MCP is a protocol, not an agent architecture
An opinionated technical look at what Model Context Protocol standardizes, what it deliberately leaves open, and where production systems still need strong architecture.
Model Context Protocol is an important step toward interoperable AI tools. It also attracts expectations that no protocol can satisfy by itself.
MCP can standardize how an AI application discovers and invokes capabilities or reads contextual resources. It does not decide which tool an agent should use, whether an action is safe, how memory should work, or what to do when a workflow partially fails.
That distinction matters. MCP is infrastructure, not the complete agent architecture.
What a protocol gives us
Without a shared protocol, every AI client and every external system need a custom adapter. The number of integrations grows as a matrix.
With a common client-server contract, a server can describe capabilities in a way multiple hosts understand. This creates a more reusable boundary for:
- Tool discovery and invocation.
- Contextual resources.
- Prompt or workflow templates.
- Capability negotiation.
- Local and remote connections.
The strategic value is portability. A useful integration should not have to be rewritten for every assistant interface.
What MCP does not decide
An MCP connection does not automatically provide:
| Concern | Still owned by the application |
|---|---|
| Planning | Which sequence of actions advances the goal |
| Authorization | Which user may access which capability or data |
| Approval | Which concrete side effects require confirmation |
| Memory | What persists across sessions and for how long |
| Evaluation | Whether tool selection and outcomes are correct |
| Recovery | How retries, partial failure, and compensation work |
| Trust | Whether a server and its returned content are safe |
Calling an agent “MCP-powered” says something about its connections, not its reliability.
Tool descriptions are part of the control plane
Models choose tools partly from names, descriptions, schemas, and the current context. Ambiguous descriptions produce ambiguous behavior.
A production tool should have a narrow purpose, validated parameters, predictable output, and explicit side effects. Descriptions should say what the tool does and does not do. Errors should be typed so the host can distinguish invalid input, missing permission, transient failure, and a permanent business rule.
Tool metadata is not documentation added later. It participates in runtime decisions.
The confused-deputy problem
An agent may have access to a private resource and also consume untrusted content. If that content instructs the agent to reveal data or invoke a privileged tool, the agent can become a confused deputy: it misuses its authority on behalf of an untrusted source.
Protocol support does not remove this risk. Hosts still need:
- Clear trust boundaries between content and instructions.
- Per-tool and per-resource authorization.
- User-visible confirmation for sensitive effects.
- Origin and provenance attached to returned content.
- Isolation for servers with different trust levels.
- Logs that connect a model decision to the executed capability.
The safest default is least privilege, not maximum connectivity.
Local servers change the economics
One of MCP's most interesting properties is that a server can sit close to the data or capability. A local server can expose files, developer tools, or desktop applications without first copying all information into a central SaaS database.
Local does not automatically mean secure. The host still needs process isolation, consent, scoped filesystem access, secret management, and clear network behavior. But local execution enables architectures where users keep control over sensitive context and choose which model provider receives it.
Our opinion
MCP is likely to become ordinary plumbing, and that is a compliment. Successful protocols become less visible as ecosystems build around them.
The differentiating layer will be above the protocol: transparent context assembly, trustworthy permissions, durable state, excellent tool design, and interfaces that let users understand what an agent is about to do.
Standard connections are the beginning of an AI platform, not the end.