MCP server development and security, from someone who runs one in production.

What I build

• Expose your product to AI assistants. An MCP server that lets Claude, Cursor and other clients use your SaaS product on your customers’ behalf, with the permissions your product already enforces.
• Connect agents to internal systems. Servers in front of your CRM, document store, ticketing or data warehouse, so your own agents can read and act on them through one controlled layer.
• Take a prototype to production. A server that works for one developer, hardened for strangers, clients you did not test and a directory that counts your errors.
• Review a server you already run. What each tool can reach, how tokens are checked, what leaks through results and links, and how injected instructions in tool results are handled.

What a production MCP server needs

A demo server takes an afternoon. One that strangers and their agents rely on needs the decisions most demos skip. These are the ones the SystemAudit connector forced:

1. Errors decided before a directory decides for you. Problems with the request are protocol errors; failures an agent can recover from come back as results marked isError, with what to try next.
2. Validation of what clients send, not what the schema says. Clients send arguments your schema never promised to accept. Every tool checks them before anything runs.
3. Tool descriptions written for the model that chooses them. One job per tool, read-only where possible, and a description that says when not to call it.
4. Limits on the expensive operation. Rate limits sit on the call that costs money or quota, not on the request count.
5. Partial results that say they are partial. A result that did not cover everything says so, instead of reading as a clean answer.
6. Auth matched to whose data a tool touches. OAuth with audience-checked tokens once a tool acts on a user’s or tenant’s data, and a client’s token never passed through to an upstream API.
7. Tool calls measured, not connections. Connections tell you who installed it; tool calls tell you whether anyone uses it.
8. Every guard tested by breaking it. Each limit, check and redaction has a test that fails when the guard is removed.

Each is written up with the code and the mistakes in what it takes to run a production-ready MCP server. If you are deciding whether to adopt MCP at all, the MCP guide for CTOs starts there.

MCP and AI agent security

An MCP server turns a model’s output into actions on real systems, so most of the risk sits in what each tool is allowed to do. The controls I put in place:

• Least privilege per tool, so an agent answering one question about one account cannot read the whole CRM.
• Tool results treated as untrusted input, because a document or web page a third party controls can carry instructions aimed at the model.
• Human approval for actions that change data, with an audit trail of who asked, what ran and what it returned.
• Claims that hold for everything a caller can reach, links and reports included, not only the tool response.

The authorization model is in how to authorise what AI agents can do, and the wider agent architecture on AI agent development.

How an engagement starts

• A new server: a 2 weeks discovery sprint, from £2,450, that ends with a working prototype against your real system and a fixed price for the build.
• A server you already run: the AI security and architecture review, from £2,000 over 1-4 weeks.
• Ongoing ownership of the agent and MCP layer as a fractional AI CTO.

Questions about MCP server development