MCP Agent: Bridge Claude and Ollama

What is the Model Context Protocol?

The Model Context Protocol is an open standard for connecting AI models to external tools and data. Anthropic open-sourced it in November 2024. By 2026 it had become the default integration layer for agentic AI, with native support across Claude, ChatGPT, Gemini, Copilot, and Cursor.

Think of it as "USB-C for AI": one universal connector in place of bespoke, per-model integrations.

The problem MCP solves: before MCP, connecting a model to your tools meant writing custom code for each model and tool pairing. One adapter for OpenAI's function schema, another for Claude, another for a local model. That is the N×M integration problem: as models and tools multiply, the glue explodes.

MCP collapses it into N+M. Build a tool as an MCP server once, and any MCP client can call it.

How MCP works: hosts, clients, servers

MCP has a small, clear architecture. Three words carry it:

• Host: the AI application the user interacts with (Claude Desktop, Claude Code, Cursor, or your own app).
• Client: the connector inside the host that opens a session to a server and calls its tools.
• Server: the process that exposes capabilities (a filesystem tool, a GitHub tool, a database tool).

Communication runs on JSON-RPC 2.0. Every interaction is a request/response pair or a one-way notification.

The MCP primitives

A server offers:

• Tools — executable actions the model can call.
• Resources — read-only data the host can load.
• Prompts — reusable templates the server provides.

A host offers back:

• Sampling — lets a server ask the host's model to generate a completion, enabling recursive agents.
• Roots — scopes the server to specific directories.
• Elicitation — lets a server request more input mid-task.

The two transports

• stdio: the server runs as a local subprocess of the host. Most local developer setups use this.
• Streamable HTTP: for remote servers over HTTPS. It replaced the older HTTP+SSE transport, which is now deprecated.

Rule of thumb: use stdio when the client can launch the server on the same machine. Use Streamable HTTP for remote or SaaS servers, and add origin checks, authentication, and explicit approval for sensitive actions.

What changed in the July 2026 spec

If you are building today, you are building across a transition. The 2026-07-28 specification is the largest revision since launch:

• Stateless protocol core. Servers scale on ordinary HTTP infrastructure (load balancers, autoscaling, serverless) instead of holding a session per connection.
• Tasks. Long-running, asynchronous work: dispatch a job, poll for completion. Essential for always-on agents.
• MCP Apps. Server-rendered UI, so a server can return interactive interfaces, not just text.
• Authorization hardening and a formal deprecation policy.

This release contains breaking changes, so confirm the current spec status before upgrading.

The takeaway: local stdio servers remain fully valid and are the right place to learn. When you go remote and need horizontal scaling, design for the stateless Streamable HTTP path.

What you'll build

Two things, sharing one set of tools. A filesystem MCP server driven by Claude, and the same server driven by a local Ollama model through a bridge, so nothing leaves your machine. Then a tiny custom server exposing one typed tool, so you see the contract end to end.

Step 1. Run a filesystem MCP server

The filesystem server is the "hello world" of MCP. It lets a model read, write, and search files inside a directory you choose, and nothing outside it. It is part of the official MCP servers collection, and npx fetches and runs it with no global install:

npx -y @modelcontextprotocol/server-filesystem /path/to/your/project

That single command is the whole server. Next, connect a host to it.

Step 2. Drive the server from Claude

Register the server in your host's config. In Claude Desktop, the config file lives at:

• Windows: %APPDATA%\Claude\claude_desktop_config.json
• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Add the server, then restart the app:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/your/project"]
    }
  }
}

Restart, and Claude can list, read, and write files in that directory on request. This same config shape works across MCP hosts, including Claude Desktop, Cursor, and Cline.

Step 3. Drive the same server from a local Ollama model

Here is the payoff of a model-agnostic standard: MCP servers do not care which model calls them. So anything that works with Claude also works with a local Ollama model through a bridge.

Ollama does not speak MCP natively, so you use a client that does. mcphost is a Go MCP client that speaks Ollama directly:

# 1) Install the MCP client.
go install github.com/mark3labs/mcphost@latest
# 2) Pull a tool-capable local model.
ollama pull qwen2.5:14b
# 3) Point mcphost at the SAME MCP config from Step 2.
mcphost -m ollama:qwen2.5:14b --config ./mcp.json

Your local model now uses the identical filesystem tool, with no cloud tokens and no data leaving the machine.

Which local models work with MCP?

Tool selection is where small models fall down. As a rule, use models of 7B parameters or larger for reliable MCP tool calling. Smaller models often pick the wrong tool, emit malformed calls, or lack a tool-calling chat template entirely.

A 14B-class model such as qwen2.5:14b runs comfortably on a 12 GB+ GPU and handles multi-tool selection well.

Step 4. Build your own MCP server (one typed tool)

To understand the contract, expose a single tool yourself. The Python SDK's FastMCP makes this short:

# server.py, a minimal MCP server exposing one typed tool over stdio.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("modelrefs-demo")
@mcp.tool()
def token_estimate(text: str) -> int:
    """Rough token estimate (~4 chars per token).
    Swap in a real tokenizer for production use."""
    return max(1, len(text) // 4)
if __name__ == "__main__":
    mcp.run()  # JSON-RPC 2.0 over stdio

Register it exactly like the filesystem server:

{
  "mcpServers": {
    "modelrefs-demo": {
      "command": "python",
      "args": ["/absolute/path/to/server.py"]
    }
  }
}

Where MCP agents break

An honest tutorial names the failure modes. These are the three that bite most often.

1. Multi-turn tool use. Simple one-shot tool calls work well through bridges. Multi-turn flows — where the model receives a tool result and must then decide the next call — are where bridges most often break.
2. Small-model unreliability. Sub-7B models pick the wrong tool too often for production. Size up, or keep the tool surface tiny and unambiguous.
3. Tool poisoning. The protocol lets an agent act on your behalf, which is exactly why untrusted servers are dangerous. A malicious server can hide instructions inside a tool's description or parameters to steer the model into unintended actions. See our guide to MCP security and tool poisoning.

Security checklist

• Scope the filesystem server to a single project directory, never your home folder.
• Prefer stdio locally. Everything stays on one machine, with no network surface.
• For remote (Streamable HTTP) servers, require authentication, verify request origins, and gate sensitive actions behind explicit user approval.
• Treat third-party tool descriptions as untrusted input.
• Log the JSON-RPC traffic while developing, so you can see exactly what the model called and with what arguments.

Sources and further reading

• Model Context Protocol specification — the authoritative spec for hosts, clients, servers, transports, and primitives.
• MCP introduction — official overview of the protocol architecture and design goals.
• MCP servers collection — the official repository of reference MCP servers, including the filesystem server used in this tutorial.
• mcphost — the Go MCP client used to bridge Ollama to MCP servers.
• What is tool calling? — the model capability that MCP standardizes.