I am writing this on a Tuesday in mid-March, twenty-seven weeks and roughly two hundred and seventy-five commits into building DuranteOS. Studio has been live for sixty-seven days. The Hexagonal migration of the gateway is essentially complete. The first MCP-shaped tool calls were running through Studio inside the first two weeks after launch; by today the gateway has handled enough MCP traffic that I can speak honestly about what the protocol delivers in production and what I had hoped it would deliver and was wrong about.

This is the first new evergreen in the series — the prior twenty rewrote existing posts; the next seven write to the timeline as it actually develops. I am starting with MCP because the recurring lesson of the last eight dispatches has been that the protocol is the boundary. Microsoft default Claude. ServiceNow Build Agent. Cursor's first-class /mcp slash command. Figma shipping parallel Claude Code and Codex MCP integrations eight days apart. The Anthropic Skills directory. Each of those moves only works if MCP is genuinely the contract — an abstraction stable enough that integrations on either side of it survive vendor-by-vendor variation.

Sixty-seven days of production traffic later, my answer is: mostly yes, with three named leaks that an indie founder should plan for in advance.

The Cockburn angle: MCP as a port, every server as a driving adapter

Alistair Cockburn's 2005 article on Hexagonal Architecture is twenty-one years old this year. The framing it offers is the cleanest possible lens on what MCP actually is: a driven port on the agent runtime side, with each MCP server playing the role of a driving adapter that supplies tools, prompts, and resources through the port's defined contract.

The shape of the protocol matches the pattern almost exactly. The agent runtime declares a stable interface (tools/list, tools/call, resources/read, prompts/get). Each MCP server implements the interface. The runtime does not need to know whether the server is talking to GitHub, Figma, a SQLite database, or a custom internal tool. From the runtime's perspective, every server is the same shape.

That is exactly what Cockburn warned twenty years ago to design toward: an application that does not know what is on the other side of its ports.

The practical payoff in Studio is a single concrete property. Adding a new MCP server does not require any change to the agent runtime, the routing layer, or the credit-metering logic. It is a registry edit and a startup-time discovery call. Sixty-seven days of production has confirmed this property holds — I have added five MCP servers since launch with zero changes to the gateway core. That is the cleanest possible evidence that the abstraction holds under load.

The Fowler angle: every adapter needs an anti-corruption layer

Where MCP fails as a strict Cockburn-style port — and where I needed Martin Fowler's anti-corruption layer concept from Patterns of Enterprise Application Architecture (2002) — is at the adapter edge of each MCP server.

The protocol abstracts the transport and the contract shape. It does not abstract the behavior of any specific upstream service. A GitHub MCP server returns issues in a shape MCP defines. The shape is consistent. The behavior — when the issues are stale, what fields are reliable, what rate limits apply, what authorization scopes the token actually grants — is GitHub-specific and leaks through the protocol no matter how clean the shape is.

Fowler's pattern is to put a small translation layer inside each adapter that converts between the upstream's actual semantics and the application's clean abstraction. In MCP-land, that means each MCP server I run benefits from a thin ACL between the raw provider behavior and the protocol-shape responses.

The discipline is that you write the ACL once per provider and it pays back across every tool call that touches that provider. Without it, the agent runtime ends up handling provider-specific error shapes, provider-specific auth quirks, and provider-specific staleness assumptions inside what should be vendor-neutral logic.

The three leaks I have hit in sixty-seven days

Three concrete places where MCP's promise of vendor-portability genuinely leaked, and what the ACL pattern looks like for each.

These three leaks do not invalidate the protocol. They define the shape of work an indie founder needs to do on top of the protocol to make production deployments hold up. Every named refactoring in the hook-pipeline walkthrough had a similar shape: the abstraction was right, and the abstraction needed a small concrete companion to actually work.

What MCP actually buys you in production

Three properties I would not have without the protocol, named honestly.

The ratio matters. Five things delivered, five things not delivered. Both lists are long. The right framing — and the framing that took me sixty-seven days to internalize — is that MCP is a baseline, not a complete solution. Below the baseline, the protocol holds and saves you significant work. Above the baseline, you write the ACL per provider and the tooling that connects MCP semantics to your application's needs.

The two production patterns that emerged

Three months in, two patterns have repeatedly justified their cost.

Pattern one: thin adapters with declared contracts. Each MCP server we add gets a small wrapper file declaring its staleness, auth-scope, and error contracts as adapter-level metadata. The runtime reads this metadata at startup and adjusts behavior accordingly — for example, retrying once on a transient error from a server that declares 30-second staleness, but failing fast on a permanent error from the same server. The cost is one file per provider. The benefit is that the runtime's vendor-neutrality holds without losing the per-vendor nuances.

Pattern two: per-server eval suites for the ACL. Every MCP server gets a small eval suite — five to ten characterization tests — that exercises its tools against the agent runtime through the protocol. The suite catches ACL drift when an upstream's behavior changes. Without these suites, the leaks listed above would have surprised me at the worst possible moment (a customer call) instead of at a Tuesday-morning eval run.

Both patterns are direct applications of the eval-suite essay from W16. Translated TDD applied to a protocol boundary is exactly the discipline MCP needs to hold in production. Without it, the boundary erodes silently the way every boundary erodes silently when no one tests it.

What this implies if you are building MCP servers

Three suggestions, in order of how much they have changed my own practice over sixty-seven days.

One. Treat the protocol as the floor, not the ceiling. MCP gives you transport and shape. You will need staleness, scope, and error semantics on top. Plan for it. Build the ACL pattern from the first server. The cost of doing it later, after the first leak surprises you in front of a customer, is much higher than doing it from day one.

Two. Write per-server eval suites. Each MCP server is a third-party integration with its own behavioral drift over time. The suite catches drift. Without the suite you will discover drift only when something breaks. Translated-TDD discipline applies here exactly.

Three. Bias toward writing your own MCP servers, not consuming third-party ones, until the third-party ecosystem matures. The ones I have run from third-party authors have averaged 3-4x the operational variance of the ones I have written myself. Some of that is inexperience on my side; most of it is that the third-party servers ship with implicit assumptions about their host environment that do not match mine. The ratio will improve as the protocol matures; for now, write what you can.

What this means for Studio

Two design decisions hardened across sixty-seven days of production:

One. The Studio gateway treats every MCP server as a driven adapter in the Hexagonal sense. The Provider port from the W15 hexagonal essay is not different in shape from the MCP-server port — both are driven adapters supplying capability through a uniform contract. This made the adapter-pattern unification straightforward: a single registry of adapters, half of them frontier-model providers, half of them MCP servers. Each adapter declares its staleness, scope, and error contracts as metadata. The runtime treats them uniformly.

Two. The first DOS pack to ship as a public MCP server — Sentinel, sketched in W8 — gets the full ACL treatment from day one, not retroactively. The lesson cost too much in the first three months to apply selectively going forward.

The protocol-as-boundary thesis I have been sketching since November is now stress-tested by sixty-seven days of production. The thesis holds. The discipline that makes it hold — anti-corruption layers per provider, eval suites per server, treating the protocol as a floor rather than a ceiling — is the work the original Cockburn-and-Fowler reading list has been preparing me for since I picked it up two decades ago.

The protocol is the boundary. The ACL is the work. Both together are how MCP earns its keep in production.

The retrospective on the back half of the year ships at the end of June, after another quarter of MCP traffic has either confirmed or revised these lessons. The discipline, by then, will either be vindicated or replaced. Either result is more useful than continuing to operate without commitment to the shape.