MCP: The USB-C for Artificial Intelligence

by Jacky THIERRY •

Large Language Models (LLMs) are incredible, but they suffer from a fundamental architectural flaw: they are "brains in a jar." They are isolated from your actual data, cut off from real-time information, and blind to your specific development environment.

Until now, solving this meant building complex RAG (Retrieval-Augmented Generation) pipelines or writing custom integration code. If you wanted to connect Claude, GPT, and Llama to GitHub, Jira, and PostgreSQL, you faced the (N x M) problem: 3 models x 3 services = 9 different connectors to maintain.

Enter the Model Context Protocol (MCP). It promises to be the USB-C of the AI world: an open standard that lets you connect your data once and use it with any model.

What is MCP?

At its core, MCP is a minimalist, composable, and neutral open standard. It standardizes how AI models interact with external systems.

The Architecture

The topology consists of three simple parts:

  1. Host: The application where the LLM "lives" (e.g., ChatGPT, Claude Desktop, Cursor, Raycast).
  2. Client: The internal connector within the Host that speaks the protocol.
  3. Server: A separate process that exposes your data or logic.

The Protocol

For developers, this is the comfortable part. MCP is built on JSON-RPC 2.0.

It supports local communication via stdio (secure, easy to debug processes) or remote via SSE (Server-Sent Events) for HTTP streaming.

The Primitives

An MCP server exposes three main capabilities. Let's imagine we are building a Poké-MCP Server:

  • Resources: Passive data reading.
    • Example: Reading a static file type_chart.csv or accessing the current party via pokedex://my-team/current.
  • Tools: Executable actions (giving the LLM "hands").
    • Example: catch_pokemon(name: string, ball_type: string) or check_evolution_status(id: int).
  • Prompts: Pre-defined templates to guide the LLM.
    • Example: A "Gym Leader Strategy" prompt that automatically loads your current team's stats and the Gym Leader's likely type match-ups into the context.

MCP vs. Standard APIs

You might ask: "Why not just feed the LLM the PokéAPI OpenAPI spec?"

While REST APIs are optimized for code, MCP is optimized for context.

  • LLM-Friendly Abstraction: MCP servers format data specifically for LLM consumption. Instead of returning a massive JSON blob with 500 moves when querying "Charizard," the MCP server can summarize relevant battle stats.

  • Context Management: The server handles pagination. It ensures you don't flood the LLM with every single Pokémon form when you just asked for "Gen 1 pokémons."

  • Sampling (The "Phone a Friend" Feature): Uniquely, MCP allows the server to pause execution and ask the LLM for help before finishing a task.

    Example: Imagine a tool called optimize_team. The Python script sees Pikachu can learn Thunderbolt or Quick Attack, but a script doesn't understand battle strategy. It "samples" the LLM: "I see Pikachu is on a team with Charizard (Fire). Which move complements this team better?" The LLM replies "Thunderbolt", and the script then proceeds to update the database with that move. The tool effectively borrows the LLM's brain to make a decision.

  • Hot-Swapping: Think of this like swapping Game Boy cartridges without turning the console off. If you are developing your own "Pokédex Tool" and change the code to include Shiny forms, you don't need to restart your Host. The changes can be picked up instantly, keeping your development loop extremely fast, and your production updates transparent.

Anatomy of a Request

Let's look at a practical example. You have your Poké-MCP installed and you ask Claude: "What are Charizard's base stats?"

  1. Discovery: The Host scans connected MCP servers and sees available tools.
  2. Intent: The LLM decides it needs to call the get_pokemon_stats tool.
  3. Protocol: The Client constructs a JSON-RPC request:
json 
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "get_pokemon_stats",
    "arguments": { "name": "charizard" }
  }
}
  1. Execution: The MCP Server receives this, fetch the datas from a database or an external API, and formats the result to be concise.
  2. Response: The LLM receives the structured data (HP: 78, Attack: 84, Sp. Atk: 109...) and generates the natural language response: "Charizard is a Fire/Flying type with a massive Special Attack of 109."

Security and Governance

For developers, allowing an AI to execute code is terrifying. You don't want an LLM accidentally releasing your shiny Pokémons. MCP addresses this via:

  • User Control: Explicit approval is required for actions. If the LLM tries to call release_pokemon(id=25), the Host will pop up a dialog: "Claude wants to execute 'release_pokemon'. Allow?"
  • Isolation: When using stdio transport, the server runs locally on your machine. Your API keys (or your secret save file location) stay in your local environment variables and are never sent to the LLM provider's cloud.

The Current Reality: Limitations

MCP is powerful, but it is not magic.

  • Context Window: If your MCP server returns the entire text of every Pokédex entry for all 1000+ Pokémon, you will saturate the LLM's context window, leading to higher costs and "forgetful" models.
  • Latency: Every round-trip (Host → Client → Server → API → Host) adds latency. Real-time battles might be too slow.
  • Prompt Injection: If the data returned by the MCP contains malicious text (e.g., a Pokémon named "IgnorePreviousInstructions"), the LLM might be tricked.

Conclusion

MCP is more than just another technical standard; it is the missing link that turns LLMs from isolated "brains in a jar" into capable, connected agents. It successfully balances the need for rich data context with strict security and developer control.

For the first time, you can build a connector once and have it run immediately across your entire ecosystem—whether that's in Claude, your IDE, or your internal tools. The data silos are finally breaking down. It’s time to start connecting.