Rike Pool

What is Model Context Protocol (MCP)?

What is Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open standard that defines how AI models interact with external data and tools. It solves the “M × N” problem where every AI client (like Claude, ChatGPT, or an IDE) currently needs to build custom integrations for every data source (Postgres, Linear, GitHub).

Instead of a tangled web of bespoke API wrappers, MCP gives an AI a consistent JSON-RPC language to request data, trigger actions, and receive structured responses. This means your agent can access live company data or execute a workflow using a predictable, standardized method.

In short: MCP creates a universal USB-C port for AI apps. You build the connection once, and it works with any model that supports the protocol.

The Problem MCP Solves

Before MCP, we were stuck building separate integrations for every tool. If you have 10 models and 20 tools, you are looking at 200 point-to-point connections. It is a maintenance nightmare that slows down development.

MCP addresses specific engineering pain points:

  • Fragmented Integrations: Every new model traditionally required writing new connection code from scratch.
  • Static Knowledge: LLMs are trained on historical data. Getting live, real-time context (like today’s sales numbers) into them was messy.
  • Action vs. Retrieval: Many workflows need to do things, like send an email or update a database. Gemini 3 and the rise of Generative UI Agents shows how agents use these tools to plan and execute complex loops, but those loops need a standard way to call functions. MCP provides that standard.
  • No Interoperability: A lack of standards created friction between vendors. MCP introduces a common ground, much like how baseline web APIs unlocked new possibilities for browsers.

How MCP Works: The Code

At its core, MCP is a client-server architecture using JSON-RPC 2.0. The “Host” (your AI agent) sends requests, and the “Server” (your data wrapper) responds.

The Protocol Level

Here is what the actual wire protocol looks like when an agent asks to use a tool.

Request (Client -> Server):

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "Amsterdam"
    }
  }
}

Response (Server -> Client):

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Current weather in Amsterdam: 12°C, Cloudy."
      }
    ]
  }
}

Building a Server (Python)

You don’t have to parse JSON manually. The official Python SDK (mcp) simplifies this significantly. Here is how to build a working MCP server that exposes a simple tool.

Note: We use FastMCP from the official SDK for a cleaner API.

from mcp.server.fastmcp import FastMCP

# Initialize the server
mcp = FastMCP("Demo-Server")

# Define a tool using a simple decorator
# The type hints and docstring automatically generate the JSON schema for the LLM
@mcp.tool()
def add_numbers(a: int, b: int) -> int:
    """Add two numbers together."""
    return a + b

@mcp.tool()
def get_status(system_id: str) -> str:
    """Check the status of a specific system component."""
    # In a real app, this would query your DB or API
    return f"System {system_id} is OPERATIONAL"

if __name__ == "__main__":
    # Runs the server over stdio by default
    mcp.run()

When you connect this to an MCP client (like Claude Desktop or a custom agent), the model automatically sees add_numbers and get_status as available tools.

Sanity Check

I pulled the mcp repository to verify the FastMCP implementation above. Running the server locally works as expected: it binds to standard input/output (stdio) and waits for JSON-RPC messages.

This is a key architectural shift. As discussed in Softening the Stack, we are moving away from hard-coded API glue toward flexible runtimes where the protocol handles the complexity. The server doesn’t need to know which LLM is calling it; it just respects the contract.

Why This is Useful for Developers

For anyone building with AI, MCP offers practical leverage:

  • Write Once, Run Everywhere: You build one protocol interface for your internal database. It now works with Claude, OpenAI, and your internal custom agents.
  • Context Window Management: MCP supports “resources” (like file contents) and “prompts” (templates). The server manages fetching the data, so you don’t bloat your client code.
  • Security Boundaries: You can run the MCP server in a sandbox or separate container. The agent only talks to the socket, never touching the raw database credentials directly.

Security & Governance Considerations

Giving an AI the keys to your tools introduces risks.

  • Prompt Injection: A malicious prompt could trick an agent into calling delete_database() if you expose that tool.
  • Data Exposure: If an agent has access to “read_all_emails”, it will read them if asked.
  • Excessive Agency: As agents become capable of complex chains, limiting the scope of each tool is essential.

Best Practices:

  1. Read-Only by Default: Start with tools that only fetch data.
  2. Human-in-the-Loop: Require user confirmation for high-impact actions (like sending emails or deploying code).
  3. Strict Schemas: Use precise typing in your Python/TypeScript tool definitions. Don’t just accept Any.

FAQ

Q: How is MCP different from OpenAI’s Function Calling?

A: Function calling is a feature specific to a model API. MCP is a protocol that creates a standard way for any model to discover and use tools. It abstracts the specific “function calling” syntax of the underlying model.

Q: Who created MCP?

A: Anthropic open-sourced MCP in November 2024. It is now an open standard with contributions from companies like Block, Replit, and others.

Q: Can I use this in production today?

A: Yes. The SDKs for Python and TypeScript are stable. Major tools like Claude Desktop already support it, allowing you to connect local files and databases directly to the chat interface.

Q: Does MCP replace Retrieval-Augmented Generation (RAG)?

A: No, it powers it. You can build an MCP server that wraps your vector database. The agent uses the protocol to query the vector DB (RAG) dynamically when it needs information.

I spend most of my time building with this kind of tech. If you want to discuss MCP implementation, learn more about my work in AI engineering and automation.