Reimagining the Model Context Protocol

This is follow up post after my first blog on model context protocol

The Model Context Protocol (MCP) has been instrumental in connecting AI models to real world via (tools,resources etc) , but what if we fundamentally reimagined it through the lens of REST architecture?

 Today, I'm proposing an alternative approach that leverages the proven patterns of RESTful design to create a more intuitive, scalable, and web-native solution. 

By treating AI capabilities as resources that can be uniformly addressed, manipulated, and discovered through standard HTTP methods, we can eliminate the complexity of the current JSON-RPC approach while gaining the benefits of caching, statelessness, and the vast ecosystem of tools built for REST APIs. This isn't just a technical refactoring—it's a philosophical shift that could make AI context management as approachable as browsing the web.

Little Recap on MCP

You can always read  model context protocol to learn more about MCP, but this is what it is at high level.

Trade-off when Comparing MCP (JSON-RPC Based) with a REST-Based Approach

1. Lack of resource-oriented modeling in current MCP
2. Non-standard interface semantics compared to HTTP methods
3. Limited built-in caching capabilities
4. Mixed stateful and stateless interaction patterns
5. Explicit versioning requirements rather than content negotiation
6. Need for specialized tooling instead of leveraging existing REST ecosystem
7. Custom error handling instead of standard HTTP status codes
8. Potential challenges with bidirectional communication in REST
9. Higher implementation complexity for developers
10. Limited self-discovery capabilities without hypermedia controls

What does REST based MCP looks like 

What are Key Benefits of REST based approach

This REST-based architecture offers:

• Simplicity: Familiar REST patterns reduce learning curve
• Discoverability: Self-documenting API with hypermedia controls
• Scalability: Stateless design enables horizontal scaling
• Caching: Efficient HTTP cache utilization
• Standards Compliance: Leverages established web standards
• Ecosystem Integration: Works with existing API infrastructure

Version of API spec is available at apispec.md

Conclusion

As we wrap up this exploration of architectural alternatives for the Model Context Protocol, it's clear that a RESTful approach offers compelling advantages over the current JSON-RPC implementation. 

By embracing HTTP's native semantics, resource-oriented design, and the vast ecosystem of tools built for REST APIs, we can create a more intuitive, discoverable, and web-friendly protocol. 

While some bidirectional communication patterns might require additional consideration, the benefits of standardisation, caching, and developer familiarity make REST a natural evolution for MCP. 

As AI systems continue to integrate more deeply with the broader software ecosystem, aligning our protocols with established architecture principles isn't just a technical choice—it's a strategic one that will lower barriers to entry and accelerate innovation in AI models integration.

 

Model Context Protocol - Old wine in new bottle

 

Inspirations Behind the Model Context Protocol

Model Context Protocol appears to draw inspiration from several established protocols and architectural patterns in software engineering. Some of the key inspirations and the concepts MCP has adopted from them:

The brilliance of MCP is in how it combines these inspirations into a cohesive protocol specifically designed for the unique challenges of LLM context integration. Rather than reinventing the wheel, it takes established patterns that have proven successful in other domains and adapts them to the emerging requirements of AI applications.

What makes MCP unique is its focus on the specific needs of LLM applications, including:

• Clear security boundaries for sensitive data
• Standardised resource descriptions optimised for LLM consumption
• Bidirectional sampling capabilities that enable agentic patterns

Combination of established patterns with AI-specific requirements creates a protocol that feels familiar to developers while addressing the novel challenges of LLM integration.

What is the Model Context Protocol?

Model Context Protocol is a JSON-RPC based protocol designed to standardize communication between AI models and external systems. It enables AI models to access contextual information, tools, and resources from different providers through a unified interface. MCP essentially serves as a bridge, allowing models to extend their capabilities beyond their core training.

Key Parties in MCP

MCP involves two primary parties:

1. Client - Typically represents the AI model or the application hosting the model. The client initiates connections, makes requests for information, and may also receive requests from the server.
2. Server - Provides resources, tools, and contextual information that the client can access. Servers can be specialized providers of specific functionality or broader ecosystem components.

Core Concepts in MCP

Key Parties in MCP

MCP Workflow

How does tools work

Tool is key abstraction in MCP that connect LLM to real world and give it capability to have information from outside world and also to take action.

Tool matching 

You might have question how what happens before tool invocation. How does LLM select which tool to use, now this could be very specific to underlying LLM but it will use some algorithm based on few core ideas.

Conclusion

Model Context Protocol (MCP) has captured widespread attention, highlighted by Google's recent Agent-2-Agent protocol release. The buzz around this is palpable, with LLM tools and companies making significant investments, anticipating it as the next major leap in Generative AI with the potential to unlock numerous use cases for working with Large Language Models.

While MCP undoubtedly solves an important integration challenge for LLMs, the fundamental question remains: what capabilities will these MCP servers or other implementations actually expose in terms of manipulating and enriching the interaction with LLMs? If these capabilities address only trivial or low-impact problems, our focus should arguably be on leveraging these transformative technologies to build truly innovative ("zero to one") capabilities that fundamentally change how we work with LLMs, rather than simply creating new interfaces for existing ones. 

So, the answer to my question about "old wine in a new bottle" is yes. The bottle is indeed shiny, creating a strong desire for it, much like the latest tech gadget.