What Is an MCP Server? A Developer Guide to the Model Context Protocol

If you have been building with LLMs for any length of time, you have written the same glue code more than once: a wrapper around an API, a schema describing it to the model, a parser for the response, error handling for when the model hallucinates an argument. Then you did it again for the next tool, and again for the next model provider, with slightly different conventions each time.

The Model Context Protocol exists to stop that. And the practical unit of MCP is the server — which is why the first question worth answering is what is an MCP server, precisely, and what problem it removes.

What Is an MCP Server?

An MCP server is a process that exposes capabilities — tools, resources, and prompts — over a standardized protocol so any MCP-compatible client can consume them without custom integration code.

That is the whole idea, and it is deliberately narrow. The server does not know or care which model is calling it. It advertises what it can do, accepts structured requests, and returns structured results. A client — Claude Desktop, an IDE, your own agent runtime — handles discovery, presents the capabilities to the model, and routes calls.

The architecture is a straightforward client-server split with three primitives:

• Tools are model-invocable functions with JSON Schema inputs. create_issue, run_query, send_message. These are the ones with side effects, and they are the ones you will write most.
• Resources are readable context identified by URI. A file, a database record, a document. Application-controlled rather than model-invoked, which means the client decides what to surface.
• Prompts are reusable templates the user can invoke deliberately — the backing mechanism for slash commands in most clients.

Transport is either stdio for local servers (the client spawns your process and talks over standard streams) or streamable HTTP for remote ones. Messages are JSON-RPC 2.0. Both ends negotiate capabilities during an initialization handshake, which is what makes version skew survivable.

Why This Beats Rolling Your Own

The obvious objection: you already have function calling. Why add a protocol?

Write once, run in every client. A Postgres integration built as an MCP server works in every MCP-compatible host without modification. The same integration written as bespoke function-calling glue works in exactly one codebase.

Decoupled deployment. Your server ships on its own cycle. Add a tool, restart, and clients pick it up through capability discovery. No coordinated release with the agent application.

Real process isolation. Servers run as separate processes with their own credentials and permissions. Your GitHub token lives in the GitHub server's environment, not in a shared config blob that every part of your agent can read. That boundary is doing meaningful security work.

A composable ecosystem. Because the interface is uniform, servers compose. An agent can hold connections to a dozen servers at once, and adding the thirteenth costs a config entry rather than an integration sprint.

The tradeoff is honest: you add a process boundary and a serialization hop. For a single tightly-coupled tool in one application, that overhead is not worth it. For anything you want reused, it is.

What Building One Actually Involves

Once you know what is an MCP server in the abstract, writing one is less work than it sounds. The official SDKs — TypeScript, Python, and several community implementations — handle the protocol layer. Your job is defining capabilities.

A minimal server registers tools with a name, a description, and an input schema, then implements the handler. The description matters far more than developers expect: it is the model's only guide to when the tool applies. Vague descriptions produce tools the model calls at the wrong moments or ignores entirely. Write them as if for a competent colleague who has never seen your system.

A few things that consistently separate solid servers from frustrating ones:

Return errors as content, not exceptions. When a call fails, return a result with isError set and a message explaining what went wrong. The model can read that and adjust. An uncaught exception just terminates the turn.

Keep tool surfaces small. Twenty granular tools overwhelm a model's selection ability. Consolidate into fewer, well-parameterized tools with clear boundaries.

Be deliberate about output size. Tool results consume context. A query tool that returns ten thousand rows will destroy the conversation. Paginate, truncate with a note, or return a reference the model can drill into.

Annotate destructive operations. Tool annotations like readOnlyHint and destructiveHint let clients apply appropriate confirmation gates. Use them.

For testing, the MCP Inspector lets you exercise a server interactively without wiring up a full client — the fastest debug loop available.

Where the Ecosystem Stands

Adoption moved quickly. Reference servers cover the obvious ground — filesystem, Git, databases, Slack, browser automation — and vendor-maintained servers now ship from a growing number of platform companies. Remote servers over HTTP have made hosted, authenticated integrations practical, which is what was needed for anything beyond local developer tooling.

The gap now is discovery and quality signal. Finding a server is easy. Finding a well-maintained one, understanding its auth model, and knowing whether it handles pagination sensibly still takes real digging.

Build Better, and Help the Ecosystem

If you are evaluating servers rather than writing one, the fastest path is comparing them side by side — transport, auth model, tool surface, maintenance status — instead of reading a dozen READMEs in sequence.

Best MCP Tools is a directory of MCP servers and tooling built for exactly that. Browse it at bestmcptools.org to find servers for the systems you already use, and to see what other developers have run in production versus what merely looks good on GitHub.

If you have shipped an MCP server, submit it to the directory — the ecosystem's usefulness is bounded by how findable good work is. And if you have run one in anger, leave a review. Notes on rate limits, error handling, schema quality, and whether the maintainer responds to issues are the details no README will tell you, and they are exactly what the next developer needs.