Tools and MCPs

A logistics team wants its Claude assistant to report the current status of a shipment held in an internal tracking service that sits behind the company VPN and has no public presence. A developer argues that no integration work is needed because the assistant already has a built-in web search capability, so it can simply look the shipment up. Which assessment of that argument is correct?

• AThe argument fails, because a built-in capability covers only the surface it was designed for, so reaching a private internal service needs a tool the team defines and implements against that service.check_circle Correct
• BThe argument holds, because a built-in search capability resolves any address the application is permitted to reach, so the private service is available once the request is phrased with the internal host name.
• CThe argument holds in part, because the built-in capability can reach the service once the team raises the number of results it is allowed to return and grants the assistant a longer working context.
• DThe argument fails, but the remedy is to paste the current shipment records into the system prompt at each deployment, so the assistant answers about live shipments without any integration work at all.

Why A is correct: Correct: the reach of a built-in capability is fixed by the platform, and an arbitrary internal system needs an integration the team writes, whether as a custom tool in the application or as a tool exposed by an MCP server.

Why B is wrong: It is tempting because search feels like a general-purpose reach-anything mechanism, but a built-in capability is scoped to what it was built to do and does not become a client for an arbitrary private endpoint just because a host name is supplied.

Why C is wrong: Tempting because result limits and context size are real levers, but neither changes what the capability is able to reach, so the private service stays unreachable however those settings are tuned.

Why D is wrong: Tempting because it avoids writing an integration, yet pasted records are fixed at deployment time and go stale between deployments, so status answers stop matching the tracking service.

A platform group owns an internal contract registry behind a private HTTP API. Two Claude applications and an internal coding agent all need to query it live. The group must be able to change the query surface each quarter without any consuming team editing its own code, and the consumers must not hold the registry credentials themselves. Which mechanism fits those requirements?

• AGive each of the three consumers its own custom tool that calls the registry API directly, with the registry credential configured inside each consuming application.
• BPublish a Skill that describes the registry's endpoints and query format, so each consumer assembles its requests from one shared written procedure.
• CExport the registry to a shared file each night and have each consumer load that export into its context at the start of a run, avoiding any live query path.
• DRun an MCP server owned by the platform group that exposes the registry, so all three consumers share one tool surface that the owning group controls and changes.check_circle Correct

Why A is wrong: Tempting because custom tools are the simplest way to reach a private API, but it spreads the credential across three applications and makes every quarterly change a coordinated edit in three codebases.

Why B is wrong: Tempting because one shared written definition does keep the three consumers aligned, but a Skill carries no access and no credential, so none of the consumers gains the ability to query the registry.

Why C is wrong: Tempting because it removes credentials from the consumers, but a nightly export is a copy rather than a live query, so answers reflect yesterday's registry rather than its present contents.

Why D is correct: Correct because MCP puts the tool surface and the credential behind a boundary the owning team controls, letting it change the query surface for several consumers without any of them editing code.

Three internal assistants owned by one team must each produce incident reports in the company's house format: a fixed section order, agreed severity wording and a worked example. All three already hold the tool access they need, the format is revised about twice a year, and reviewers have recorded the wording drifting between the three assistants. Which mechanism fits that requirement?

• ABuild an MCP server that returns the report format as a resource, so each of the three assistants fetches the current wording from it at request time.
• BAdd a custom tool to each of the three assistants that returns the section order and severity wording from a small internal service the team stands up.
• CAuthor the section order, severity wording and worked example as a Skill and make it available to all three assistants, since no new system access is required.check_circle Correct
• DWrite the full format and the worked example into each assistant's system prompt, and update all three prompts whenever the reporting format is next revised.

Why A is wrong: Tempting because an MCP resource does give one shared, centrally owned copy of the wording, but it buys a running service and a release pipeline for static text revised twice a year that needs no access boundary.

Why B is wrong: Tempting because a tool would indeed return one authoritative copy, but it puts a service and three separate tool implementations behind content that changes twice a year and requires no live lookup.

Why C is correct: Correct because the gap is consistent application of a written procedure rather than access to anything new, and a Skill is the packaging that carries that procedure to every assistant from one maintained source.

Why D is wrong: Tempting because it is the quickest route to correct wording today, but it creates three copies that must be edited together, which is the same drift the reviewers have already recorded.

A two-person team maintains one internal rota assistant that reads staff shift data from a single private endpoint no other application consumes. An engineer proposes building an MCP server for it, with its own deployment, monitoring and on-call rota, in place of declaring one tool in the assistant's own integration layer. The team has a fortnight of build budget and no operations staff. Select TWO valid objections to that proposal.

• AA separately deployed server would prevent the assistant from validating the arguments the model produced before the shift endpoint is called, so out-of-range requests would reach the private system unchecked.
• BA single custom tool cannot be given a structured input schema, so the team would lose the ability to constrain the shift date and the staff identifier that the model supplies on each call.
• CThe proposal adds a separately deployed and monitored process with an owner on call, which is a continuing operational cost that a team of two with no operations staff must carry for one caller.check_circle Correct
• DAn MCP server may not be run inside a private network, so the shift endpoint would have to be exposed publicly for the server to reach it, which the team's security position does not permit.
• EThe value an MCP server buys is one maintained interface shared by several consuming applications, and with exactly one consumer that benefit is never realised while the maintenance still falls due.check_circle Correct

Why A is wrong: Tempting because argument validation genuinely matters, but a server implements its own handlers and validates arguments exactly as an in-process tool handler does, so the stated loss does not occur.

Why B is wrong: Tempting because schema quality really is what drives good tool arguments, but a tool declared directly by the application carries a JSON input schema in the same way, so nothing is lost by not building a server.

Why C is correct: Correct: the server is not just code to write once but a running service to deploy, watch and support, and the stated staffing and budget make that ongoing cost the decisive objection.

Why D is wrong: Tempting because network placement is a real concern in integration design, but servers are routinely run inside a private network next to the systems they front, so the stated restriction is not real.

Why E is correct: Correct: the reuse and ownership boundary is the reason to pay for a server, so with a single consumer the cost lands with none of the return, which is the definition of overkill here.