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]

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]

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] [3]

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

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

See how the MCP gateway works →