A single internal application needs Claude to look up a customer's order status from one private REST endpoint that no other team consumes. The team wants the smallest amount of surface area to build, operate and secure, and has no plan to share the integration. Which mechanism fits that constraint best?
- AStand up an MCP server wrapping the order-status endpoint so the integration is available to any future client that might need it.
- BDefine one custom tool in the application that calls the order-status endpoint and returns the specific fields the model needs. Correct
- CRely on a built-in tool to reach the private order-status endpoint, since that endpoint speaks ordinary HTTP over the internal network.
- DAuthor a Skill that documents the order-status endpoint's request shape so the model can construct the correct call whenever it is asked.
Why A is wrong: Tempting because MCP is the correct reuse mechanism in general, but with exactly one consumer and no sharing requirement it adds a service to deploy, secure and monitor for no gain today.
Why B is correct: Correct because a single custom tool inside the one consuming application is the smallest thing that satisfies the requirement, with no extra process, transport or deployment target to operate.
Why C is wrong: Tempting because the endpoint is just HTTP, but built-in tools are not a general gateway to arbitrary internal APIs, so this assumes reach the mechanism does not have.
Why D is wrong: Tempting because a Skill is the right home for reusable procedural knowledge, but knowing the request shape is not the same as being able to make the call, so nothing actually executes.