Claude Code documents several organization level controls for MCP: allow and deny lists of servers, a managed server configuration, a switch to turn off claude.ai connectors, and per tool settings that force a prompt or remove a tool. Together they let an administrator define which servers developers can use. The details live in separate pages, so verify them before relying on this summary.
What the page says
Anthropic's Claude Code MCP reference mentions these controls briefly and links to the pages that cover them in full. The part fetched for this article lists:
- A managed MCP configuration file and a setting for managed servers. Servers provided this way rank above every other scope.
- Allowed and denied server lists.
- A setting, and an environment variable, to turn off claude.ai connectors in Claude Code.
- Per tool connector controls set to ask, which always prompts, or blocked, which removes the tool from Claude's tool list.
Because the page only touches these, treat the names and behavior as pointers and read the linked administration documentation for exact syntax and version requirements.
What each control is for
| Control | Purpose | Good for |
|---|---|---|
| Managed servers | Provide approved servers to everyone | A standard security connector |
| Allow list | Name the servers people may use | Closed environments |
| Deny list | Block specific servers | Known bad or retired servers |
| Turn off claude.ai connectors | Stop connectors from the web account appearing in the coding tool | Keeping a coding environment narrow |
| Tool set to ask | Always prompt for that tool | Anything that changes data |
| Tool set to blocked | Remove the tool entirely | Tools you never want used |
A worked example
This example is illustrative. A company of several hundred developers wants to allow one security connector and nothing else for now.
- The administrator provides the connector through the managed configuration, so each developer has it without setup.
- An allow list names that server and no others.
- The administrator turns off claude.ai connectors in the coding tool, so connectors added in a developer's personal web account do not appear in work sessions.
- Within the connector, three write tools are set to blocked, and one is set to ask.
- The security team publishes a request process for adding another server.
Developers notice nothing except that the connector is there. When one tries to add a server of their own, the allow list stops it and the message points to the request process.
Step by step: design your policy
- Inventory the servers developers use today.
- Decide which are approved for everyone, which for some teams and which are retired.
- Pick an approach: closed allow list, or open with a deny list. A closed list is stricter and creates more requests.
- Decide how connectors from personal web accounts are treated.
- Set per tool controls for each approved server.
- Test with a fresh machine and a standard developer account.
- Document the request path and the review cycle.
Pitfalls
A deny list protects only against what you already know. Managed settings need a way to reach machines, and developers on personal devices may be outside it. A policy that blocks everything will push people to workarounds, so pair controls with a quick approval process.
Evidence and audit
Keep the managed configuration under version control with a change history. If a reviewer asks how you limit AI tool connectors, you can show the file, its history and the request records. Do not describe this as a certification or attestation. It is your own control, and you should say what it covers.
Rolling it out without friction
Announce the policy before enforcing it. Give developers two weeks to list the servers they use, and approve the legitimate ones first. Publish a short form for new requests, with a promise of a response in a few working days, and keep that promise. Tools that block without a path forward teach people to look for ways around them.
After enforcement, review the denied attempts you can see. A pattern of requests for the same server is a signal to evaluate it properly, not to ignore it. Review the whole policy each quarter, since the documentation for these settings may change and new controls may appear.
One more check: personal accounts
A developer can often sign in to the web version of a chat product with a personal account and add connectors there. Ask whether your policy covers that case and how you will learn about it. One practical step is a short survey asking which connectors people use for work data. The answers usually surprise the security team, and they feed straight into the allow list.
Where Safeguard fits
Safeguard offers an MCP Guardrail, policies and gates, and agent identity for teams that want centrally managed controls around agents. Start with the free scan. The Safeguard CLI, installed with a curl or PowerShell installer, can also write code, and the download page lists a Local agent and a Cloud agent as available.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a policy is expressed, and compare it with the allow and deny ideas above.
Quick check
Do these controls replace reviewing each server?
No. They limit which servers can be used, but each approved server still needs a review of tools, scopes and data flow.
Where do I find exact setting names?
In Anthropic's administration documentation linked from the MCP reference. This summary covers only what that page states.
Should I use a closed allow list or an open deny list?
A closed list is stricter. An open list is easier on developers but only blocks known problems.
Sources
Last reviewed: 19 October 2026.
