MCP server development

The tool layer is where an agent becomes dangerous

A model on its own can only be wrong in text. It becomes consequential the moment it is handed tools — a system it can read, a record it can write, an action it can take on your behalf.

So the interesting engineering is not the prompt. It is the server on the other side of the tool call: what it exposes, what it refuses, and what it writes down about both.

How we build them

OAuth 2.1 resource-server authentication, so a tool call arrives with an identity the server verified rather than a shared secret pasted into a config file.

A fail-closed permission model. Anything not explicitly granted is denied, and a scope that was never issued cannot be inferred at runtime by a persuasive request.

A tamper-evident audit ledger behind every call: which credential, which tool, which arguments, what came back. An automated step is logged the way a human step is.

Credentials that structurally cannot spend money

The safest way to stop an agent moving money is not to instruct it not to. It is to issue it credentials under which the action does not exist.

So write paths and payment paths are separated from read paths at the permission layer, and anything with a financial consequence terminates in a human review queue rather than in a tool the agent can call alone.

What you get

A running server your agents connect to, the permission model written down as something a reviewer can read, and the ledger that shows what was actually called.

We also review MCP servers other teams have already deployed, which is the same work approached from the other end — see AI evaluation and red-teaming.