You approve an MCP server because it can read issues. A month later, its tool list includes a write operation. Maybe you updated the package. Maybe the server changed which tools it exposes for your account. Either way, the permission decision you made at setup no longer describes the agent’s working environment.

MCP has a way for servers to announce changes to their tool lists. That announcement is useful, but it is not an approval workflow. Builders need to decide what happens after a list changes and before an agent acts on a new capability.

What actually changes in an MCP tool list

A client discovers tools through tools/list. Each tool has a name, a description, and an input schema; it can also carry annotations and an output schema. Those fields tell the client, and often the model, how to use the tool. They are not just documentation for developers.

The MCP tools specification also defines a listChanged capability. A server that declares it should send notifications/tools/list_changed when its available tools change. The client can then retrieve the list again. The notification does not contain an approval decision, and the specification’s SHOULD is not a promise that every server will notify correctly. A restarted client may also encounter a different list at connection time without seeing a change event.

A change can be more subtle than a new name. A familiar tool might accept a broader input schema, describe its job differently, or become available under credentials with wider access. Comparing names alone misses that. Comparing the tool list also does not prove what the server’s underlying code will do; it only tells you what the server is presenting.

The practical risk: yesterday’s trust decision

Imagine an agent connected to a repository server for issue triage. It can search and read issues, and the team approves that narrow workflow. A later release exposes a merge or deletion tool. The agent may now see an action that was absent when the team made its initial decision. Whether it can perform that action depends on server implementation, credentials, client behavior, and any approval gates, not on the directory listing.

An install command is not a lasting safety verdict. A directory can help you find a candidate, but it cannot authorize each tool your agent sees next month. Our earlier directory trust-gap analysis gets into the distinction between a listing and ongoing trust. Nor does a passing health check tell you whether a new tool should be allowed to merge a branch.

Tool descriptions deserve attention too. The MCP project’s local-server security guidance warns that a server supplies its tool names and descriptions at runtime and recommends treating those definitions as untrusted input. That is distinct from hostile text in a search result. A changed description can influence which tool an agent chooses before it ever reads a result.

A change-review loop you can actually operate

  1. Record the approved baseline. Save the server identity, source, pinned package version or remote endpoint, auth scope, and the full tools/list response. Include names, descriptions, schemas, and annotations. Keep credentials out of the record.
  2. Compare at connection and on change. Fetch the current list after connecting. If the server advertises listChanged, fetch again when that notification arrives. Diff definitions, not just names. Also review changes after package updates and credential changes; do not rely on the notification as your sole detector.
  3. Hold new write paths for review. If your client supports per-tool approval or an allowlist, keep newly exposed tools unavailable to unattended runs until someone checks the action, argument schema, data destination, and credential scope. If the client cannot enforce that boundary, restrict the server’s credentials or disconnect it while you review.
  4. Test with limited authority. Exercise the changed tool against a disposable project or test account when possible. Confirm what it actually touches, what errors look like, and whether the approval screen shows the real operation. Do not use production write access just to learn what a tool does.
  5. Log the decision and revisit it. Keep the baseline and approved changes with the workflow. When a credential gains a new scope or a package changes provenance, reopen the decision even if the exposed tool names are identical.

That review loop is something you have to build around MCP. Check what your particular client can block before relying on an allowlist; clients differ, and the protocol only tells them which tools the server offers.

Where directories fit

Use a directory to narrow the search, then inspect the actual connected server. A listing for GitHub MCP can help you identify a repository integration, but your token scopes and live tools determine what your agent can do. Filesystem MCP raises a different question: which paths can the local process access? Playwright MCP puts browser actions in scope. These are examples of risk questions, not claims that those particular servers changed their tool lists.

If you run local stdio servers, take the boundary one step further: the server is an operating-system process, not a sandbox supplied by MCP. The official local-server security guide recommends isolation and limited credentials because a process may have access beyond its advertised tools. A clean tools/list diff cannot replace that containment.

The awkward part is that even a perfect diff cannot tell you whether a server will honor its advertised boundaries. But when a new write tool shows up, at least you can stop the agent from trying it until somebody checks what it can touch. Yesterday’s server approval shouldn’t silently cover tomorrow’s merge tool.

FAQ

Q: Does notifications/tools/list_changed require the user to approve new tools?
A: No. It announces a change when a server that advertises the capability sends the notification. Approval policy belongs to the client and the organization running it.

Q: Is a stable tool list enough to trust a server update?
A: No. Code, credential scope, dependencies, and remote behavior can change without a new tool name. Pin and review what you run, and limit what it can access.

Q: Should I disconnect every server that adds a tool?
A: Not necessarily. Review the new definition and its permissions first. If your client cannot block the new capability while you review it, disconnecting or narrowing credentials is the safer temporary option.