You are asked to stop your organisation using a particular MCP server. You add a denylist entry matching the label people use for it and confirm it no longer loads on your own machine. A colleague warns that this will not hold. Why are they right, and what would actually enforce it?

The principle — A restriction is only as strong as the thing it matches on, and the weakest possible handle is one the person being restricted gets to choose.

Why the key is correct — The documentation states it outright: a name entry, in either list, is not a security control, because the name is the label a user assigns when adding the server rather than anything about the underlying server. Anyone can call any server anything, so a user who wants the blocked server keeps it simply by naming it differently. Matching on the server's URL or on the exact command that starts it is what the documentation directs you to for enforcement, because those describe the server rather than the user's choice of label. Your local test succeeded because you were the one who chose the label, which is the least representative case there is.

Why the others are wrong — The approach is not proven by working on your machine; it demonstrated only that the entry matches the label you happened to use. The name is not supplied by the server, which is the root of the whole problem. And tightening the allowlist does not close the gap on its own, because without the setting that makes the managed allowlist authoritative, allowlists merge from every settings source and a user can broaden what yours permits. Note that this does not apply to the denylist, which merges from every source regardless — deny is the half that holds.

Remember this — Match on what the server is, never on what somebody called it.

Sources — Anthropic's Claude Code managed MCP guide.