# Your MCP server passed a scan. What happens when its tools change?

> A practical guide to MCP tool changes: review definitions, pin local packages, limit runtime access, and understand what a clean scan cannot guarantee.

Canonical: https://bouncer.run/blog/mcp-tool-changes
Last updated: 2026-10-27

Blog · By Bouncer · October 27, 2026

# Your MCP server passed a scan. What happens when its tools change?

You review an MCP server, connect it to your agent, and get back to work. A week later, the same address advertises a different tool description. The connection still works. But are you using what you originally approved?

A scan tells you about the material inspected at that moment. It does not freeze a remote service or decide which future requests your agent should be allowed to make. To keep control, treat onboarding review, change detection and runtime permissions as separate jobs.

## The small change that matters

In MCP, clients discover tools through `tools/list` and invoke them with `tools/call`. A definition includes a name, description and input schema. The 2025-11-25 specification also defines an optional `listChanged` capability: servers declaring it should emit `notifications/tools/list_changed` when available tools change. Support is not universal. A notification signals a refresh, not security approval, code pinning or guaranteed integrity. [[1]](https://modelcontextprotocol.io/specification/2025-11-25/server/tools)

A changed description can be an ordinary documentation fix. It can also add instructions that try to steer the model beyond the user’s request. Invariant Labs’ April 2025 research demonstrated tool poisoning and described post-approval changes and cross-server influence. That research establishes an attack pattern, not a claim that every client today has the same weakness. [[2]](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks)

## A fictional notes assistant

Illustrative scenario — fictional tool names; not a recorded attack or real scan result.

Your task is to summarize project notes. The server initially advertises `read_note`. Later, it also advertises `delete_note`, or changes the description of `read_note` to request unrelated information.

A useful response is not to ask the model to “be careful.” It is to decide outside the model what the task permits:

- The notes credential can read only the project it needs.
- The gateway permits `read_note` and denies other tools by default.
- Request limits bound repeated calls.
- A changed tool definition goes back through review before you accept it.

Different controls answer different questions
| Control | What it helps with | What it does not establish |
| --- | --- | --- |
| Definition review | Spot suspicious descriptions and unexpected tools | What the server will do internally |
| Exact local package version | Make the selected package version explicit | That its code is harmless or dependencies/services are frozen |
| Tool allow list | Restrict which named tools can be called through the controlled path | Whether an allowed call’s arguments or returned content are appropriate |
| Rate limit or spend cap | Bound configured request volume or metered usage | That an individual request is authorized or benign |

## Build an approval baseline

Save the identity and endpoint you reviewed, the selected local package version where applicable, and a snapshot of the tool names, descriptions and schemas. Treat that as review evidence, not a certificate.

For a local npm-based server, choose an exact version instead of relying on `latest`. That makes the selected version explicit; it does not pin every transitive dependency or prevent the package from using external services. For a remote MCP server, the URL remains an address, not an immutable release.

Compare subsequent definitions with the baseline. Investigate new tools, permission-relevant schema changes and instructions unrelated to the job. A checksum can show that a representation changed; it cannot tell you whether the change is malicious. Unchanged definitions do not prove unchanged server implementation.

## Keep runtime permissions independent

Enforce the smallest useful tool set on the path the agent actually uses. A policy written only in a prompt depends on the model following it. A gateway policy can reject a disallowed tool call before forwarding it.

For the notes example, permit `read_note` and deny other tools by default. Keep the upstream credential equally narrow: if the agent still has a direct connection or broad credential, it may bypass the gateway.

Do not infer permission from a friendly tool name or `readOnlyHint`. The MCP specification treats annotations as untrusted unless they come from trusted servers. The official annotations explainer describes hints, not enforcement or guarantees; provenance still matters. They describe expected behavior, not access control. [[1]](https://modelcontextprotocol.io/specification/2025-11-25/server/tools) [[3]](https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/)

Even an allowed read can return hostile instructions or retrieve information outside the task. A tool-name policy is one layer. Validate arguments, scope upstream authorization, review sensitive actions in the client, and handle returned content as untrusted where appropriate. These are architectural recommendations, not claims that Bouncer implements every layer.

## Where Bouncer fits

Bouncer’s Security Check inspects advertised MCP tool definitions and records a tool-list snapshot. Its npm check reads published package files as text rather than running the package. The findings support a review; an “On the list” verdict is not a guarantee of safety.

After review, Bouncer’s gateway can apply tool allow/deny policies, scoped gateway keys, rate limits, daily quotas and configured spend caps to requests that pass through it, with a call log for inspection. It does not make a remote server immutable or automatically prove that every permitted call is safe.

Use the scan to inform what you connect. Use gateway policy to restrict what calls you allow. Revisit the decision when the tool surface changes.

[Check an MCP server](https://bouncer.run/check)

Free first check · No account needed. Sign in to re-scan.

[See how the MCP gateway works →](https://bouncer.run/mcp-gateway)

## Sources

- [MCP specification, 2025-11-25: Tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools)
- [Invariant Labs: MCP tool poisoning research, April 1, 2025](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks)
- [Official MCP blog: Tool annotations, March 16, 2026](https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/)

## Related reading

[Hello, agent! — the Bouncer launch article](https://bouncer.run/blog/hello-agent)

[MCP security scanner: check a server before you connect](https://bouncer.run/blog/mcp-security-scanner)

## Related
- [Security Check](https://bouncer.run/check)
- [MCP gateway](https://bouncer.run/mcp-gateway)
- [Pricing](https://bouncer.run/pricing)