MCP: giving agents your internal tools without giving them your production database

Before MCP, connecting an agent to an internal system meant writing a bespoke tool wrapper per agent framework, and everyone wrote their own. The protocol standardises that: a server declares the tools it offers, and any compatible client — a coding agent, a chat assistant, an automation platform — can discover and call them.

That is genuinely useful and it is not the interesting part. The interesting part is that the moment your systems are addressable by an agent, tool design becomes a security and reliability discipline rather than a plumbing exercise.

Design the tool, not the endpoint

The instinct is to wrap the existing API one-to-one. Resist it. An agent given GET /customers, GET /orders and GET /invoices will make nine calls and assemble the answer badly. An agent given get_customer_summary(customer_id) that returns the same information already joined makes one call and gets it right.

Tools should be shaped like the questions people ask, not like your data model. Fewer, coarser, task-shaped tools outperform a faithful API mirror on every axis: accuracy, latency and token cost.

The same applies to output. Return what is needed, not the full record — every unnecessary field is context spent on every subsequent turn, and a tool that returns a 40 KB JSON blob will degrade the reasoning of everything that comes after it in the conversation.

Descriptions are prompts

The tool description is how the agent decides whether to call it. "Returns customer data" produces calls at random. "Returns billing status, plan and open invoice count for one customer. Use for questions about what a customer is paying. Does not include support history." produces correct routing.

Write the description as instructions to a competent new colleague, including when not to use the tool. The negative clause is the one people leave out and it does more work than the positive one.

Identity: the decision that has to be made early

Three models, in ascending order of effort and safety.

Service identity. The server holds one credential and every call goes through it. Simple, and it means any user of the agent can reach anything the service can. Acceptable for read-only access to non-sensitive data; not acceptable for anything customer-specific.

Delegated identity. The end user's token is passed through, and the backend applies its existing authorisation. This is the right answer almost always, because your permission model already exists and re-implementing it in the tool layer is how gaps appear.

Scoped service identity per agent. A dedicated principal with a narrow policy, where delegation is impossible. Then the constraint has to be in the tool signature itself: a tool that takes a customer id from the request context rather than from the model's arguments cannot be talked into fetching a different customer.

Whichever you choose, write down the reachable set, as in sizing an agent's blast radius.

Read and write, separated

Expose reads generously and writes narrowly. A write tool should do one specific business operation with validated inputs — create_support_ticket(subject, body, customer_id) — never a generic execute_sql or call_api(method, path, body), which are the two most common shortcuts and both of them hand over everything at once.

Rate limit per agent, log every call with its arguments and the identity it ran under, and make destructive operations require a confirmation token that only a human flow can produce.

Operating it

An MCP server is a production service. It needs health checks, timeouts, a version, and a deprecation path for tools you remove — agents break the same way clients do. Run it inside your network, put authentication in front of it, and do not expose it to the internet because a tool endpoint that anyone can reach is an API without an authorisation layer.

And be sceptical of third-party servers. Installing one gives it a channel into your agent's context; a malicious or careless tool description is an injection vector. Review what you install with the seriousness you would apply to a dependency with credentials, because that is what it is.

What to do this week

List the five questions your team asks internal systems most often — the ones that currently mean opening three tabs. Those are your first five tools, and they are almost never a one-to-one mapping of any endpoint you already have.