MCP Build vs Buy: The Tool Boundary You Should Own

Why is the MCP decision a purchasing decision?

Because the protocol is not the thing you buy. The servers are.

Model Context Protocol solved a real problem — one way for an agent to call a tool — and it did it by standardising the shape of a tool call: a name, a JSON schema, a result. What it deliberately does not standardise is meaning. Whether create_draft_quote refuses a customer on credit hold, whether a retry after a timeout creates a second quote, whether an ambiguous invoice number is rejected or guessed: none of that is in the protocol, and all of it is your business.

So when a vendor offers an MCP server that connects an agent to your ERP, you are not buying a protocol adapter. You are buying their interpretation of your operations, with their schema, their retry semantics and their error taxonomy — and you will discover the differences on the day something goes wrong. The useful question is therefore not "MCP or not MCP". It is which tool boundary you write yourself.

Buy the servers that read commodity data through documented APIs. Build the servers that write to your systems of record, and the ones that encode a decision your team is paid to make.

I ship MCP servers for a living and I also review bought ones, and the failures are consistent enough to state as a rule: nothing on the read path has ever cost a client a customer, and every serious incident I have seen happened on a write path whose semantics belonged to somebody else.

What does buying an MCP server actually transfer?

Eight surfaces, and it is worth knowing which of them a quote is really pricing.

Surface	What the vendor controls when you buy	What you control when you build
Tool names and schemas	The vocabulary the model is given, and how narrow it is	Your own names, your own required fields
Argument validation	What is rejected before the model's output reaches your system	Your constraints: minimums, enumerations, referential checks
Authentication and scope	Usually one credential with the vendor's aggregate permissions	A scope per action, narrower than the human who approved it
Retry and idempotency	Whatever the connector does on a timeout, documented or not	An idempotency key on every write, and a refusal on duplicate
Error taxonomy	Their error codes, mapped to their meaning of failure	"Cannot do this" as a first-class answer the agent can act on
Audit record	Their log, in their console, with their retention	A run record you can join to your own tickets and invoices
Versioning	Tool names and schemas changing on their release train	A version pin and a deprecation notice you write
Egress	The regions and hosts their server talks to	The list you can put in front of a security reviewer

Notice that six of the eight are not features. They are liabilities, and buying moves them to a company whose incentive is to cover the median customer's case.

Which tools should you build, and which should you consume?

A workable rule, ordered by how much damage a wrong answer does.

The tool…	Build or consume	Because
Reads a commodity system through a stable API (calendar, weather, exchange rates)	Consume	The semantics are the vendor's, and nobody pays you for knowing how to read a calendar
Reads your own system of record, read-only	Either; consume if the API is stable	Blast radius is informational, so a bad answer costs a re-run rather than a correction
Writes anything to a system of record	Build	Duplicate writes, scope and audit are your liabilities, so the code has to be yours
Encodes a judgement your team makes (pricing, credit, escalation)	Build	There is no vendor market for your judgement, and no schema that captures it
Appears in a customer-facing promise (a quote, an SLA, a refund)	Build	You will have to reconstruct what it did, in writing, months later
Wraps a system you are already planning to leave	Consume, and keep it short-lived	Do not build a boundary you intend to abandon

The test I use in a vendor call is to fill in a third column while they talk: who owns this row? Any tool that writes, encodes a judgement, or appears in a promise, and is still owned by the vendor at the end of the call, is the row to build — and it is usually two to four tools, not fifty.

What does building the boundary actually cost?

Less than the argument implies. On the systems I ship, the differentiating layer is 200 to 600 lines across two to four tools, plus the pieces that make the boundary trustworthy:

A written contract per tool — what it does, what it refuses, what it returns on failure.
Idempotency on every write, with the key supplied by the caller rather than derived. Idempotency for agentic writes is the whole argument; the short version is that an agent that retries after a timeout will duplicate a write unless the tool refuses to.
A failure taxonomy the agent can act on: retryable, needs a human, invalid input, forbidden. A tool that returns an empty success teaches the model to keep going.
A per-run audit record — which tool, which arguments, which approval, which model version.
A version pin so a schema change is a decision you make rather than an incident you discover.

