Anthropic Model Context Protocol: How to give wings to local mode

Anthropic just released their Model Context Protocol (MCP), an open-source standard that’s about to transform how AI models work with local data. Think of it as giving wings to AI models running on your machine – they can now securely access your files, databases, and tools without sending anything to the cloud. Whether you’re using Claude, open-source models like Llama, or building your own AI applications, MCP is a game-changer. Let’s dive deep into what it is, how it works, and why it’s going to make local AI much more powerful and practical.

What is MCP and Why Does it Matter?

Imagine you have a super-smart AI assistant (like Claude), but it’s locked in a room with no access to your files, databases, or tools. Every time you want it to access something new, you need to build a custom door. That’s the current state of AI – models are powerful but isolated from real-world data and tools.

MCP solves this by creating a standard way for AI models to connect to external resources. It’s like creating a universal adapter that works with any data source or tool. No more building custom integrations for each new connection!

What’s more is that this is an open source protocol which means that it will work not only with Claude but with Open Source agent systems!

How MCP Works: The Technical Details

Let’s dive deep into how MCP actually works under the hood. At its core, MCP uses a client-server model with standardized communication protocols, but what makes it special is how it brings everything together to create a seamless bridge between AI models and external resources.
You can find the official documentation here.

Core Architecture

The foundation of MCP rests on three main components working in harmony. First, we have host applications like Claude Desktop that want to access external resources. These hosts work through MCP clients, which live inside the application and handle all the nitty-gritty details of maintaining connections with servers. Finally, we have MCP servers – lightweight services that expose various resources and capabilities to the clients.

Think of it like a well-organized office where the host application is the executive (Claude), the MCP client is their assistant, and each MCP server is a department head managing specific resources. When the executive needs something, they don’t need to know all the internal processes – their assistant handles all the communication and protocols.

flowchart TB
    Host["Host (Claude Desktop)"]
    Client["MCP Client"]
    
    Server1["MCP File System Server"]
    Server2["MCP Database Server"]
    Server3["MCP GitHub Server"]
    
    Files["Local Files"]
    DB["Local Database"]
    Git["Git Repositories"]
    
    Host -- "Requests" --> Client
    
    Client -- "File Requests" --> Server1
    Client -- "Query Requests" --> Server2
    Client -- "Code Requests" --> Server3
    
    Server1 -- "Access" --> Files
    Server2 -- "Access" --> DB
    Server3 -- "Access" --> Git
    
    Files -- "Return Data" --> Server1
    DB -- "Return Data" --> Server2
    Git -- "Return Data" --> Server3
    
    Server1 -- "Results" --> Client
    Server2 -- "Results" --> Client
    Server3 -- "Results" --> Client
    
    Client -- "Combined Response" --> Host

Communication Protocol

MCP uses JSON-RPC 2.0 for all its communications, which might sound technical but it’s really just a standardized way of sending messages back and forth. When a client needs to request something, it sends a structured message that looks something like this:

jsonCopy{
  "jsonrpc": "2.0",
  "method": "read_resource",
  "params": {
    "uri": "file:///path/to/resource"
  },
  "id": 1
}

Sometimes, servers need to send updates without expecting a response – like letting the client know about progress on a long-running task. These one-way messages are called notifications. The server can also send back responses with requested data or error messages if something goes wrong.

The Communication Dance

When an MCP client and server first connect, they go through a careful choreography. The client starts by introducing itself and sharing what it can do. The server responds with its own capabilities, and once they’ve established this common ground, they’re ready to start working together. This careful initialization ensures that both sides know exactly what to expect from each other.

sequenceDiagram
    participant Host as Host (Claude)
    participant Client as MCP Client
    participant Server as MCP Server
    participant Resource as Resource (DB/Files)
    
    Note over Host,Server: Connection Initialization
    Host->>Client: Initialize connection
    Client->>Server: initialize request (with capabilities)
    Server->>Client: initialize response (supported features)
    Client->>Server: initialized notification
    
    Note over Host,Server: Active Communication
    Host->>Client: Request resource
    Client->>Server: read_resource request
    Server->>Resource: Access resource
    Resource->>Server: Return data
    Server-->>Client: Progress notification (optional)
    Server->>Client: Response with data
    Client->>Host: Deliver result
    
    Note over Host,Server: Clean Termination
    Host->>Client: Close connection
    Client->>Server: shutdown request
    Server->>Client: shutdown complete
    Client->>Host: Connection closed

After the initial handshake, MCP goes through a discovery process where the client learns exactly what the server can do. The server tells the client about:

1. Resources: What data sources it can access (files, databases, APIs)
2. Tools: What operations it can perform (queries, transformations, API calls)
3. Features: What specific capabilities are available (read, write, execute)

This way, the host knows exactly what it can request from each server. For example, some servers might be read-only, while others might allow both reading and writing. Some might support real-time updates, while others might only support basic queries.

It’s like when you first connect to a new service – before you start using it, you need to know what features are available to you. This negotiation ensures that the host never tries to request something the server can’t provide.

MCP supports two main ways of moving data between clients and servers. For local connections (like when everything’s running on your computer), it uses standard input/output – it’s fast and efficient because there’s no network overhead. For remote connections, it uses HTTP with Server-Sent Events, which allows for secure, two-way communication over the internet.

MCP servers provide both passive resources (like access to files or databases) and active tools (like the ability to process data or call external APIs). Each server decides what it wants to expose and how to handle requests for its resources. It’s like each server is a specialized department with its own expertise and tools.

