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

If you've spent any time building with LLMs, you've written the same code more than once: a wrapper around some API, a schema describing it to the model, a parser for the tool call that comes back, error handling for when the model passes garbage. Then you switch models or frameworks and write it all again.

That repetition is the problem the Model Context Protocol was designed to eliminate. But "MCP server" gets thrown around loosely enough that it's worth being precise about what one actually is, what it isn't, and when writing one is the right call.

So What Is an MCP Server?

An MCP server is a process that exposes capabilities — tools, resources, and prompts — to an AI client over a standardized protocol. The client (Claude Desktop, an IDE, your own agent loop) connects to the server, asks what it offers, and can then invoke those capabilities on the model's behalf.

The protocol itself is JSON-RPC 2.0 over one of two transports: stdio for local servers the client spawns as a subprocess, or streamable HTTP for remote servers. The handshake is straightforward — client and server exchange an initialize message negotiating protocol version and capabilities, then the client calls tools/list to discover what's available and tools/call to invoke something.

Three primitives matter:

Tools are model-controlled functions with JSON Schema input definitions. The model decides when to call them. create_issue, run_query, send_message — these are tools.

Resources are application-controlled data the client can read, addressed by URI. A file, a database record, a document. The distinction from tools is about who initiates: the host application decides what resources to pull into context, not the model.

Prompts are user-controlled templates — reusable instructions a user explicitly invokes, typically surfaced as slash commands.

Getting these three straight is the thing most people get wrong when they first ask what is an MCP server. Everything ends up shoved into tools, and the result is a server that dumps enormous payloads into the model's context because a resource would have been the right primitive.

Why the Standardization Actually Matters

The honest answer to why MCP exists is combinatorial. Without a protocol, connecting M AI applications to N data sources requires M×N bespoke integrations. With one, it's M+N. Write a Postgres MCP server once and every MCP-capable client can query Postgres.

The second benefit is architectural. Because servers are separate processes with declared capabilities, you get a real boundary. Your Jira integration doesn't share a process with your filesystem access. Permissions and auth live at the server edge rather than being tangled through your agent code. Servers can be swapped, versioned, and tested independently.

The third is less obvious but matters in practice: the protocol supports server-initiated interaction. Sampling lets a server request an LLM completion from the client, so the server can use inference without holding its own API key or model dependency. Elicitation lets a server ask the user for input mid-execution. Both let you build servers that do something more interesting than wrap a REST endpoint.

When to Build One — and When Not To

Knowing what is an MCP server is one thing; knowing when you need one is the more useful skill. Build one when the capability will be used by more than one client, when it needs its own auth or permission boundary, when you want it maintained and versioned separately from your agent, or when you're exposing something for others to consume.

Don't build one when a plain function call would do. If you have a single agent, a single tool, and no intention of reusing it, MCP is protocol overhead for no benefit. The transport handshake, the schema declarations, and the process boundary all cost something. A well-typed Python function in the same process is simpler and faster.

The middle case is the interesting one: you have several tools that share auth or state — a set of operations against the same database, or a group of endpoints behind one OAuth token. That's a natural server boundary even inside a single application, because it gives you one place to manage credentials and one place to enforce limits.

Practical Notes for Server Authors

A few things separate servers that feel good to use from ones that don't.

Write tool descriptions for the model, not for humans. The description is the model's only signal for when to call your tool. Say what it does, what it returns, and when not to use it. Vague descriptions produce wrong calls.

Keep tool surfaces small. Forty near-identical tools is worse than eight well-chosen ones. Every tool definition consumes context and every ambiguous pair increases the chance of the wrong pick.

Return errors the model can act on. {"error": "invalid input"} teaches the model nothing. {"error": "date must be ISO 8601, got '03/09/26'"} gets a correct retry.

Watch your payload sizes. A tool that returns 50,000 tokens of JSON is a context bomb. Paginate, truncate with an explicit note, or return a resource URI the client can fetch selectively.

Be careful with side effects. Annotate destructive operations, and design so a misfired call is recoverable. The model will occasionally call the wrong thing.

Find the Servers Worth Using

Once you understand what an MCP server is, the next question is which ones already exist — because the fastest MCP integration is the one someone else wrote and maintains.

That's what Best MCP Tools is for. It's a directory of MCP servers and tooling, organized so you can find what connects to the systems you actually use rather than scrolling an unsorted README of a thousand repos.

Browse the directory to find servers for your stack. If you've built one, submit it — a good server that nobody can find helps nobody. And if you've run one in production long enough to know where it's solid and where it's rough, leave a review. Real operational detail is the most useful signal in this ecosystem right now, and it's exactly what's missing from most listings.