To revoke an MCP server everywhere, find every agent and client configuration that references it, block it at your enforcement point, rotate any credentials it held, and verify with a live test that no agent can still call it. Removing one config file is not enough.
Why it is harder than it looks
An MCP server can be wired into many places: developer laptops, shared team configs, CI jobs, hosted agents and project level settings committed to repositories. Each may have its own copy. Credentials may live in separate environment files or secret stores. If you remove only the entry you know about, the others keep working.
Step by step
- Decide urgency. If the server is suspected malicious or compromised, act first and investigate after. If it is simply retired, schedule the change.
- Block centrally first. Add the server to a denylist at the proxy, gateway or policy layer if you have one, so access stops while you hunt for configs.
- Find references. Search repositories for config files and server names or URLs, check shared team settings, CI definitions, container images and documentation snippets people copy from.
- Check your agent registry. Every agent using the server should list it among its tools. Registry entries tell you where to look, and gaps tell you what you were missing.
- Remove it from each config and commit the change. Tell owners of laptop level setups what to delete.
- Rotate credentials. Any token, key or secret the server held or received should be treated as exposed if the server was untrusted. Revoke the old ones at the issuer, not just in your config.
- Review logs. Look for calls to the server before the cut, to understand what data it received and what actions it triggered.
- Check for persistence. Some servers ask clients to cache tokens or register callbacks, so look for leftover grants at the identity provider.
- Verify. In a safe test, try to call the server from a representative agent. The call must fail.
- Record the decision, date and owner.
What the specification gives you
The MCP specification lets servers declare whether they send notifications when their tool list changes, which is one reason a server you once reviewed can look different later. Use that as a prompt to record the server version and review state in your registry, so you can tell which agents depend on a version you no longer trust.
The MCP security best practices page also discusses risks such as confused deputy problems in proxy servers and token handling, which is a good reminder that credentials associated with a server are part of the revocation scope.
What to tell people
Developers need a plain message: which server, why, what to remove, by when, and what to use instead. A removal with no replacement drives people to install something worse, so offer an approved alternative where you can.
Prevent the next scramble
Keep a living inventory of MCP servers with owners, versions and consuming agents. Pull requests that add a server config should trigger a review. With that in place, revocation becomes a lookup rather than a hunt.
Try it yourself
Click through it at your own pace, or open it full screen. See where a server connection is configured, then think about every other place the same entry could exist.
Safeguard's MCP Guardrail, agent identity and asset discovery features are relevant here, and a free scan is at https://gold.safeguard.sh/scan.
Quick check
Is deleting the config entry enough?
No. Block centrally, remove every copy, rotate credentials and verify with a test call.
Do I rotate credentials for a merely retired server?
Revoke them at the issuer anyway. Unused live credentials are an avoidable risk.
Sources
Last reviewed: 19 October 2026.