Keeping Things Secure

Let’s talk about how MCP keeps things secure – it’s actually pretty interesting when you dig into it. Think of MCP like a super secure building where every department has its own isolated room, and they can only talk to each other through special secure channels.

When an MCP server starts up, it’s like putting it in its own protective bubble – if something goes wrong with one server, it can’t mess with anything else on your system. Here’s what makes it work:

• Each server is locked in its own secure space (nerdy term: process isolation)
• Servers can only access what they’re explicitly allowed to
• Everything is encrypted, even when it’s just talking to itself on your machine
• There’s a detailed log of who tried to access what (like security cameras)

The cool thing about this setup is that you can let AI models access your local stuff without worrying about them getting into things they shouldn’t. It’s like giving someone a special key that only works for specific doors – they can do their job, but they can’t wander into restricted areas.

Error Handling

Things don’t always go perfectly, and MCP is prepared for that. When something goes wrong, servers can send back detailed error messages that help pinpoint the problem. These aren’t just generic “something broke” messages – they include specific error codes and helpful descriptions that make debugging much easier.

This whole system comes together to create something pretty powerful: a way for AI models to securely and efficiently interact with all sorts of external resources. Whether it’s reading files, querying databases, or calling APIs, MCP provides a standardized way to make it happen while keeping everything secure and organized.

The beauty of this design is its flexibility – new servers can be added to handle new types of resources without changing how anything else works. It’s like being able to add new departments to our office without having to reorganize the whole company. This makes MCP not just powerful today, but ready for whatever new capabilities we might want to add tomorrow.

MCP Servers as Local LLM Agents: Understanding the Parallel

MCP shares an interesting parallel with LLM agents – both are ways of giving AI models the ability to interact with external tools and data. But while traditional LLM agents work in the cloud, MCP brings these capabilities to your local environment. Let’s explore this connection

Traditional LLM agents use function calling to interact with tools. An agent might have functions like search_web(), calculate_numbers(), or fetch_weather(). When the LLM needs information, it calls these functions and gets results back.

MCP works in a remarkably similar way, but instead of cloud-based function calls, it uses local servers that expose two main types of capabilities:

• Resources: Think of resources as the agent’s memory or knowledge base. Just like how an agent might have access to specific databases or documents

{
  "uri": "file:///documents/data.csv",
  "name": "Sales Data",
  "mimeType": "text/csv",
  "description": "Monthly sales records"
}

• Tools: Tools in MCP are surprisingly similar to agent function calls. Here’s what a tool definition might look like:

{
  "name": "query_database",
  "description": "Query the sales database",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "SQL query to execute"
      }
    }
  }
}

Key Differences between MCP and LLM agents

Let’s talk about how MCP is different from your typical LLM agents – there’s actually some pretty fascinating stuff going on under the hood. While both try to give AI models more capabilities, MCP takes a completely different approach that’s worth understanding.

The biggest differences? Here’s what makes MCP special:

• First off, everything runs locally on your machine. Unlike some service that would be deployed on the cloud and you would need api access to interact with it, here everything would run locally.
• Instead of every tool doing its own thing, MCP uses a standardized way of talking between components. This means you can take what the community makes and it is far easier to develop or maintain because you do not need to know Langflow or other frameworks.
• The whole architecture is different too. Instead of simple function calls, you’ve got this whole client-server setup. Sounds complicated? Maybe, but it means you can do things like handle multiple connections at once or stream data in real-time. Pretty neat stuff.
• Security is built different here. Instead of basic permissions, you’ve got multiple layers of protection. Each server runs in its own secure space, carefully controlling what can be accessed and how. The problem here would be limiting the agent or making sure it does not do stuff that you do not want (like deleting half your code …)

All of this adds up to a fundamentally different way of thinking about AI tools. Instead of trying to cram everything into the cloud, MCP brings the power to your local machine, and give a way for the community to develop a fully working but local agent system.

What I love about this approach is how it solves real problems that developers face when working with AI. No more worrying about sensitive data, no more dealing with cloud limitations – just powerful, local AI capabilities that work the way you need them to.

Conclusion

Here’s what makes MCP really exciting – it’s not just another proprietary protocol locked to specific AI models. Anthropic released MCP as an open-source standard, which opens up some pretty incredible possibilities for the entire AI ecosystem.

Think about it this way: while Claude Desktop might be the first major implementation, any AI application can use this protocol. Want to use local Llama models? Go for it. Prefer Mistral? No problem. The protocol doesn’t care which AI model you’re using – it’s all about creating a standard way for these models to interact with your local tools and data.

This open approach means developers can build MCP servers that work with any AI model that implements the protocol. You could have your favorite open-source LLM running locally, using the exact same tools and integrations that Claude uses. It’s like having a universal adapter that works with any AI model you throw at it.

Some practical examples of what this enables:

• Run Llama or Mistral models locally while using MCP to give them access to your files and databases
• Create custom tools that work seamlessly with both commercial and open-source AI models
• Build integrations once and use them with any MCP-compatible AI system

The open-source nature of MCP isn’t just about freedom of choice – it’s about creating a foundation for innovation. Developers can inspect, modify, and improve the protocol itself, without knowing about specific framework. They can create new types of integrations and share them with the community. Every improvement benefits the entire ecosystem, not just a single company’s products.

Afterwards

I hope you really loved this post. Don’t forget to check my other post as I write a lot of cool posts on practical stuff in AI.
Follow me on and and please leave a comment.