What are MCP Servers?

MCP stands for Model Context Protocol. It is an open standard Anthropic published in late 2024 so that any AI client and any tool provider can talk to each other without a custom integration sitting in between them. An MCP server is the tool side of that conversation. It is a small program, often a single Node or Python file, that announces a clear contract to whatever client connects: here are the tools I expose, here are the resources I can read, here are the prompts I can run on request. Claude Code is the client. When you launch the CLI, it starts the MCP servers you have configured, asks each one what it can do, and then makes those capabilities available to Claude during your session without any further setup on your part.

If you have ever pasted a schema into a chat, screenshotted a Jira ticket, or copied logs out of a terminal so Claude could see them, you already understand the problem MCP solves. The model is smart but blind to your real systems. MCP gives it eyes and hands in the systems you care about. It is the difference between describing your database to an assistant and letting the assistant query it directly. Once you feel that gap close, the rest of your workflow rearranges itself around it.

Why MCP exists

Before MCP, every integration between an LLM and a tool was bespoke. Each IDE plugin, each chat app, each agent framework reinvented the same wiring: how to discover tools, how to pass arguments, how to stream results, how to handle errors, how to keep secrets out of logs. That meant tool builders had to ship the same connector five times across five clients and AI clients had to maintain a sprawl of one-off adapters that broke every time an upstream API changed. The Model Context Protocol replaces that mess with one wire format. Build a server once and any MCP-compatible client can use it. Build a client once and every server in the ecosystem works.

For you as a builder, that means real reach. You are not waiting for Anthropic to add support for your stack. If a server exists for Stripe, Supabase, Notion, or your internal API, Claude Code can use it tonight. If one does not exist, you can write one in an afternoon, ship it to a coworker by sharing a config snippet, and they get the same capability without redoing the work. That compounding is the real point of an open standard, and it is why MCP adoption moved so fast.

How MCP actually works

Under the hood, MCP is JSON-RPC 2.0 messages exchanged over one of three transports: stdio for local servers Claude launches as child processes, Server-Sent Events for remote servers over HTTP, and streamable HTTP for newer remote setups. The protocol defines a small set of methods. The client sends initialize, the server replies with its capabilities. The client calls tools/list to discover available tools, resources/list to discover readable resources, and prompts/list to discover canned prompt templates. When Claude decides to use a tool, it sends tools/call with the tool name and arguments, the server runs whatever code it wants behind that name, and returns a structured result that Claude reads as new context.

That is the whole model. Tools are functions the model can invoke. Resources are read-only data the model can pull in as context, like a file or a row from a table. Prompts are pre-written templates a user can summon by name. Each is described in a JSON schema so Claude knows exactly what arguments to send and what shape it will get back. There is no magic. The clarity of the schema is what lets the model use the tool well, which is why a thoughtfully written server feels dramatically better than a hastily written one even when both technically expose the same data.

Authentication and secrets live outside the protocol on purpose. Your server reads API keys from environment variables, your config file pins those variables for the server process, and the client never has to know what the server is talking to. That separation keeps secrets where they belong and keeps the protocol clean.

Real MCP servers people actually use

The ecosystem already covers most of the surfaces a working developer touches. A few that show up over and over in real workflows, in roughly the order most builders adopt them:

• Filesystem MCP - lets Claude read and write files outside the current project directory, useful for cross-repo work, scratch directories, or assembling outputs that span more than one folder.
• Postgres MCP - exposes a database connection so Claude can list tables, describe schemas, run read-only queries, summarize result sets, and explain what it found in plain language.
• GitHub MCP - search code across your repos, read issues, open and review pull requests, look at diffs, and pull file content without leaving the session.
• Puppeteer or Playwright MCP - drives a real browser so Claude can fill forms, scrape rendered pages that need JavaScript, or run end-to-end checks against a staging URL.
• Linear, Notion, Slack, Sentry MCPs - read tickets, write docs, post messages, pull stack traces. Whatever your team uses to coordinate work, there is almost certainly a server already.
• Memory MCPs - give Claude a persistent scratchpad across sessions so it remembers project context, decisions, and ongoing tasks without having to reread the whole repo every time.
• Custom internal MCPs - a thin server in front of your own API so Claude can act on your product the same way a teammate would.

