DEV Community

Raj Kundalia
Raj Kundalia

Posted on

Understanding Model Context Protocol (MCP): Beyond the Hype

#mcp #ai #llm

As always, I have created code repositories which will be easier to understand; also, resources much better than what I have here are added at the bottom:
MCP Book Library: https://github.com/rajkundalia/mcp-book-library
MCP Toolbox: https://github.com/rajkundalia/mcp-toolbox

As software engineers, we were and are witnessing a fragmentation problem in the AI ecosystem. Every major model provider (Anthropic, OpenAI, Google) and every tool (Linear, GitHub, Slack) has its own proprietary integration pattern. If you want Claude to talk to your PostgreSQL database, you write a specific integration, and if you switch to GPT-5, you rewrite it.

This “m × n” integration problem — where m models need to connect to n tools — is creating an exponential explosion of custom code. It is one of the primary bottlenecks preventing LLMs from becoming true agents.

Enter the Model Context Protocol (MCP).

MCP-image

What Is MCP?

The Model Context Protocol is an open standard that defines how AI models interact with data and tools. Think of it as a “USB-C port” for AI applications.

In short, MCP removes the need for bespoke integrations between every tool and every AI model. Instead of building a specific connector for every data source to every AI model, MCP provides a universal protocol.

If a tool is “MCP compliant,” any MCP client (like Claude Desktop, Cursor, or Zed) can instantly connect to it without custom glue code.

Why MCP?

The value proposition is decoupling.

  • For tool builders: You build one MCP server for your API. It now works with Claude, Cursor, and any future MCP-compliant application.
  • For AI app developers: You build your host application once and gain access to the entire ecosystem of MCP servers (Google Drive, Slack, PostgreSQL, etc.).
  • For end users: You can switch between AI providers without losing access to your tools.

This solves the m × n problem by reducing it to m + n. The math alone makes the case compelling.

How MCP Works Architecturally

The architecture relies on a triangle of roles. The “Client” is often hidden inside the application you are using.

  • MCP Hosts: The user-facing application (e.g., Claude Desktop, Zed, or a custom dashboard). The Host orchestrates the flow, manages the UI, and contains the LLM.
  • MCP Clients: The bridge (often a library) embedded within the Host. It maintains the connection with the Server, negotiates capabilities, and routes requests.
  • MCP Servers: Where your custom logic lives. A server wraps a capability (Postgres, file system, REST API) and exposes it via standardized primitives.

image2

Core MCP Primitives

