MCP Tool Allowlist: How to Restrict What Agents Can Call

An MCP tool allowlist is a policy that names exactly which tools a caller may see and call, with everything else denied. Build it by inventorying tools, labelling each read, write or irreversible, granting each key only what its job needs, and then testing that a hidden tool is refused when called by name.

Why an allowlist beats a blocklist

A blocklist says “these tools are dangerous.” Every new tool is allowed until someone notices it. An allowlist reverses the default. Every new tool is unavailable until a person decides it is needed. In a protocol where tools can be added to a server at any time, the second design is the only one that stays safe without constant attention.

The principle is the same as least privilege in any system. OWASP lists excessive agency among the main risks for LLM applications: an agent holding more functionality, permission or autonomy than its job requires. An allowlist is the most direct control for it.

Key takeaway: every tool an agent can call is an action an injected instruction might trigger. The allowlist is where you decide the size of that set.

Step 1: inventory every tool

You cannot restrict what you have not listed. Start from the live catalogue, not from memory. Ask the server or gateway for tools/list and record name, description, parameters and which upstream system each tool touches.

Some products publish this for you. BusinessMCP’s reference of every tool its MCP endpoint exposes is generated from its live registry and groups tools by category: AI visibility, attribution, company identification, CRM and contacts, funnels and goals, heatmaps and replays, paid ads, sales automation, SEO and others. It also marks which require approval and which are gated by plan. If your own gateway cannot produce a comparable list, building one is the first piece of work.

Step 2: classify by risk

Give each tool a risk class. A simple three-level scheme is enough to start.

Class	Meaning	Examples	Default policy
Read	Returns data, changes nothing	Fetch analytics, list contacts	Allow per need
Write	Changes internal state, reversible	Update a contact field, save a note	Allow narrowly
Irreversible or external	Spends money, contacts people, deletes	Send email, change an ad budget	Off by default, approval required

Add a second axis for the data touched: customer personal data, financial data, internal documents, public data. The combination makes review fast. A read tool on public data is low risk. A read tool on contact personal information is not.

Step 3: scope policy per caller

Different callers have different jobs. A reporting agent needs a few read tools. A support agent needs read plus one draft tool. An operations agent might need more. Do not give them one shared key.

Caller	Allowed	Denied
Weekly report agent	Analytics, search performance (read)	Anything that writes or sends
Support drafter	Read tickets, create draft	Send, close, delete
Ops assistant	Read plus update internal fields	Money and external messages

Some platforms express this as presets plus per-connection allowlists. BusinessMCP’s documentation describes access presets that define what a scoped key can call, and per-connection tool allowlists that restrict tools further, with sensitive actions such as sending email gated for approval. Read the documentation on exposing an MCP endpoint for the details as the vendor states them.

Step 4: enforce at call time

Discovery filtering and enforcement are separate. A well-built gateway does both:

1. tools/list returns only permitted tools for the key.
2. tools/call re-checks the policy for the named tool.
3. Output may be redacted for fields the key is not permitted to see.

If only step 1 exists, a caller that guesses or remembers a tool name can still call it. That is a common design flaw, which is why testing matters.

Step 5: test the boundary

Do not trust a configuration screen. Run these checks for each key:

1. List tools and compare with your intended policy.
2. Call a denied tool by its exact name. Expect refusal.
3. Call an allowed tool with arguments that reach beyond its purpose, if the tool takes free-form input. Observe what the tool validates.
4. Call an approval-gated tool and confirm nothing happens before approval.
5. Revoke the key and confirm the next call fails.
6. Check the log for every attempt above, including refusals.

Refusals in the log are valuable. A read-only key repeatedly trying to write is an early warning that something is wrong, whether a bug or an injection. See MCP audit logging for what to record.

Step 6: keep the list alive

Allowlists decay. People add a tool for a one-off and never remove it. A few habits keep yours honest:

• Give every grant an owner and a reason in writing.
• Review quarterly and drop unused tools.
• Re-review when a connected server updates, since tool descriptions can change after approval. This is the rug-pull risk described in BusinessMCP’s guide to MCP prompt injection, whose mitigations include pinning versions and requiring re-consent when descriptions change.
• Cap the total number of tools per workspace if your platform allows it.

A policy template

Keep policy in a reviewed file, not in someone’s head. A minimal shape:

Field	Example
Key name	reporting-agent-prod
Owner	Growth engineering
Purpose	Weekly performance summary
Allowed tools	Listed explicitly
Approval required	None (read-only)
Expiry or review date	Next quarter
Log destination	Central log store

Mistakes that undo the work

• Granting a category (all CRM tools) when two tools would do.
• Sharing one key between agents, which makes the allowlist meaningless.
• Treating connected third-party servers as trusted. Their descriptions are instructions to a model.
• Forgetting that a model reading a poisoned tool description can steer calls to other servers. That is why the whole connected set should stay small.

The allowlist is one part of a wider approach. Combine it with per-caller keys and the baseline in MCP gateway security, and keep key management disciplined so a leaked key cannot undo your careful scoping.