Designing every agent against MCP first.
The architectural decision that has paid the most consistent dividends across the agent systems I’ve shipped in 2025 is not exotic. It is a posture choice you can adopt in a one-line standard: every tool an agent reaches for is defined as an MCP server, even when the first deployment doesn’t need MCP and would be simpler to wire up directly.
The first time you make this choice, it costs you a few hours of extra setup work and produces no visible benefit. The agent still calls the tool. The tool still returns the answer. The user still gets the feature. Nothing about the immediate deliverable looks different from the version you’d have shipped by inlining the tool call directly into the agent’s framework code.
The benefit shows up by month four, and it shows up in a way that compounds. The agent moves to a different runtime. The tool gets replaced by a different vendor’s equivalent. A second agent needs the same tool. A third agent needs a different tool that the same vendor also exposes. The customer asks whether the system can integrate with their internal API instead of the third-party one you initially built against. Each of these events is a routine event in the lifecycle of a production agent system, and each of these events is dramatically cheaper to handle when the tool surface is defined against MCP than when it is bespoke to the agent framework you originally chose.
This essay is the architectural case for treating the Model Context Protocol as the default tool-surface contract from day one. Why the posture pays off, what the day-one cost actually is, and where the discipline matters most.
What MCP actually buys you
MCP is the open protocol Anthropic released in late 2024 that standardizes how language models invoke tools and access external context. The protocol uses JSON-RPC over a transport (stdio for local servers, HTTP/SSE or streamable HTTP for remote ones), and it defines three core primitives: tools (functions the model can invoke), resources (data the model can read), and prompts (templates the application can offer the model). The protocol has been adopted by every major frontier model provider and by most serious agent frameworks. Cloudflare, OpenAI, Anthropic, Google, and the open-source ecosystem all ship MCP support natively as of late 2025. The community has built thousands of MCP servers covering everything from filesystems and databases to GitHub, Slack, Salesforce, calendars, and the long tail of specialty tools.
What MCP actually buys you is not the protocol itself. Protocols are not interesting on their own. What MCP buys you is that the contract between your agent and the tool is now defined by something other than your agent framework’s idiosyncratic tool-registration API. The implications are mostly mundane and entirely cumulative.
If you write your agent’s filesystem access as direct framework calls and the framework’s filesystem API changes between versions, you rewrite. If you write it against an MCP filesystem server, the framework upgrade doesn’t touch your tool layer. If you decide to switch agent frameworks entirely — from one orchestration library to another — the framework swap doesn’t require rewriting your tool integrations, because the agent on either side talks MCP. If you decide to expose your internal tools to other agents in your organization, the MCP server you already wrote is the integration; you point another agent at the same server and you’re done. If a customer asks whether the agent can integrate with their internal version of a tool you currently call out to a vendor for, you write an MCP server in front of their internal API and your agent doesn’t change.
None of these are large wins individually. All of them are routine maintenance tasks in the life of a production agent system. The discipline of designing against MCP first means each of them costs roughly an hour instead of roughly a week. Over the lifetime of the system, the compounding is what matters.
The day-one cost, honestly
The day-one cost of designing against MCP first is real, and it is the reason most teams skip the discipline.
The first version of any tool integration is faster to write inline. If your agent framework has a tool decorator that lets you write a Python function and have it automatically available to the model, the path of least resistance is to write the function inline and move on. Writing the same function as an MCP server requires a few more steps: scaffolding the MCP server, defining the tool schema in the MCP format, handling the JSON-RPC transport, registering the server with the agent’s MCP client. Each step is small. The cumulative day-one cost is maybe two to four hours for a non-trivial tool, versus thirty minutes for the inline version.
That two-to-four-hour cost is real, and it is the cost most teams use to justify skipping the discipline on the first integration. They are not wrong about the cost. They are wrong about the durability of the inline-first decision. The first integration is almost never the only integration the system will ever need. The second integration is faster because the scaffolding is now reusable. By the fifth integration, the MCP-first approach is faster than the inline approach for new tools, because the patterns are settled and the agent framework already knows how to talk to MCP servers.
The honest framing for a customer who is asking why the proposal includes “MCP server scaffolding” as a line item: this is a small investment up front that prevents a larger rework later. If the system is going to be touched again — which every production system is — the MCP-first posture is paid back inside the first scope-change conversation.
Where the portability dividend actually shows up
The “portability dividend by month four” claim in the teaser is not rhetorical. It is the pattern I have observed across the agent systems I’ve shipped in 2025. The specific shape varies by engagement, but the timing is remarkably consistent. Sometime between the third and fifth month of a production system’s life, something happens that would have required a major rework on an inline-tools architecture and that costs an afternoon on an MCP-first architecture.
The shapes I’ve seen, in rough order of frequency:
Framework swap. The team picks an agent orchestration framework in week one based on what looked good at the time. By month four, either the framework has moved in a direction the team didn’t expect (breaking changes, licensing shift, maintainer departure) or a different framework has emerged that’s a better fit for what the system has actually become. On an MCP-first architecture, the framework swap is mostly a swap of the orchestration code; the tool layer doesn’t move. On an inline-tools architecture, the framework swap is a forklift of the tool layer as well, because the tool registration is framework-specific.
Tool vendor swap. The team integrates with a specific vendor’s API for some capability in week one (search, embeddings, file storage, document parsing, whatever). By month four, either the vendor has changed something (pricing, terms, rate limits) or a competing vendor has emerged with a better fit. On an MCP-first architecture, the vendor swap is a swap of the MCP server’s internals; the agent doesn’t know which vendor is on the other end. On an inline-tools architecture, the vendor swap propagates through every agent call site that touched the tool.
Multi-agent expansion. The team ships an initial agent that does one thing well. By month four, the customer wants a second agent that does a related thing, or wants the first agent’s capabilities exposed to a different surface (a Slack bot, a CLI, a different product). On an MCP-first architecture, the existing tools are already exposed as MCP servers; the second agent points at the same servers and inherits the capability. On an inline-tools architecture, the tool layer has to be extracted or re-implemented for the second agent.
Internal-API integration request. The customer’s procurement or security team asks whether the agent can be reconfigured to use the customer’s internal version of an external tool (their internal search, their internal document store, their internal user directory). On an MCP-first architecture, the answer is “yes, we write an MCP server in front of your internal API and the agent doesn’t change.” On an inline-tools architecture, the answer is “yes, but it’ll take a quarter.”
Across the systems I’ve shipped this year, at least one of these four events has happened on every system, somewhere between month three and month six. The portability dividend is not theoretical. It is what allowed the engagement to absorb the event without renegotiating scope.
The patterns that make this work
Three architectural choices, more specific than just “use MCP,” that have made the posture actually pay off in practice.
Treat every external dependency as an MCP server, even the ones that don’t naturally fit. A vendor API that returns JSON does not “naturally” fit the MCP tool model — you have to write a thin wrapper that exposes the API’s operations as MCP tools. Write the wrapper anyway. The wrapper is twenty minutes of work and it gives you the abstraction barrier that pays off later. The exception is internal Cloudflare bindings (D1, R2, KV) which are tightly integrated with the Worker runtime and don’t benefit from being wrapped — these are the runtime fabric, not external dependencies.
Treat MCP servers as deliverables in their own right. When you write an MCP server for a customer engagement, you have written a reusable artifact that could be valuable to the customer beyond the immediate agent. Document it. Version it. Treat it as part of the IP transfer at the end of the engagement. Customers who realize they own a portable MCP server for their internal CRM (or whatever) at the end of the engagement get more value than customers who realize they own an agent that happens to talk to their CRM.
Standardize on the streamable HTTP transport for remote MCP servers, stdio for local. The MCP spec supports multiple transports, and the temptation in early development is to use whatever transport is easiest in the moment. By month four, transport heterogeneity becomes a maintenance tax. Pick one for remote and one for local up front and stick to them across the engagement. The patterns are settled enough by late 2025 that this choice is uncontroversial; just don’t reopen the conversation every time a new server gets added.
When to break the discipline
Honest about exceptions, because every architectural posture has them.
Throwaway prototypes that will never see production. If you are running a one-week proof-of-concept for an internal demo, MCP scaffolding is overkill. Inline the tools, ship the demo, throw the code away. The discipline exists for production systems with a lifecycle measured in months and years; it does not apply to evaluations measured in days.
Tools that are genuinely framework-specific. Some agent capabilities are tightly coupled to the framework’s runtime in ways that don’t translate cleanly to MCP — for example, framework-native introspection of the agent’s own execution state. These should remain framework-native. Trying to force everything through MCP creates more abstraction than the system needs.
Performance-critical hot paths. MCP adds a JSON-RPC hop. For most agent tool calls (which are already running model inference in the same round-trip and are bottlenecked on model latency), the additional hop is invisible. For tool calls that need to complete in single-digit milliseconds — typically not common in agent systems, but they exist — the additional serialization overhead can matter. These are rare enough that I’d argue against optimizing for them up front; profile first, optimize specific cases as needed.
One-off internal scripts. Tools the agent uses once during initialization, debug helpers, one-shot data migration utilities. The discipline targets the durable tool surface of the production system, not every helper function the codebase contains.
The compounding argument
The deeper reason to adopt the MCP-first posture is not the specific portability events I named above. The deeper reason is that the coupling between your agent and the rest of your stack is the single largest source of architectural debt in long-running agent systems, and MCP is the cheapest available mechanism to reduce that coupling without losing capability.
Every direct tool call in your agent code is a coupling between the agent’s behavior and a specific vendor, framework, or implementation. Every MCP-fronted tool call is a coupling between the agent’s behavior and a protocol — and protocols are dramatically more durable than the vendors, frameworks, and implementations underneath them. The vendor will change. The framework will change. The implementation will change. The protocol, if you’ve chosen one with broad adoption and stable semantics, will outlast all of them.
This is the same argument that made standardizing on HTTP for service-to-service communication the right call twenty years ago, and standardizing on JSON-over-HTTP for API design the right call ten years ago. The pattern is durable because the cost of choosing a portable contract is small and the savings compound over the system’s lifetime. MCP is the version of this argument for the agent era. The protocol is settled enough, the adoption is broad enough, and the cost of designing against it is low enough that the only reason not to is impatience with the day-one setup.
The agent systems I’m shipping in 2026 will be MCP-first by default for the same reason the services I shipped in 2015 were HTTP-first by default. The contract is the leverage. The protocol is what makes the contract durable. Everything else is implementation.
Design against MCP first. The dividend pays itself.