Article
Two years ago, connecting a model to your systems meant writing a bespoke tool layer for every model vendor. The Model Context Protocol ended that. An MCP server describes what a system can do in a form any capable model can use, and the same server works with whichever agent framework or coding tool you point at it. If you build software that other people's agents should be able to use, an MCP server is now the expected interface, in the way a REST API was expected a decade ago.
The protocol is not the hard part. The hard part is deciding what to expose.
Design the tools around tasks, not tables
The first instinct is to wrap the existing API one endpoint per tool. The result is a model with forty tools that each do a little, and a plan that takes twelve calls to do what a person does in one. Better: ask what an agent would actually need to accomplish, and expose those as tools. "Find the customer's open orders and their delivery status" is one tool, even if it is five queries underneath. Fewer, larger, task-shaped tools produce shorter plans and fewer mistakes.
Make reads cheap and writes deliberate
Split the server's tools into reads and writes and treat them differently. Reads can be broad. Writes should be narrow, named for what they do, and idempotent where possible, so a retry does not create a second order. For anything irreversible, return a proposal the harness can show to a person, rather than performing the action. The agent harness decides when a proposal can be auto-approved; the server should never decide that on its own.
Filter at the server, not the prompt
If a record contains a field the model should never see, remove it in the server. A prompt that says "ignore the card number" is a request; a server that never returns the card number is a guarantee. The same goes for row-level access: the server runs as the user or tenant the agent is acting for, and the database enforces what they can see.
Describe tools as if to a careful new colleague
The model reads tool descriptions the way a new hire reads a runbook. Say what the tool does, what it returns, when to use it and when not to, and what the arguments mean, with an example. Vague descriptions produce vague calls. We spend as long on the descriptions as on the code, and evaluation results move when we improve them.
Log everything, rate-limit everything
Every call, with arguments and results, goes to a log the client can read. Every tool has a rate limit and a cost ceiling, because an agent in a loop can call a tool a thousand times before anyone notices. These are boring and they are the reason the security review passes.
What to leave out
Anything that deletes. Anything that sends money. Anything that emails customers directly. Not never, but not in the first version, and not without a person in the loop. Ship the server with reads and a few carefully chosen writes, watch the logs for a month, then expand.
We build MCP servers as part of agent engagements and as standalone pieces of custom software for companies whose customers are bringing their own agents. Either way the server is yours, in your repository, with the descriptions and the tests.