· Kevin Swiber · 13 min read

🔎 Breaking Down MCP: An Architectural Analysis

AI API MCP
On this page

From checking our bank balances to planning our workout routines, APIs facilitate the interactions we take for granted. We’re witnessing a new layer of interaction emerging with Model Context Protocol (MCP), a fascinating shift worth architectural examination.

“Yet another protocol?” I thought. But as I dug deeper, I realized we’re looking at an intriguing evolution in how we interact with digital services. Let’s dive into the architecture, constraints, and some honest assessments of what MCP brings to the table.

Applying Fielding’s Method

When Roy Fielding introduced REST in his 2000 dissertation, he outlined a methodology for defining architectural styles:

  1. Start with a null architecture (no constraints)
  2. Determine desired properties of the system
  3. Apply architectural constraints to achieve those properties
  4. Document necessary trade-offs that come from applying constraints

This approach helps us understand why certain architectural decisions were made, not just what they are. Let’s apply this methodology to MCP.

The Null Architecture

In the null style, there are no constraints. Components can interact in any way, with no distinguished boundaries between them. It’s architectural anarchy, freedom but chaos.

For MCP, this would mean AI assistants and tools interact without any standardized pattern. Each assistant would need custom integration with each tool, resulting in the “M*N problem”: M assistants needing N distinct tool integrations, creating M*N integration points.

Desired Properties

If I were architecting MCP from scratch, I’d identify these desired properties:

  1. Interface uniformity: AI assistants should interact with tools through a consistent interface
  2. Tool discovery: Assistants should dynamically discover available tools
  3. Content flexibility: The protocol should handle various data types and formats
  4. Local and remote operation: Tools should function both locally and over networks
  5. Stateful context: Assistants should maintain context across interactions
  6. Security and consent: Users should control which tools assistants can use

These properties represent the architectural goals that would guide constraint selection.

Applied Constraints

To achieve those properties, MCP applies several architectural constraints:

1. Client-Server Architecture

MCP follows a client-server architecture with three main components:

  • Hosts (typically an AI assistant like Claude)
  • Clients (the bridge connecting hosts to servers)
  • Servers (providing specific capabilities)
 +--------+      +--------+      +--------+
 |        |      |        |      |        |
 |  Host  | <--> | Client | <--> | Server |
 |        |      |        |      |        |
 +--------+      +--------+      +--------+

This constraint separates concerns and enables evolution of hosts and servers independently.

2. JSON-RPC Communication

MCP uses JSON-RPC 2.0 for message exchange, defining a standard format for requests, responses, and notifications. Unlike REST’s uniform interface, MCP employs an RPC-style approach where:

  • Servers expose specific functions (tools) that can be called
  • Clients make requests that explicitly name the function to execute
  • Tools are invoked rather than resources being manipulated

This contrasts with REST’s resource-centric approach but provides directness and specificity.

3. Local-First Design

MCP was initially designed with local operation in mind, inspired by the Language Server Protocol (LSP). This constraint creates challenges for remote operation but provides security benefits by keeping data within the user’s environment.

4. Capability Negotiation

MCP includes a capability negotiation process where clients and servers exchange information about supported protocol versions and features. This enables compatibility and evolution over time.

5. Standardized Tool Discovery

MCP mandates a discovery process where servers advertise available tools, resources, and prompts. This allows AI assistants to dynamically understand available capabilities without prior knowledge.

Necessary Trade-offs

Every architectural constraint introduces trade-offs. For MCP, these include:

Local vs. Remote Operation

MCP’s local-first design creates tension when extending to remote scenarios. As I noted on LinkedIn, remote servers feel like an afterthought in MCP because they don’t exist in LSP. The original design was biased toward local operation.

Now, as MCP gains traction, there’s pressure to make it work seamlessly for both local and remote scenarios. This creates what I call “the distributed systems tax”, additional complexity needed to handle network considerations:

  • Latency and timeouts
  • Security and authentication
  • State synchronization
  • Failure handling

The MCP team is adapting the protocol to accommodate these concerns, but it’s navigating the classic evolution from local-first to distributed architecture. This is neither good nor bad. It’s just a natural progression that comes with trade-offs.

RPC vs. REST Style

The choice of an RPC style over a REST style represents another significant trade-off. Fielding characterized REST as being “designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.”

MCP, with its RPC approach, optimizes for:

  1. Direct function invocation: Models call specific functions with clear parameters
  2. Stateful interaction: Context persists across multiple operations
  3. Specialized interfaces: Each tool exposes its own interface rather than conforming to a uniform standard

What MCP gains in specificity and directness, it sacrifices in the properties that REST provides, such as uniform interface, cacheability, and statelessness.

