Jul 21, 2026 · 2 min read
What is an MCP server, really?
Every time you want an AI assistant to do something — read a file, query a database, hit an API — someone used to write a bespoke integration for that one model and that one tool. Ten models times ten tools is a hundred glue-code projects. The Model Context Protocol (MCP) exists to collapse that M×N mess into M+N: every tool speaks one protocol, and every model speaks the same one.
Anthropic's analogy is that MCP is a USB-C port for AI — a single, standard connector between models and the world. I like it because it's honest about what MCP is: not intelligence, just a well-designed interface.
What a server actually exposes
An MCP server is a small program that offers three kinds of things to a client — the connector an AI host (Claude Desktop, Claude Code, or your own agent) runs to reach it:
- Tools — functions the model can call. "Search invoices", "create a ticket", "run this query."
- Resources — data the model can read. Files, rows, documents — addressable by URI.
- Prompts — reusable prompt templates the server offers up for common tasks.
The client discovers all of this at connect time, so the model learns what a server can do without you hardcoding it into the prompt.
The smallest possible server
Because I live in .NET, here's the shape in C# — a server exposing a single tool:
[McpServerToolType]
public static class InvoiceTools
{
[McpServerTool, Description("Look up an invoice by its number.")]
public static Invoice Get(string number) =>
Invoices.Find(number);
}
Register it, pick a transport (stdio for a local subprocess, HTTP for a remote one), and any MCP client can now call Get — with the model deciding when, based on the description you wrote. That description is your API contract with the model, so it's worth writing well.
Why it matters for agents
An agent is only as capable as the tools it can reach. MCP turns those tools into a library you compose rather than a codebase you fork: stand up a server once, and every MCP-aware agent you build inherits the capability. That's the part I find genuinely useful — the same filesystem, database, or search server I wrote for one agent drops straight into the next.
This was a warmup. Next I want to get into the sharp edges — auth, and keeping a server's blast radius small when an agent can call it autonomously.