Every agent needs to reach something: a database, a ticketing system, a document store, an internal service. Until recently each team wired those connections by hand, with bespoke function definitions tied to one model provider and one framework.
Open tool protocols, with the Model Context Protocol (MCP) as the best-known example, change that. They define a common way for an AI client to discover tools, call them and receive results. Build a connector once and many agents and clients can use it.
That is useful. It also means the protocol layer is now part of your integration architecture, and it should be designed like one.
Why a standard protocol helps
Without a shared protocol, integrations multiply. Each agent, assistant and IDE plugin gets its own copy of the same connector, each with slightly different behaviour and permissions.
A protocol layer gives you:
- One connector per system instead of one per agent
- Discovery — clients can list available tools and their schemas
- Portability across model providers and agent frameworks
- A clear seam for security, logging and policy
The last point matters most in an enterprise. A well-defined seam is where controls belong.
Treat tool servers as products
A tool server is an API with a new kind of caller. The caller reads descriptions, chooses tools and fills parameters based on natural language. That raises the bar on design.
Good tool servers have:
- Narrow, well-named tools rather than one generic “run query” endpoint
- Precise descriptions and schemas, because the model relies on them to choose correctly
- Typed, validated inputs with clear error messages
- Idempotent writes, so retries are safe
- Versioning, so changes do not silently break agents that depend on them
If a human developer would find a tool confusing, a model will too.
Security is the main design problem
A protocol makes it easy to connect an agent to many systems. That is exactly why it needs guardrails.
Questions to settle early:
- Identity — does the tool act as the user, as a service account, or both? How is that token scoped and passed?
- Authorisation — which tools are available to which agents and users, and who approves additions?
- Prompt injection — content returned by one tool can try to instruct the model to misuse another. Treat tool outputs as untrusted data.
- Third-party servers — community connectors are convenient, but review them like any dependency before they touch production data
- Data exposure — limit what each tool returns to what the task needs
Put a gateway or policy layer in front of tool servers where you can. It gives you one place to enforce allow-lists, rate limits and logging.
Logging and audit
Every tool call an agent makes should be attributable: which agent, on whose behalf, which tool, which parameters, what result, which model version. For write operations this is not optional.
Keep logs useful for both engineering and audit. Avoid storing sensitive payloads unless policy requires it, and restrict who can read the logs themselves.
Do not expose everything
It is tempting to wrap an entire internal API surface and hand it to an agent. Resist that. A large tool catalogue makes tool selection less reliable and widens the attack surface.
Expose the smallest set of tools that supports the workflow in scope. Add more when a real use case needs them and evaluation shows the agent uses them correctly.
Testing tool integrations
Tool servers need their own tests, separate from agent evaluation:
- Contract tests for schemas and error responses
- Permission tests that confirm a tool refuses what it should
- Injection tests with hostile content in returned data
- Load tests if many agents will share the server
Then evaluate the agent end to end with the real tools, so you know it chooses and uses them well.
Where to start
- Inventory the systems your agents need, and which already have stable APIs
- Pick one system and build a small, well-described tool server for it
- Decide identity and authorisation before the first write tool ships
- Route calls through a gateway with logging from day one
- Review third-party connectors like any other dependency
A protocol is plumbing. Good plumbing is what lets the rest of the agent programme scale safely.