How do I control which MCP tools an AI agent can call?
Updated · DBShifts
Short answer
Put a policy point between the agent and the MCP server. Allow and deny tools per agent by name, check argument values before a call reaches the server, hide disallowed tools from the list the model sees, and scan tool descriptions and results for injected instructions. Answer refusals as tool errors so the model can adapt.
Key facts
- An MCP server lists every tool it has to every client that connects to it.
- A tool's description is read by the model as instructions, which makes it a place to hide them (tool poisoning).
- Argument rules catch the dangerous use of an allowed tool, such as acting on the wrong repository.
- A refusal returned as a tool error lets the model choose another route instead of failing the session.
- What a tool returns is untrusted input to the model that called it.
Why tool-level control matters
Most MCP servers bundle harmless tools with destructive ones: read a file and delete a file, open an issue and delete a repository. Connect an agent and it can call any of them, and the server usually cannot tell which agent is calling or for whom.
What to check on every call
The method (tools, resources, prompts), the tool's name against an allow list and a deny list where the deny list wins, the argument values against rules for that tool, sensitive data in the arguments on the way out, and sensitive data and instructions in the result on the way back. Refuse before the call reaches the server, not after.
Descriptions are part of the attack surface
The model decides how to use a tool from its description. A malicious or compromised server can put instructions there, and they arrive in the model's context before any tool is called. Screen descriptions like any other text the model reads, and show the model only the tools it may actually use.
Checklist
- 1
Tools allowed per agent, with a deny list that wins
- 2
Rules on argument values for tools that can do damage
- 3
Disallowed tools removed from the tool list
- 4
Tool descriptions and results scanned for injected instructions
- 5
Sensitive data masked in arguments and results
- 6
Every call logged, including the refused ones
Common mistakes
Asking the model not to use a tool
A system prompt is advice, not a control. If the tool is reachable, the model can call it; enforce the rule outside the model.
Allowing a tool without looking at its arguments
Opening an issue is harmless until the repository argument points somewhere it should not. Rules on argument values close that gap.
Trusting tool descriptions
Description text goes straight into the model's context, and a server you do not control can change it at any time.
How DBShifts does it
- DBShifts Agent Mesh sits between agents and MCP servers (Streamable HTTP) and applies one rule per caller and server.
- Rules allow and deny tools by name pattern and check argument values with eq, ne, in, not_in, prefix, glob, max and min; a refused call is answered as a tool error under the request's id and never reaches the server.
- The tool list is filtered to what the caller may use, and tool, resource and prompt descriptions pass the injection shield.
- Arguments and results are masked by data class, results are shield-scanned, and resources and prompts stay off until the rule allows them.
Questions people also ask
Can I limit a tool to certain argument values?
Yes. An argument rule names a tool pattern, an argument and a test, for example repo must equal acme/web or amount must be at most 500. A call that breaks one is refused before it reaches the server.
What is tool poisoning?
Hiding instructions for the model in a tool's description or metadata. The model reads descriptions to decide how to use tools, so the hidden text can steer it. Screening descriptions, and limiting which tools a model sees at all, reduces the risk.
Related questions
Give AI agents data access you can defend
Scoped tokens, PII masked on the server, every request audited. Free to start.
Start free18 answers in this series. See all.