An MCP server can change its tool list while an agent is connected and notify the client. If the client adds the new tools without review, the agent's capabilities grow with nobody approving them. Record the tool definitions you approved, compare on every change, and require review for additions.
How the mechanism works
In the MCP tools specification, a server that supports tools declares the tools capability and may set listChanged to true. When its tools change, it should send a notifications/tools/list_changed message. The client then requests the list again.
This is useful for servers whose tools depend on context. It also means the set of things an agent can do is not fixed at connection time.
Why it matters for security
The security best practices page gives a concrete case. In the session hijack prompt injection attack, an attacker injects an event that causes a list changed notification, which can affect the tools offered, so the client may end up with tools it was not aware were enabled.
Drift also happens without any attacker. A server operator ships an update that adds a write tool beside a read tool, and every client picks it up on the next refresh.
A control loop
- Record at approval time: server, tool names, descriptions and input schemas.
- On every list refresh, diff against the record.
- Treat an addition, a changed description or a widened input schema as a change needing review.
- Keep new tools disabled for the agent until approved.
- Log the diff with who approved it.
Also remember that the specification says clients must treat annotations as untrusted unless the server is trusted, so a changed label should not alter approval rules on its own.
Limiting the blast radius anyway
Review will miss things. Backstop it with controls that do not depend on noticing:
- Narrow credentials, so a new tool cannot do much even if approved by mistake.
- Approval for irreversible actions, whatever tool performs them.
- Rate limits and timeouts, which the specification asks servers and clients to apply.
- Session hardening: random session IDs bound to the user, so list change events cannot be injected from outside.
What to put in a runbook
- Who reviews tool changes, and how fast.
- Where the approved definitions are stored.
- What happens to an agent when a server changes without review: block, degrade to the old list, or ask.
A worked example
Say your agent connects to a ticketing server with two tools: search tickets and read ticket. A month later the operator adds a close ticket tool and a post comment tool. Your client refreshes the list and offers all four to the model.
Nobody decided that the agent should be able to close tickets or write comments visible to customers. With a stored approval record and a diff, the two new tools would have been held back and a person would have been asked. Without them, the change goes live the next time the agent runs.
Where Safeguard fits
Safeguard includes an MCP Guardrail for governing which MCP servers agents use. Reviewing what changed in a tool list is still a process you own.
Quick check
Should I disable the list changed notification?
You cannot control what a remote server sends, but you can control what your client does with it. Refresh, diff, and hold new tools until reviewed.
Sources
Last reviewed: 19 October 2026.
