What an MCP Server Actually Gives Claude Code
An MCP server is a small standalone program that speaks the Model Context Protocol and hands Claude Code new tools, live data, or reusable prompts it did not ship with. Claude Code already reads your files and runs your terminal. An MCP server extends that reach to anything with an API: a client's CRM, an internal ticketing system, a proprietary database, a niche file format nobody wrote a public integration for. You build the bridge once, and the agent can use it in every project from then on.
You do not need one for most work. Claude Code already reads and writes files, runs shell commands, and can hit any REST API you point it at inside a single session. Build a server when the same connection needs to exist across many sessions and many projects, when the system needs a stable, named tool the agent can call reliably instead of you re-explaining the API shape every time, or when you want to hand a client or teammate a tool without handing them your raw credentials and prompt scaffolding.
The Three Pieces Every MCP Server Needs
Every MCP server, no matter how simple, is the same three pieces wired together.
- A server instance that declares its own name and version, and lists what it offers - one or more tools, and optionally resources (readable data) or prompts (reusable instructions).
- A transport that connects the server to Claude Code. Locally this is almost always stdio - the server runs as a subprocess and talks to Claude Code over standard input and output, which is the simplest option and the one to reach for first.
- One tool handler per capability - a function that takes the arguments Claude Code sends, does the real work (call an API, query a database, read a file), and returns a result the agent can read and act on.
Building a Minimal Server, Step by Step
This is the shortest path to a working server using the TypeScript SDK. The same shape applies in Python if that is your stack.
- Scaffold a new Node project and install the SDK: npm init -y, then npm install @modelcontextprotocol/sdk.
- Create a server instance and give it a name and version - this is what shows up when Claude Code lists connected servers.
- Register one tool with server.registerTool(): give it a name, a short description Claude Code will use to decide when to call it, and a Zod schema for its input arguments so bad calls fail before they reach your code.
- Write the handler function - the part that actually does the work. Keep the first one boring on purpose: read a local JSON file, or call one endpoint on an API you already have a key for. Return a plain text or structured result.
- Connect the server to a StdioServerTransport and call server.connect(). That is the entire runtime - no port, no listener to manage.
Wiring It Into Claude Code
Once the server file runs on its own without errors, register it with Claude Code using the CLI: claude mcp add my-server -- node /path/to/server.js. That writes the connection into Claude Code's config, and the next session Claude Code starts, it lists your tool alongside its built-in ones and calls it the same way - by deciding, based on your prompt and the tool's description, that it is the right tool for the job.
Where an MCP server config can live
| Scope | When to use it |
|---|---|
| Local (per-project) | A tool specific to one client or one codebase - credentials and config stay with that project only |
| User (global) | A tool you personally want available in every project - your own utilities, your own accounts |
| Project (checked into the repo) | A tool the whole team or client should have automatically when they open the project |
A Real Build: Packaging a Client's Internal API as One Tool
A client had an internal ops API with a dozen endpoints and no public SDK. Every session I would paste the same three endpoint shapes into the prompt so Claude Code could call them correctly. That is exactly the pattern an MCP server exists to remove. I wrote one server with three tools - lookup-order, update-status, and list-open-tickets - each a thin wrapper around one endpoint with a clear description and a validated schema.
After that, the agent called the API directly, by name, with correctly shaped arguments, in every new session without me re-explaining anything. The win was not speed on any single call - it was that the connection became a fact about the project instead of something I had to re-teach the agent each time I opened a new chat.
When to Build Your Own vs. Use an Existing Server
Check the MCP server registry and Anthropic's list of official integrations before you write anything - Slack, GitHub, Google Drive, Postgres, and a long list of others already have solid public servers, and building your own version of one of those is wasted time.
- Build your own when the system is internal, proprietary, or has no public API surface at all.
- Build your own when you want to expose a narrow, safe slice of a bigger system - three approved actions, not the entire API.
- Use an existing server when a maintained one already covers the exact tool you need. Contributing a fix upstream beats maintaining a private fork.
Start With One Endpoint This Week
Pick the one API call you keep re-explaining to Claude Code at the start of every session. Wrap just that one call in a server with a single tool, register it locally, and confirm the agent calls it correctly without you describing the shape again. That one working tool is the whole pattern - everything past it is just adding more handlers to the same server.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
What is an MCP server for Claude Code?
It is a small standalone program that speaks the Model Context Protocol and hands Claude Code new tools, live data, or reusable prompts it did not ship with. It lets the agent reach systems like a CRM, an internal API, or a proprietary database the same way it reaches its built-in file and terminal tools.
Do I need to build my own MCP server, or is there already one for my use case?
Check the MCP server registry and Anthropic's official integrations list first. Slack, GitHub, Google Drive, Postgres, and many other common systems already have maintained public servers. Build your own only when the system is internal, proprietary, or has no existing integration.
What do I actually need to build a minimal MCP server?
Three pieces: a server instance that declares what it offers, a transport (stdio is simplest for local use) that connects it to Claude Code, and one tool handler function per capability that does the real work and returns a result. Anthropic's TypeScript and Python SDKs handle the protocol plumbing for you.
How does Claude Code find and use a custom MCP server?
You register it once with the CLI - claude mcp add - pointing at the command that runs your server. From then on, Claude Code lists it alongside its built-in tools at the start of every session and calls it automatically when your prompt matches what the tool's description says it does.
Last reviewed by David Iya on August 10, 2026
