MCP Server Development

An MCP server exposes three kinds of capability. Tools are actions the model can choose to call, such as searching orders or creating an invoice, each with a name, a description and a typed input schema. Resources are pieces of context the client can read, such as a file, a record or a schema, identified by a URI. Prompts are reusable, parameterised templates a user can pick, such as summarise this account or draft a release note.

The design work is deciding what goes where and at what level of detail. Wrapping every REST endpoint as its own tool usually overwhelms the model and wastes context; a smaller set of task-shaped tools with clear descriptions, sensible defaults and concise, structured results gets better behaviour. We write tool descriptions for the model as carefully as API docs for a developer, mark which tools are read-only and which change data, and return errors that tell the model how to recover.

MCP servers run in two main ways. A local server is launched by the client on the user machine and talks over standard input and output, which suits developer tools and access to local files. A remote server runs as a web service using the streamable HTTP transport, which suits shared business systems, central logging and access by many users and clients; the earlier SSE-based transport has been superseded by it.

For remote servers we handle the usual production concerns: containerised deployment in your cloud or on-premises, secrets management, rate limiting, timeouts for slow back ends, structured logs of every tool call, and health checks. Keeping the server stateless where possible makes scaling and rolling updates straightforward.

Remote MCP servers should authenticate users with OAuth-based authorization, as the specification describes, so each request carries a token issued for that user and that server. We validate tokens properly, never pass a client token straight through to downstream APIs, and map each user to the narrowest scopes they need - many servers start as read-only, with write tools added one at a time.

Least privilege also means planning for misuse by the model itself. Content returned by tools can contain instructions planted by third parties, so destructive or financial tools require confirmation, inputs are validated server-side rather than trusted, outputs are filtered for data the user should not see, and every call is audit-logged with the user, tool and arguments.

We test MCP servers at two levels: conventional unit and contract tests for each tool, and model-in-the-loop evaluations that check an assistant actually picks the right tool with the right arguments for realistic requests. Changing a tool name, description or schema can change model behaviour as much as a code change, so the server surface is versioned, changes are reviewed, and breaking changes are introduced alongside the old tool before it is retired.

MCP is not always the answer. If one application calls one model with a fixed, known set of functions, defining those functions directly in your code is simpler. MCP earns its keep when the same capabilities should be available to several AI clients or agents, when users bring their own assistants, or when you want one governed, audited gateway between AI and your systems instead of many one-off integrations.