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

If you've been building with LLMs for any length of time, you've written the same glue code more than once: a wrapper around an API, a JSON schema describing what the model is allowed to call, a dispatcher that routes tool calls back to your functions. Then you switch models, or add a second agent, and you write it all again.

The Model Context Protocol exists to kill that pattern. And the piece that does the work is the MCP server. If you've seen the term thrown around in release notes and quietly wondered what is an MCP server, actually — this is the answer, with enough detail to go build one.

So What Is an MCP Server?

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

That's the whole idea, but the implications take a moment to land. Concretely:

• The server owns the capability. A GitHub MCP server knows how to list issues, open PRs, and read files. It handles auth, pagination, rate limits, and error shapes.
• The client owns the model. Claude Desktop, an IDE, your own agent loop — whatever's driving the LLM connects to servers and surfaces what they offer.
• The protocol is the contract. JSON-RPC over stdio or HTTP, with a defined handshake, capability negotiation, and message types.

The consequence is that integrations stop being N×M. You write one Postgres MCP server and every MCP client can query databases. Someone else writes a Slack one and you get Slack for free. That's the actual value proposition — not a new capability, but the elimination of repeated integration work.

If you've worked with the Language Server Protocol, the analogy is exact. Before LSP, every editor needed a plugin for every language. After it, one language server serves every editor. MCP is that idea applied to model context.

The Three Primitives

An MCP server can expose three kinds of things, and knowing which is which will save you design mistakes.

Tools are functions the model can call. They have a name, a description, and a JSON Schema for their inputs. create_issue, run_query, send_message. Tools are model-controlled — the LLM decides when to invoke them based on your descriptions, which means those descriptions are effectively prompt engineering. A vague tool description produces a tool that never gets called or gets called wrong.

Resources are data the model can read. Files, database rows, API responses — addressed by URI. Resources are application-controlled: the client decides what to pull into context, not the model. Use resources for reference material the model should be able to look at, tools for actions it should be able to take.

Prompts are reusable templates the server offers, typically surfaced to the user as slash commands or menu items. User-controlled. Underused, and genuinely handy for encoding a workflow your server supports.

The line between a tool and a resource trips people up constantly. Rule of thumb: if calling it twice could produce different side effects, it's a tool. If it's just reading something, lean resource.

Transports, and Why It Matters Where Your Server Runs

MCP servers speak over one of two transports.

stdio — the server runs as a local subprocess, and the client talks to it over stdin/stdout. This is the default for anything touching the local machine: your filesystem, a local database, git, developer tooling. Auth is implicit, because the process runs as you. It's simple and it's fast.

Streamable HTTP — the server runs remotely and the client connects over HTTP with server-sent events for streaming. This is what you want for hosted services, multi-user setups, and anything a team shares. It's also where the hard parts live: OAuth, token handling, per-user scoping, and the security questions that come with letting a model reach a network endpoint.

Most people writing their first MCP server should use stdio. Ship it locally, prove the tool design is right, then decide whether it needs to be remote.

Practical Notes From Building a Few

Knowing what is an MCP server in the abstract is one thing; here are the details that only become obvious after you've shipped one:

Descriptions are your interface. The model chooses tools based on the text you write. Be specific about when to use a tool and — just as importantly — when not to. "Search the codebase" is worse than "Search the codebase for symbol definitions. Use this before editing a file you haven't read."

Return errors as content, not as protocol failures. When a tool call fails, return a message the model can read and act on. A raw stack trace as a transport error just stalls the loop.

Keep tool surfaces small. A server with forty tools floods the context window and degrades selection accuracy. Group related operations behind fewer, better-parameterized tools.

Watch your output size. A tool that returns 40,000 tokens of JSON is technically working and practically useless. Paginate, summarize, or return references.

Test against a real client. The spec is one thing; how a given client surfaces your tools is another. Behavior differs more than you'd like.

Think about the trust boundary. Anything your server returns lands in the model's context. If that content comes from an external source — a web page, an email, a user-submitted record — treat it as untrusted data, not as instructions.

Find the Right Server on Best MCP Tools

The ecosystem has grown fast enough that the hard part is no longer answering what is an MCP server — it's finding the right one and knowing whether it's any good.

Browse the directory to find servers by what they connect to: databases, cloud providers, developer tooling, design tools, internal systems. Each listing covers transport, auth model, and the tools it actually exposes, so you can tell whether it fits before you install it.

Leave a review. You know which servers have thoughtful tool design and which ones dump raw API responses into your context. That's exactly the signal other developers are looking for and can't get from a README.

Submit your server. If you've built something worth using, add it to Best MCP Tools and get it in front of developers who are already looking.

Head to Best MCP Tools, find what you need, and stop writing the same integration twice.