When MCP is the wrong answer

Read these first

• Building a server
• Consuming servers

What you will know

• Build the same capability twice — as a direct function call inside your own service, and as an MCP server — then compare the lines of code, the failure modes, and who can reuse each

  Two implementations, not four: skills and subagents are stage 12, and comparing against things you have not built yet produces an opinion rather than a measurement. The direct function is the baseline MCP has to beat, and it usually wins until a second consumer appears. Revisit this at 12.16 once the other two options exist.

• Write a decision record for a concrete integration that selects one option and records client reuse, ownership, change rate, security boundary, and rejected alternatives.

  A standard interface is not evidence by itself; the boundary should follow who deploys, governs, and changes the capability.

• Run fault-injection tests for the selected boundary covering unavailability, denied credentials, schema drift, and partial downstream failure, and demonstrate the fallback behavior.

  A design that looks simple in the happy path can strand the agent or widen permissions during an incident.

• Calculate the break-even point at which MCP's shared integration cost is lower than duplicating direct integrations across clients.

  Include hosting, engineering, authentication, support, and latency costs so small-scale reuse does not get mistaken for savings.

• Review the proposal with another engineer, defend it against a lower-cost alternative, and record the conditions that would trigger migration to a different boundary.

  Client count, team ownership, and security requirements change over time, so a good choice includes an exit path rather than permanent commitment.

Chapters

1. 1

   The direct function call baseline

   Build the same capability twice — as a function inside your own service, with a schema and description handed to the model, and as an MCP server — then count the lines, the failure modes, and who can call each. Two implementations, not four: skills and subagents arrive at stage 12, and comparing against what you have not built produces an opinion rather than a measurement. With one consumer owned by one team, the function wins on 71 lines against 340, on seven fewer failure modes, and on 27 ms of median latency.

   Read chapter
2. 2

   The deploy boundary test

   Reuse is a property of the artefact until somebody actually reuses it, so the fact that moves the decision is a named second consumer deployed by a different team — a caller who cannot import a function of yours because they are not on your release train. This chapter makes the deploy boundary the test rather than the client count, adds the durability clause that disqualifies a laptop client, and gives you the single revisit condition worth writing into a record that selected the direct call.

   Read chapter
3. 3

   Ownership, change rate and trust boundary

   Client reuse is one axis of five, and the other three do not all point the same direction. A capability another team owns, governs and deploys argues for a boundary regardless of how many callers there are; a fast-changing one argues against a shared server, because every change becomes a versioned contract renegotiated with N consumers on their own release trains. And a capability that holds credentials the caller must not hold can make a server the right answer at a single consumer, which is the one case that overrides the baseline. Learn which way each axis pushes before you write any of them into a record.

   Read chapter
4. 4

   Evidence in a decision record

   A decision record justified entirely by \"MCP chosen because it is the standard interface for agent integrations\" gets rejected, and this chapter says what belongs there instead: how many clients there are and who they are, who owns and deploys the capability, how fast it changes, what security boundary it crosses, and which cheaper option was rejected and why. The test for each line is whether it could have come out the other way for this integration; standards describe an industry, and a record has to describe your integration.

   Read chapter
5. 5

   Fixed and variable costs of a boundary

   Three internal clients at two weeks each against a four-week server is the framing you will be handed, and it omits everything recurring. Hosting, an on-call rotation, the authentication and per-consumer isolation a shared boundary demands, and support for teams you do not control all begin the day it ships; duplicated maintenance is variable and bills only when upstream moves. Build the version you would present, naming where each number comes from — and notice that the variable that flips the answer is the upstream change rate rather than the consumer count.

   Read chapter
6. 6

   Fault injection at the boundary

   Happy-path coverage of every tool says nothing about whether the boundary you selected survives an incident. Inject four faults — unavailability, refused credentials, schema drift, and a half-succeeding downstream — and notice that only three of them produce an error to assert on. The partial result returns successfully with less data than it should, which an agent cannot distinguish from a complete answer, and one of the four has a correct response that is not technical at all. Each fault then needs a demonstrated fallback, and every fallback has a failure mode of its own: omitting the tool and letting the agent proceed converts an outage into a quality regression.

   Read chapter
7. 7

   Conditional approval and reversal triggers

   The author has two teams expressing interest, the company's standard protocol, and a five-week estimate. Refusing until a second consumer is actually building against it is sound and lazy: it costs nothing to say, hands them no path, and returns the proposal next quarter with more political weight behind it. Make the case for the direct call from the author's own facts, answer the year-from-now argument without invoking YAGNI, buy the option for three days instead of five weeks, and attach triggers in both directions.

   Read chapter