MCP Servers

The Model Context Protocol is an open standard for connecting AI applications to external capabilities. Before it, every assistant needed a bespoke integration with every tool; MCP makes the connection reusable — write a server once and any MCP-capable client can use it.

The shape. A host application runs MCP clients, each connected to an MCP server that exposes capabilities. Communication is JSON-RPC. Servers are usually small, focused programs, not large services.

Three primitives, distinguished by who is in control. Tools are invoked by the model to take actions — this is the one most servers spend their time on. Resources are data the application pulls in as context, controlled by the app rather than chosen by the model. Prompts are templates the user deliberately invokes, like a slash command. Choosing the right primitive matters: making everything a tool forces the model to decide things the application already knows.

Transports. A local server typically runs as a subprocess over stdio, which is simple and inherits the user's environment and privileges. A remote server runs over HTTP, which brings authentication, multi-tenancy, and network exposure into scope.

Design the tools, not the API. A thin wrapper over an existing REST API is usually a poor MCP server: it exposes endpoint-shaped operations when the model needs task-shaped ones. Design around what someone wants to accomplish, return results the model can use directly, and keep responses small enough not to flood the context window.

Security deserves real attention. A local server runs with the user's privileges, so it can do whatever they can. Tool results flow into model context, which makes them an injection surface — content fetched from elsewhere can carry instructions. Scope credentials narrowly, and require confirmation for destructive actions rather than assuming the model will be careful.