Inside Claude Code Club at claudecodeclub.ai we share working configs for these so members do not have to re-figure the same setup steps. It is one of the things the $9/mo membership pays for itself on within a week because the time you save not chasing transport errors and missing env vars is real.

Common misconceptions

First, MCP is not a plugin format specific to Claude. It is an open protocol, and other clients are adopting it. Servers you write today should still be useful when the ecosystem grows. That portability is part of why MCP is worth learning instead of a vendor-specific integration format that might not survive the next round of platform shifts.

Second, MCP is not a way to fine-tune the model or change its weights. It only adds tools and context at inference time. The model that calls your server is the same model that answered the last chat. The difference is what it can reach. If your task requires capability the base model truly lacks, MCP will not help.

Third, MCP servers are not magic agents. They expose capabilities. Whether Claude uses them well depends on your instructions and on how clearly the server documents its tools. A vague tool description leads to misuse, even with a strong model. The discipline of writing crisp tool docs is the unglamorous part of MCP that separates servers that feel great from servers that feel buggy.

Finally, MCP is not the same as Claude Skills. Skills live inside your project as instructions and supporting files that change behavior. MCP servers are external processes that expose live tools. The two are complementary and you will typically use both, often together, where a skill teaches Claude how to use a server properly.

How to get started

Install Claude Code with npm install -g @anthropic-ai/claude-code, then add a server. The fastest path is to use one from the official directory of community servers. You add it to your config file and Claude Code launches it automatically next session. You do not have to write any code for your first server.

1. 1Pick one server that solves a real pain you have today, like Postgres for database questions or GitHub for cross-repo work.
2. 2Add it to your Claude Code config with the command, args, and any environment variables it needs, following the server's README exactly.
3. 3Start a new Claude Code session and run /mcp to confirm the server connected and to see the tools it advertised.
4. 4Ask Claude to do something that requires the server, like 'list the five largest tables and their row counts' or 'summarize the last ten merged pull requests.'
5. 5Once it works end-to-end, add a second server. Stop there until you genuinely need a third.
6. 6When the off-the-shelf servers run out, write your own. The Anthropic docs include a starter template in both TypeScript and Python.

When not to use MCP

If the work fits in a single repo and a single language, you do not need MCP. A clear CLAUDE.md, a tidy file tree, and the built-in file and shell tools will handle it. Reach for MCP when Claude needs to act on something outside the repo: a database, an API, another service, a browser. If you find yourself adding ten servers, stop. Each one adds startup time and tool clutter for the model to wade through, and tool overload measurably degrades how well the model picks. Keep your server list short and intentional.

Also avoid wiring production-write access to MCP servers casually. A Postgres MCP that can run any SQL is fine on a dev replica and risky on prod. Use read-only credentials by default, and put dangerous tools behind a separate server you only enable when needed. The CLI will let you scope what is available per session, and you should use that.

Writing your own server

Eventually you will want a server that does not exist yet. The good news is that writing one is short. The Anthropic SDKs in TypeScript and Python both ship a tiny library that handles the protocol boilerplate. You import it, declare your tools with JSON schemas, write the handlers, and start the process. A useful internal server is usually under two hundred lines of code, and most of that is the schema for the tools you are exposing.

Write the tool descriptions as if Claude has never seen your API before, because effectively it has not. Say what each tool does, what each argument means, what the result looks like, and what failure modes to expect. Vague tool descriptions are the number one reason a server feels broken even when the code works. The investment in clear docs pays back every time Claude picks the right tool on the first try.

How MCP fits the Claude Code ecosystem

Claude Code already ships with file editing, shell execution, and web fetching as built-in tools. MCP extends that surface to anything you can write a small program for. Pair it with Claude Skills for repeatable task instructions, with subagents for parallel work, and with a clean CLAUDE.md for project context, and you have an assistant that can actually move a codebase forward instead of just chatting about it. That is the workflow we teach inside Claude Code Club, and MCP is one of the first things new members learn to set up because the moment you watch Claude run a query against your own database is the moment you understand what the rest of the stack is for.

Once you have two or three servers running, the way you think about new projects shifts. You stop asking 'how do I describe this system to Claude' and start asking 'is there a server for this system or do I need to write one.' That question is the right one to be asking. It is the difference between treating AI as an answer machine and treating it as a worker who needs the right access to do real work on your behalf.