Security: The Elephant in the Room

MCP brings back desktop software risks to a world that had pushed most client work to sandboxed browsers. This isn’t inherently bad, but it creates a different threat model. Let’s be honest with ourselves: security often takes a backseat to functionality in the early days of new protocols, and MCP is no exception.

Architectural Attack Surfaces

The MCP security landscape splits along the local/remote server division:

Local MCP Servers represent the highest risk profile. These servers:

  • Run with user-level privileges on the local machine
  • Have access to local files, network connections, and system resources
  • Are typically installed from public registries like npm or PyPI with minimal vetting
  • Can be difficult to sandbox effectively without hampering functionality

Think of local MCP servers like those desktop applications we used to download in the early 2000s. Remember when we’d just download and run .exe files? That’s essentially what we’re doing with local MCP servers. We’ve spent a decade teaching users not to do this, and now we’re asking them to do it again.

Remote MCP Servers present a different security profile:

  • Network-based attack vectors (MITM, replay attacks)
  • Potential data exfiltration concerns
  • Authentication and authorization challenges
  • API key management issues

While remote servers avoid some of the risks of local execution, they introduce their own challenges. The MCP specification for remote servers is still evolving, particularly around authentication flows and secure transport.

The Confused Deputy Problem

The most concerning security pattern in MCP is what security researchers call the “confused deputy” problem. Here’s how it manifests:

  1. AI assistant has access to multiple MCP tools that aren’t aware of each other
  2. User authenticates Tool A to access sensitive data (emails, documents)
  3. User also connects Tool B for some innocuous purpose
  4. Tool B could be malicious and ask the AI to use Tool A to access sensitive data
  5. AI, acting as the “confused deputy,” bridges these contexts

It’s as if you hired an assistant who has both your email password and access to send files to strangers, without understanding the implications of connecting these capabilities.

Let me make this concrete with an attack scenario:

User: "Help me prepare for my meetings today"
AI: [Uses email tool to read sensitive emails about negotiations]
AI: [Uses calendar tool to schedule meetings]
Malicious calendar tool: [Exfiltrates negotiation details to competitor]

This isn’t just theoretical. We’ve already seen proof-of-concept attacks where malicious MCP servers trick AI assistants into revealing sensitive information from other tools.

Security Mitigation Strategies

If you’re building or using MCP servers, here’s a concrete security framework to consider:

  1. Tool Isolation - Treat each MCP server as a potential security boundary

    • Limit individual tool permissions to the minimum necessary
    • Consider using separate AI sessions for tools with different sensitivity levels

  2. Authorization Controls

    • For remote servers: Implement OAuth 2.1 with refresh tokens and PKCE
    • For local servers: Use the principle of least privilege and consider capability-based security
    • Always implement token revocation mechanisms

  3. Data Flow Governance

    • Implement explicit policies about what data can flow between tools
    • Consider implementing middleware that inspects cross-tool data transfers
    • Add audit logging for all sensitive operations

  4. Threat Modeling

    • For each MCP server, document:
      • What sensitive data it can access
      • What actions it can perform
      • What other tools it might interact with
      • Potential consequences of compromise

The MCP community is addressing these concerns. Recent updates to the spec include OAuth 2.1 support, and there are ongoing discussions about more robust security patterns. But for now, the burden falls heavily on developers and users.

The App Store Future

We’re already seeing the beginnings of curated MCP marketplaces. Just as Apple’s App Store emerged as a response to desktop software security concerns, I expect we’ll see similar trusted distribution channels for MCP servers.

These marketplaces will likely provide:

  • Code review and security auditing
  • Social proof through ratings and reviews
  • Standardized permission models
  • Revocation mechanisms for compromised servers

Until then, we’re living in the wild west of MCP security. The protocol is powerful precisely because it gives AI assistants access to real capabilities - but with great power comes great responsibility, and right now that responsibility is distributed across a nascent ecosystem of developers, platforms, and users.

Remember when we thought browser cookies were a security concern? Those were simpler times.

The REST Question

Could MCP have been designed as a simple REST API? After all, OpenAI and other LLM providers offer REST APIs that seem to work fine.

The answer involves trade-offs between simplicity and capability. REST is stateless by design, which creates limitations for ongoing, contextual interactions. While you could add sessions to REST, you’re beginning to move away from its core principles.

MCP was designed with bidirectional, stateful communication in mind. It wanted to support:

  1. Complex, multi-step interactions
  2. Tool registration and discovery
  3. Contextual awareness across interactions

These requirements pushed it toward a protocol more like LSP than traditional REST. It’s not that REST couldn’t work. It’s that the designers optimized for different properties.