When you write an MCP server, you are generally exposing one of these three capabilities.

  • Resources: Passive data. The client asks to “read” a URI (for example, postgres://logs/latest). These are analogous to file reads—informational only.
  • Tools: Executable functions, allowing the LLM to take action (for example, execute_sql_query, send_slack_message).
  • Prompts: Reusable context. A server can define a template (for example, “Analyze Error Logs”) that the host loads to jumpstart a conversation.

Capability Discovery and Schemas

A critical part of the protocol is discovery. When a client connects, it asks the server, “What can you do?” and the server responds with a list of tools and resources, including JSON Schemas for arguments.

This is how the LLM knows exactly which parameters (for example, isbn: string) are required to call a tool, enforcing type safety at the model level.

Why JSON-RPC 2.0?

MCP uses JSON-RPC 2.0 for its wire protocol, and this choice maps naturally to the problem space.

  • Bidirectional: JSON‑RPC supports both requests and notifications from either side over a single logical session, which maps cleanly onto long‑lived transports like stdio or streaming HTTP.
  • Session-based: MCP sessions are often long-lived. JSON-RPC handles this persistent state naturally without the overhead of stateless HTTP headers for every interaction.
  • Transport agnostic: The message shape remains identical whether piped over local stdio (for local dev) or SSE/WebSockets (for remote deployment).

Example: A Full MCP Flow

User: “Check the library database for book availability for ISBN 12345.”

Host (LLM): Recognizes the intent and asks the client to find a relevant tool.
Client: Identifies check_availability via discovery and sends a JSON-RPC request:

{
  "method": "tools/call",
  "params": {
    "name": "check_availability",
    "arguments": { "isbn": "12345" }
  }
}
Enter fullscreen mode Exit fullscreen mode

Server: Receives the request, runs the query, and returns:

{
  "result": {
    "content": [
      { "type": "text", "text": "Available: 5 copies" }
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

Host: Feeds this back into the LLM context window.
LLM: Responds: “Good news! There are 5 copies available.”

Advanced Mechanisms: Sampling and Roots

MCP extends beyond simple API calls with features that enable sophisticated interaction.

  • Sampling: Enables the server to delegate complex tasks back to the host. During the execution of a tool, the server can effectively say, “Hey LLM, I need your brain for a second,” and request the host to generate text or analyze code.
  • Roots: A security boundary mechanism. A server can declare boundaries (for example, “I only have access to /var/www/project”), preventing access to files or resources outside a specific scope.

Real-Time Updates and Transports

Unlike standard APIs where the client must poll for changes, MCP supports server-initiated notifications.

Once a session is established, a server can send streaming responses and JSON‑RPC notifications without additional polling. For example, a filesystem server can notify the host immediately when a watched file changes, or a long-running build process can stream log lines as they appear.

This is supported across the main standard transports.

  • stdio: For local processes (ideal for desktop apps like Cursor).
  • SSE (Server-Sent Events): For remote servers sending updates to clients.
  • Custom transports: The protocol is extensible to additional carriers like WebSockets; draft proposals already explore this on top of the existing HTTP/streaming model.

Is MCP a Silver Bullet?

MCP solves the integration problem, but it is not a magic fix for every scenario.

Use it when you:

  • Need interactive AI–tool integrations
  • Expect multiple AI models to use the same tools
  • Have tooling that evolves frequently

Avoid it when you:

  • Have a simple one-off integration
  • Run large batch jobs without interaction
  • Care about latency more than flexibility

Production Challenges

While the local development story is fantastic, moving to production introduces complexity.

1. The Scaling Challenge

In development, a “one host process → one server process” model via stdio works well. In production, this naive 1:1 model does not scale, because you cannot spawn a new database connection process for every one of 10,000 concurrent users.

The solution: Production architectures use MCP gateways, which sit between clients and servers to handle connection pooling and multiplex many logical sessions over fewer physical connections.

2. Security and Auth

MCP defines the transport, but it does not strictly mandate how you authenticate. In a remote setup, you need to secure the transport layer (for example, via headers in SSE).

Because MCP servers can execute code or read files, strict roots configuration and containerization are essential to prevent privilege escalation.

3. Debugging and Observability

Debugging streaming JSON‑RPC over a long‑lived transport can be opaque. Unlike REST, where you have discrete HTTP logs, MCP is a stream of messages.

Production implementations require robust tracing (for example, correlation IDs) to track a request as it hops from Host → Gateway → Server and back.

Final Thoughts

The Model Context Protocol represents a meaningful step toward standardizing AI-to-tool communication. While Anthropic seeded the ecosystem, there is now broad adoption across open-source tools, IDEs, and infrastructure providers.

However, treat it as a protocol, not a magic solution. It requires ecosystem adoption and careful architectural planning for production scale.

Example MCP Implementations

To explore MCP in practice, here are the implementation repositories built while learning the ecosystem:

These projects demonstrate MCP servers and integrations for realistic data sources and workflows.

Why Use mcp Over fastmcp?

Short version:

  • Use mcp (official) if you want to learn the architecture, build custom clients/hosts, or manually configure the HTTP/SSE layers (which is exactly what many project prompts ask for).
  • Use fastmcp if you just want to ship a tool to Claude Desktop in a few minutes and do not care how the wiring works under the hood.

The best way to understand MCP is to build with it. Start small, implement a simple server for a data source you use regularly, and compare the experience to traditional point-to-point integrations.

Resources That Helped

Some resources that helped deepen understanding of MCP and its ecosystem:

Top comments (0)