Skip to main content

Connect Claude to Local Tools & Agents with MCP

Intermediate

You want Claude to be the brain and your machine to supply the hands — read your files, query your database, run your script, even call a local model or a local agent, all without your data leaving the laptop. That synergy already has a standard: the Model Context Protocol (MCP). In one breath: MCP is an open standard that lets an AI client call external tools and data through small programs called MCP servers — and those servers can run privately, locally, on your own machine. This page shows what MCP is, how the local architecture fits together, how to add a local server to Claude, and how to build a tiny one of your own.

What you'll learn
  • Explain MCP in one sentence — an open standard so an AI client can call external tools and data via MCP servers
  • See the local architecture: an MCP client (Claude Code / Claude Desktop) talking to a local MCP server over stdio
  • Understand why this IS the Claude-as-brain + local-capabilities synergy you want
  • Add a local MCP server to Claude with one command
  • Build a tiny MCP server that exposes one tool
  • Know the trust boundary — MCP servers act with YOUR privileges, so install only what you trust

What MCP is (in one breath)​

MCP is an open standard for connecting AI applications to external systems. An AI client (like Claude) speaks one protocol; any MCP server that speaks it can plug in and offer the client new abilities. The official analogy is a USB-C port for AI: instead of a bespoke integration per tool, you build to one connector and it works everywhere.

Anthropic introduced and open-sourced MCP, and from day one it shipped with local MCP server support so Claude could connect to internal systems and datasets running on your own machine.

An MCP server can expose three kinds of things to the client:

  • Tools — actions the model can call (read a file, run a query, hit an API). This is the same shape as the model's native tool use: a named capability with typed inputs.
  • Resources — data the client can read (files, records, documents).
  • Prompts — reusable, parameterized prompt templates the server offers.

For this page the headline is tools: a local MCP server is how you hand Claude a new, private capability.

Why this is the synergy you want​

The thing people mean by "Claude as the brain, my computer as the body" is exactly the MCP client/server split:

  • Claude is the orchestrator. It reads your goal, decides which tool to call, calls it, reads the result, and decides the next step.
  • Local MCP servers are the capabilities. Each one is a small program you run on your machine: a filesystem server, a database server, a wrapper around a local script, even a server that calls a local model or hands work to a local agent.

Because the server runs locally and Claude talks to it over your own machine's standard input/output, your data and actions stay on your hardware — the model orchestrates, but the file reads, the SQL, the script execution happen locally. That is the privacy-preserving version of agentic work: brain in the cloud (or local too), hands strictly on your box.

And because MCP is one open standard adopted across many clients, a server you build is not locked to a single app. The same local server you wire into Claude Code can be used by other MCP-speaking clients — build once, reuse everywhere.

The local architecture​

The smallest useful picture has two parts and one channel:

  • MCP client (host). The AI app — for example Claude Code or Claude Desktop. It holds the model and decides which tools to call.
  • MCP server. A separate process that advertises tools/resources/prompts and executes them when asked.
  • Transport. For local servers the client launches the server as a subprocess and they talk over stdio (standard input/output) using JSON-RPC messages. No network, no port — just a local pipe between two processes on your machine. (Remote servers exist too, over HTTP; this page is about the local, stdio case.)
┌─────────────────────────┐         stdio (JSON-RPC)        ┌──────────────────────────┐
│  MCP CLIENT / HOST       │ ──── launches as subprocess ──▶ │  LOCAL MCP SERVER         │
│  Claude Code / Desktop   │ ◀── tools/resources/prompts ─── │  filesystem · db · script │
│  (the model = the brain) │                                 │  · local model / agent    │
└─────────────────────────┘                                  └──────────────────────────┘
                                                              runs on YOUR machine, YOUR data

The model never touches your disk directly — it asks the local server, and the server (running with your permissions) does the work and returns a result.

Add a local MCP server to Claude​

The fastest path is Claude Code's claude mcp add command, which registers a server the client will launch over stdio. The general shape is a name, then the command that starts the server.

Guided walkthrough1 of 4
  1. Start with an official reference server (e.g. the filesystem server) so the behavior is known. Anthropic maintains a collection of reference MCP servers you can run locally — filesystem, git, memory, fetch, and more.

A minimal claude mcp add for a local filesystem server (everything after -- is the launch command):

Add a local filesystem MCP server to Claude Code

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/allowed/dir

If you prefer editing config directly, a stdio server is declared by the command that launches it. The shape looks like this:

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

Build a tiny MCP server​

A server is just a program that uses an MCP SDK, declares a tool, and starts a stdio transport. Here is the whole idea in TypeScript — one tool that adds two numbers (swap the body for "run my script", "query my DB", "call my local model"):

npm install @modelcontextprotocol/sdk zod
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "my-local-tools", version: "0.1.0" });

// Declare ONE tool. Inputs are typed; the body runs locally with your privileges.
server.registerTool(
  "add",
  {
    description: "Add two numbers",
    inputSchema: { a: z.number(), b: z.number() },
  },
  async ({ a, b }) => ({
    content: [{ type: "text", text: String(a + b) }],
  }),
);

// Talk to the client over stdio — this is what makes it a LOCAL server.
await server.connect(new StdioServerTransport());

Register it with Claude exactly like any other stdio server — point the launch command at your file:

Add your own local server to Claude Code

claude mcp add my-local-tools -- node /abs/path/to/server.js

That's the full loop: Claude (brain) sees a new tool, calls it when relevant, and your code (hands) runs locally and returns the result. Because it speaks the same open protocol, this server also works in other MCP clients without changes.

Watch out
  • MCP servers run with your privileges and can take real actions — only install servers you trust, and watch for prompt-injection via tool results.

Check yourself​

Check yourself

0/4
  1. In one sentence, what is MCP?
  2. For a LOCAL MCP server, how does the client usually talk to it?
  3. Why does building one MCP server pay off across tools?
  4. What's the main reason to vet a server before installing it?
Press Enter or Space to flip the card. Use the left and right arrow keys to move between cards.Term shown.
1 / 8
Key takeaways
  • MCP is an open standard so an AI client can call external tools and data via MCP servers — Anthropic introduced it with local server support from the start.
  • The local architecture is simple: an MCP client (Claude Code / Desktop) launches a local MCP server as a subprocess and talks to it over stdio — your data stays on your machine.
  • This is the Claude-as-brain + local-capabilities synergy: Claude orchestrates; local servers (filesystem, DB, a script, even a local model or agent) supply the hands.
  • Add a server with one command (claude mcp add ... -- <launch command>); build one with an MCP SDK by registering a tool and connecting a stdio transport.
  • MCP is broadly adopted, so a local server you build works across many clients — build once, reuse everywhere.
  • Servers act with your privileges: install only what you trust and treat tool results as a possible prompt-injection vector.

Next​

Sources & further reading​