MCP as a Seam

Overview

Section 1 designed a tool surface. Each tool on it is an integration, and integrations sprawl — a second consuming system wants the same tools, a third provider arrives, and before long every pair has its own bespoke connection.

MCP — the Model Context Protocol — is a standard way for a system to expose tools and data to models. This topic is about what that buys architecturally, and about the much more important thing it does not buy.

The problem it solves

Bespoke integrations — every consumer wired to every provider:

graph LR
  C1["Agent"] --> P1["Monolith"]
  C1 --> P2["Scheduling"]
  C2["Internal tool"] --> P1
  C2 --> P2

  classDef c fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef p fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class C1,C2 c
  class P1,P2 p

One seam — each side implements the protocol once:

graph LR
  D1["Agent"] --> S["MCP seam"]
  D2["Internal tool"] --> S
  S --> Q1["Monolith"]
  S --> Q2["Scheduling"]

  classDef c fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef s fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef p fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  class D1,D2 c
  class S s
  class Q1,Q2 p

Consumers times providers becomes consumers plus providers. The amber box is the seam, and the saving grows with both counts — which is also the clue about when it is not worth having.

The architectural value is the seam: a documented boundary where tool integration stops being ad hoc. A seam is a place you can put things — versioning, instrumentation, a single list of what exists. Module 3 argued that a reference architecture’s main gift is the decisions a team no longer has to make; a tool seam is the same gift at the integration layer.

The caveat that matters most

Here is where teams get into trouble, and it is worth stating as bluntly as possible:

A protocol standardises access. It does not standardise authorisation.

MCP describes how a tool is discovered, described and invoked. It does not decide who may invoke it, on whose behalf, within what scope, up to what limit, or with what confirmation. Every gate from the action boundary topic — tenant scope from the session, allowlists, limits as configuration, confirmation by tier, idempotency keys issued by your code — is still yours to build, and none of it arrives with the protocol.

The failure mode is specific and common: a team adopts a tool protocol, sees that tools are now neatly exposed and discoverable, and concludes the permission model came along with them. What they have adopted is a transport. The security design is still unwritten, and it is now harder to see that it is missing, because the architecture looks tidy.

So the enforcement points live behind the seam, in the action layer, not in the protocol. The seam is where a request arrives; the gates are what it passes through afterwards.

Tool definitions from a server you do not control are untrusted content

The second caveat, and it follows directly from Module 2’s trust labels.

A tool’s description is part of the prompt — Section 1 made that point in order to argue that descriptions deserve review. The same fact has a security consequence: a tool description is text that reaches the model, so a server that supplies descriptions can inject instructions.

A compromised or hostile server does not need to do anything exotic. It supplies a tool whose description tells the model to do something it should not, and the description is delivered with the authority of a system component rather than the suspicion owed to user input.

The responses are the ordinary ones for untrusted content: pin the servers you trust rather than discovering them dynamically, review tool definitions as you would review code, version them, and apply the same trust-label discipline that keeps retrieved ticket text from being treated as instruction. A third-party tool server is a supply-chain dependency with prompt-level reach.

It is still a distributed dependency

Briefly, since the mechanics are prerequisite knowledge: an MCP server is a service. It has availability, latency, versioning and failure characteristics, and standardising the interface does not change any of them. A tool call that crosses a network can time out, and the loop’s bounds from Section 1 have to account for that.

When it is not worth it

The saving is multiplicative in consumers and providers, which tells you when it does not apply. One consuming application with three bespoke tools against one internal API gets a protocol, a server to run, and a schema to version — in exchange for an abstraction that saves nothing yet.

The honest rule: adopt it when you have more than one consumer, or more than a couple of providers, or when you can see the second consumer arriving. Before that, direct integration behind the tool surface you already designed is simpler and loses nothing — and Section 1’s promoted tools are exactly the interface you would expose through a seam later.

The seam, with the gates behind it

The action tools reach the Rails monolith for job records, scheduling and credits. Module 3’s reference architecture already forbade reaching its database directly.

Adopt the seam, for one reason that is already visible: the agent is not the only future consumer. Grace Adeyemi’s support console will want the same read and action capabilities for its own tooling, and the internal admin surfaces will too. Writing the monolith integration once, behind a documented seam, and consuming it from both is the additive version of a problem that is otherwise multiplicative.

What lives at the seam: tool discovery, schemas, versioning, and instrumentation — one place that knows which tools exist and what shape they take.

What emphatically does not live at the seam: the enforcement. Tenant scope is asserted from the authenticated session in the action layer. The credit limit is configuration in the action layer. The confirmation requirement for credits and device resets is in the action layer. The idempotency key is issued by the action layer. A reviewer asking Lena Fischer’s question — what stops this issuing a credit above the limit? — must be pointed at code, not at a protocol specification.

Third-party servers: none, initially. Every server is first-party and pinned. If one is ever added, its tool definitions are reviewed and versioned like code, because a tool description reaches the model with system authority and the ticket corpus has already made this platform’s injection surface wide enough.

Feeds the workbook

This is the MCP-based tool integration design artifact. State what the seam carries and, separately, what stays in the action layer. The second list is what makes the design reviewable by someone with blocking authority.

Check your understanding

1. Does the case system have a second consumer? If yes, name it; if no, what would you build instead and when would you revisit?
2. A third-party tool server is proposed. List the three checks you would require before connecting it.
3. Someone says the protocol gives you a permission model. What is the one-sentence correction, and what do you show them?

---

→ The system is bounded, gated and integrated. On Tuesday it issued a credit it should not have. Explain it. — Observability for agents