Let Agents Use Tools Without Losing Track of Them
Tools are what turn a model into an agent. Three small controls answer the questions every agent team ends up asking: what can it call, which servers does it reach, and what changed since last week.
In this post
The agent that got a new tool on Thursday
Most agent incidents start with a good idea.
Someone gives the agent a new tool, because the agent is more useful with it.
Picture this
A support agent gets a ticketing tool on Thursday. On Friday another team adds a repository tool to the same agent, to help with a bug. By Monday the agent has twenty tools, three of them can delete things, and nobody can say which team approved which.
Nothing in that story is reckless. The gap is that tools are added where the agent is built, and governed nowhere. The more an agent can do, the more it matters who decided that.
Three questions every agent team ends up asking
They arrive in the same order, usually after the first surprise.
| Question | What answers it |
|---|---|
| What can this agent call? | Allow and deny lists for tools, per policy |
| Which servers does it reach? | A registry of approved MCP servers, with an approval step |
| What changed since last week? | Recorded tool definitions, with a review when one changes |
Each control is small. Together they let a team keep adding tools without losing the thread.
Where governance sits
Tools run in two places. Your own code runs some. The model provider runs others, such as MCP servers it reaches itself. Cloptima does neither. It sits between your agent and the provider and governs the traffic.
1Agent offers tools
In the request
2Cloptima checks
Policy and registry
3Provider answers
May ask to call a tool
4Cloptima checks the call
Before your agent acts on it
That position is enough. The request lists the tools on offer, and the response lists the calls the model wants. Both can be judged without running anything.
Allow and deny, in the request path
A policy lists the tools and tool servers an agent may use, and the ones it may not.
A deny always wins.
Without tool control
- Every tool the agent offers reaches the model
- A new tool is live the moment it ships
- The only record is the agent's code
With tool control
- Denied tools are removed before the model sees them
- A denied call is stopped and recorded
- A cap on tool calls ends a runaway loop
Removing a denied tool means the agent keeps working with the tools it may use. Nobody has to redeploy the agent for a rule to take effect.
A registry with an approval step
An MCP server gives an agent new abilities.
The registry makes each server a decision somebody made.
- 1
Register the server
Name, URL, and the tools it may expose.
- 2
Approve it
An admin approves, and only then does it go live.
- 3
Let a policy use it
A policy lists the servers its agents may reach.
Disabling a server cuts it off at once. That is the fast path during an incident.
Seeing a tool change
A tool is more than its name. Its description and input schema are instructions the model follows.
A tool that changes its description has changed what your agent will do.
Cloptima records the definitions agents send for registered servers. The first is approved for you. When one changes, you see the approved version beside the new one, and you approve or reject it. The decision lands in the audit log.
The human stays in charge
Some providers can run an MCP tool on their own, with no pause.
Cloptima keeps a person in the loop for those.
- A provider-run server must be named in the request and listed on the policy
- A request that asks the provider to run tools with no approval is refused
- Servers and their tools can be restricted to the ones you named
Cloptima does not connect to your servers or hold their credentials. It decides what traffic may mention them.
Roll out in a week
You do not need to design the perfect list first.
- 1
Start in Monitor only
Write the lists and let Cloptima record what would be refused.
- 2
Review the Policy Violations card
Add the tools your agent really needs. Deny the ones it should not have.
- 3
Register your servers
Start with the ones agents already use.
- 4
Enforce on one agent
Switch that agent's policy to Enforce.
- 5
Review tool changes weekly
Approve the expected ones.
Your first week
Small and deliberate beats complete and late.
- Deny the tools no agent should ever have, such as shell and delete tools
- Cap tool calls per run at a number that fits a normal task
- Register the servers your agents already use
- Check the registry for tool changes once a week
- Keep a short note beside each policy saying why a tool is allowed