One engineer, one to two weeks, and the build is smaller than most platform implementations of the same process. The full engineering treatment of that server is in designing an MCP server that survives production; what belongs here is the purchasing question.

What has to be true for a bought MCP server to be acceptable?

If the row really is commodity — read-only, no promise attached — then buying is correct, provided the answers to eight questions are quotable sentences rather than assurances:

Requirement	The question to ask	The acceptable answer
Scoped authorisation	Is the credential scoped per tool, or one token with everything?	Per-tool scopes you can narrow further
No shared credentials	Do two customers ever share a credential or an endpoint session?	Never, stated in writing
Stable naming	How will tool names and schemas change, and how much notice?	Versioned names, deprecation notice, changelog
Retry semantics	What happens if my agent retries a write after a timeout?	A documented idempotency key, and a refusal on duplicates
Native audit	Can I export run records joined by my own task ids?	An export with your identifiers, not theirs only
Egress control	Which hosts, which regions, and can it be constrained?	A list, a region, and a way to enforce both
Upgrade notice	What happens to my workflow when the server changes?	A version pin plus a migration period
Exit	Can I point the agent at my own server without changing the agent?	Yes, demonstrated — the protocol is the exit path

That last row is the reason MCP is worth adopting even if you buy everything else. Because the interface is standard, replacing a bought server with your own is a configuration change rather than a rewrite — which means buying is a reversible decision, and the reversibility is the thing the contract should protect.

What does the boundary have to record?

A register, one row per tool, and it should be short enough that somebody reads it:

Tool	May be called by	Scope	Writes to	Idempotent	Owner	Reviewed

If that table cannot be filled in, there is no tool boundary — there is a list of integrations, and the difference only becomes visible when someone has to answer why the system sent a second quote on a Tuesday. Keeping the register current is the first control in an agent governance framework, because a control that is not attached to a named row is a policy document.

Where does MCP governance fit?

Gateways, registries and policy layers are appearing quickly, and they are useful: they centralise discovery, quotas, and the ability to turn a tool off everywhere at once. Two things are worth being clear about before a gateway is bought as a governance answer.

A registry entry is not an approval. It proves a server exists and is reachable, not that anybody decided its write semantics were acceptable.

A gateway is not a boundary. It can constrain who calls what, and it cannot tell whether unit_price_cents means something different from the field of the same name in your accounting system. That judgement lives in the schema and the contract, and it is written by whoever owns the tool.

So the ordering is: write the boundary where the meaning is, then let a gateway enforce the policy you already decided. Buying the enforcement layer first produces an enterprise that can prove it deployed a tool while being unable to say what the tool means.

When is buying the MCP server clearly right?

Four cases, and they cover most of what a company will ever connect.

Read-only, commodity, and stable. Nothing about your business is encoded, nothing is written, and the vendor's API changes less often than yours would.

The write is theirs anyway. If the system of record belongs to a SaaS product you do not control, its own MCP server may have better semantics than anything you would write, because they know their invariants.

No owner exists. A boundary with nobody responsible for its review dates is worse than a rented one; a subscription at least has a support line.

You are testing whether the process is worth automating at all. Consume a server for two weeks, run your own cases, and decide. Then build the boundary for whichever two tools earned it — the reverse order is how teams end up maintaining fifty tools they never chose.

Who owns each row?

The whole decision collapses into one column of names. Write down every tool an agent can reach, and against each one the person who owns its schema and its refusal conditions. The rows still owned by a vendor are a deliberate rental with a documented exit; the rows with no name at all are where the system will surprise you, and they are the only ones worth a build.

If you want the same analysis at the level above the protocol — which of the four boundaries of an agent purchase are worth owning, and which are genuinely commodities — the four decisions in a build-versus-buy choice for agents is where this one sits.