How to Build an Approved MCP Server List: A Step-by-Step Playbook

An approved MCP server list is the short catalog of MCP servers your staff may connect to company AI apps, with who approved each and on what terms. It is usually owned by IT or security, with input from the teams that use each server. MCP makes this list necessary because anyone can add a server by URL or command, and each server can read or change real business data.

This playbook covers how to build the list, review new requests and enforce it in the clients that document allowlist controls as of October 2026.

What you need

• An intake form that asks for the server's publisher, URL or package, the job it supports, the data it touches and whether it can write.
• A review checklist. Our MCP server security review and vendor security questionnaire give you the questions.
• Client admin controls. Claude Team and Enterprise Owners add connectors from Organization settings > Connectors, per Claude's directory docs. Claude Code supports managed allowlists, per Anthropic's managed MCP docs. ChatGPT admins manage plugin availability in the Admin Console, per OpenAI's admin controls article.
• Optional: a gateway or private catalog. Obot and other MCP gateways can publish one governed catalog across several clients.

The workflow

1. Inventory what is already connected. Before writing rules, list the servers people use today. Shadow servers are an OWASP risk: OWASP's MCP Top 10 lists "Shadow MCP Servers" as MCP09.
2. Define tiers. For example: read-only servers from the vendor of a system you already use; servers that can write; and local servers that run code on staff machines. Higher tiers need more review.
3. Check publisher and source. Confirm the server comes from the vendor's own docs or repository. The MCP Registry ties server names to verified GitHub accounts or domains, but it "delegates security scanning" to package registries and downstream aggregators. In Claude's directory, Anthropic says Verified status "isn't a security audit," per its verification page.
4. Review the tools and scopes. List every tool, and mark which ones write, send or delete. Record the OAuth scopes the server requests. Decide whether to approve the whole server or only some tools.
5. Record exactly what you approved. Note the URL or exact launch command, the version, and the tool list on the approval date. Obot's README says catalog changes "take effect only through an explicit upgrade," which is the behavior you want.
6. Enforce it in Claude Code. Anthropic documents an "Approved catalog" pattern: allowedMcpServers plus allowManagedMcpServersOnly: true in managed settings. Match remote servers with serverUrl and local ones with serverCommand. The docs note Claude Code has no built-in server registry, so publish the approved list and its install commands on an internal page.
7. Enforce it in Claude and ChatGPT. In Claude, only add approved connectors for the organization. On Team plans, members who cannot enable connectors see a Request button that goes to Owners. In ChatGPT, OpenAI says only admins and owners can publish custom MCP apps for the workspace, and new actions found on refresh are "disabled by default."
8. Publish the list. Show each approved server, its tier, what it may be used for, and who to ask. Link the request form.
9. Re-review on change. Re-check a server when its tools change, its publisher changes, a security advisory appears or a year has passed.

Example prompts

Run these against vendor docs or exports, not production systems:

• "Here is the tool list this server returned. Mark each tool as read, write or delete, and flag any whose description asks the model to do something unrelated to its name."
• "Compare today's tool list with the one we approved in June. List added, removed and changed tools."
• "From this request form, draft a review summary: publisher, data touched, write tools, requested scopes and open questions."
• "Turn this approved list into a table for our wiki: server, tier, allowed use, owner, review date."

Guardrails

• Approve by URL or command. Anthropic's docs warn that a serverName entry is just a label a user picks, so "a user can call any server github."
• Watch for silent changes. Claude's verification page says a connector's developer "controls its tools, which can change after review." Our page on rug pull attacks explains the risk.
• Treat annotations as hints. The MCP tools specification says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers."
• Keep a denylist too. In Claude Code, a denylist match blocks a server and "Nothing overrides a denylist match."
• Tell people what changed. Anthropic notes that when a server is newly blocked it can disappear from /mcp with no signal, so announce changes.

What to measure

• The number of approved servers, by tier.
• Requests received, approved and declined, and the median days to decide.
• Servers found in use that are not on the list, from logs or device inventory.
• Approved servers past their re-review date.
• Tool or version changes detected since approval.

These numbers show whether the list is used or bypassed. A rising count of unlisted servers usually means the request process is too slow.

Next step

For the wider picture of policies, logging and access control, read MCP for IT leaders. More guides are in the MCP playbooks hub.

Frequently asked questions