Not long ago every agent integration was bespoke. Each tool arrived with its own authentication, its own error shapes and its own retry rules, and the glue code was rewritten for every project. The Model Context Protocol (MCP) changed that. It gives assistants and agents one way to discover tools, call them and read the results, and it is now supported by the major assistant clients and agent frameworks.
That settles the protocol question. It does not settle the engineering one. An MCP server is a way for a model to act inside your systems, and the questions that matter are the ones every integration has always had: who is allowed to do what, how much, and how you find out afterwards.
Design tools around tasks, not endpoints
The quickest MCP server wraps every API endpoint as a tool. It is also the worst one. A model given forty narrowly named tools spends its effort choosing between them, and many of those tools grant more than any single task needs.
A better server exposes a short list of tools shaped around what a user actually asks for — "find invoices for a customer", "draft a refund" — each with a clear description, typed inputs and results the model can act on. Fewer, better-described tools are easier for the model to use correctly and easier for you to secure.
Scope every tool
The MCP authorization specification is built on OAuth 2.1, which means a remote server can act on behalf of a specific user with specific scopes. Use that properly:
- Separate read scopes from write scopes, so a user can grant an agent the ability to look without the ability to change.
- Give each tool the narrowest scope that completes its task.
- Use short-lived tokens, and make revoking access a single action.
- Require a person to approve any tool that moves money, changes access or contacts a customer.
One server per trust boundary
A single server that can both read customer records and post messages to a chat tool can be used to copy one into the other. The model does not need to be malicious for this to happen; it only needs to read a document that tells it to.
Our default is to split servers along trust boundaries rather than along vendors. Systems that hold sensitive data sit behind servers that cannot send anything outside, and servers that can send messages cannot read sensitive data. The agent can still use both, but no single server holds the combination that makes a leak possible.
Plan for the downstream API saying no
Agents call tools in bursts and retry when something fails. A downstream API that rate-limits halfway through a run will see the same request again unless the server handles it. Put rate limits on the server per user and per tool, return errors the model can understand ("rate limited, retry after 30 seconds" rather than a stack trace), and make write operations idempotent so a retry does not create a duplicate.
Log every call before you need the log
When something goes wrong — an unexpected refund, a message sent to the wrong channel — the first question is what the agent did and why. Record every tool call with the user it acted for, the input it sent and the result it received, and keep those records for as long as your policies require. An audit trail is cheap to build at the start and very expensive to reconstruct afterwards.
Where to start
If you already have an internal API, an MCP server in front of it is a modest project: a few weeks to design the tools, add authorization and logging, and test it with real assistants. The time is best spent on the permission model, because that is the part that decides whether connecting an agent to your systems is a risk or a feature.