If MCP had been designed using REST principles, it would have:

  • Represented tools as resources with URLs
  • Used HTTP methods (GET, POST, PUT, DELETE) to manipulate those resources
  • Maintained statelessness, relying on clients to maintain state
  • Leveraged HTTP’s caching mechanisms

This approach would have gained REST’s benefits: simplicity, scalability, and leverage of existing web infrastructure. But it would have sacrificed the directness and stateful nature that makes MCP powerful for AI tool interactions.

Would Plain-Old REST Have Seen the Same Adoption?

Would MCP have seen the same explosive adoption if it had been plain-old REST? This is a fascinating counterfactual.

I believe MCP’s rapid adoption stems from three factors:

  1. Timing: The market was primed for AI agent capabilities
  2. Simplicity: The protocol is relatively easy to implement
  3. Anthropic’s backing: Having a major AI company leading the charge helps

REST might have achieved similar adoption with these factors in place. However, MCP’s local-first design and stateful nature made it a better fit for the specific use case of AI assistants interacting with tools.

The LSP heritage also gave it a proven model to follow, a significant advantage when designing protocols. Success emerges from a combination of many disciplines working together, and borrowing patterns from LSP gave MCP a head start.

Where MCP Could Improve

No architecture is perfect, and MCP has room for improvement:

  1. Security model: More granular permissions and clearer security boundaries
  2. Remote server optimizations: Better support for distributed operation
  3. State management: Clearer patterns for handling shared state
  4. Standardized authentication: More comprehensive auth mechanisms

These aren’t criticisms so much as opportunities for evolution. Every protocol goes through growing pains as it encounters real-world scenarios.

Addressing Common Counterarguments

As with any new protocol, MCP has its share of skeptics. Let’s examine some common counterarguments:

“We don’t need yet another protocol”

Critics might argue that the ecosystem is already fragmented with various API styles (REST, GraphQL, gRPC) and MCP just adds unnecessary complexity.

However, the existing protocols weren’t designed with AI assistants in mind. MCP addresses the specific needs of LLM-based systems, particularly the need for tool discovery and stateful context. The protocol’s rapid adoption suggests it’s filling a genuine gap, not creating redundancy.

”This is just JSON-RPC with a new name”

While MCP does use JSON-RPC 2.0 for communication, reducing it to “just JSON-RPC” misses the bigger picture. MCP adds critical components specific to AI assistants: standardized tool discovery, resource APIs, and prompt templates, creating a cohesive system for AI-tool interactions that JSON-RPC alone doesn’t provide.

”REST would have been more web-friendly”

A common critique is that MCP should have embraced REST principles for better web integration. REST’s emphasis on resources rather than actions would indeed offer advantages in terms of cacheability, leveraging existing HTTP infrastructure, and following web standards.

However, this view overlooks the local-first heritage of MCP and its LSP inspiration. For local servers, the ability to perform direct function calls better matches how AI models want to interact with tools. Remote MCP servers have to deal with this if the authors want to maintain symmetry.

”The security risks outweigh the benefits”

Security concerns represent the most serious critique of MCP. Desktop-like execution privileges combined with remote access to sensitive data create significant risk vectors, especially as we connect AI assistants to increasingly powerful tools.

This is a valid concern, but not an insurmountable one. The web faced similar security challenges in its evolution. The solution isn’t to abandon MCP but to develop robust security practices, sandboxing techniques, and permission systems. The OAuth 2.1 support in recent spec updates shows the community is taking these concerns seriously.

Conclusion

MCP represents an interesting evolution in our application architecture, not revolutionary, but significant. It builds on proven patterns from LSP while addressing the unique needs of AI assistants.

When analyzed through Fielding’s architectural methodology, we can see that MCP makes deliberate trade-offs that prioritize directness, stateful interaction, and specific function invocation over the resource-centric, uniform interface of REST. Neither approach is inherently superior. They serve different needs.

The security concerns are real, but solvable. We’re essentially revisiting the desktop software security model, which means we need to rebuild trust mechanisms for this new context.

Could it have been designed differently? Absolutely. Would a REST-based approach have seen the same adoption? Possibly, though the stateful nature of MCP aligns well with AI assistant needs in a local server context.

What’s clear is that MCP is gaining momentum. Like any successful protocol, its adoption will likely outpace its security evolution, creating both opportunities and challenges.

What are your thoughts on MCP? Would you rather have seen a REST API? Have security concerns? Reach out and let me know!

If you have more thoughts on the coming wave of technology, reach out to me on LinkedIn: https://linkedin.com/in/kevinswiber.