The chat app asks the connector for its tool list, and it can subscribe to a notification that fires when the list changes. The MCP documentation says those notifications are best effort, so a client should also refresh on its own. For security teams, the point is that tool lists can change after you approved them.
How the list is built
The architecture overview describes it. A client sends a tools list request, and the server answers with each tool's name, title, description and input schema. The app combines the tools from all connected servers into one set the model can use.
The tools specification says that the set may be empty, may change over time, and may vary by the authorization presented, for example returning only the tools that the caller's granted scopes allow.
How change reaches the app
Servers that declare a list changed capability can notify clients. Change notifications are opt in: the client opens a long lived subscription stream and names the notification types it wants, and the server sends matching ones on that stream. On receiving one, the client asks for the list again.
The documentation is candid about limits. It says there are no guarantees that every notification is sent or received, particularly across reconnects, and that clients should also rely on polling to keep results fresh.
Why a security team cares
| Event | Risk |
|---|---|
| Vendor adds a write tool | Capability grows after approval |
| Vendor changes a description | Model behavior shifts |
| Vendor removes a tool | Workflows break |
| Your token gains scopes | More tools appear for that user |
Claude's help center warns that server developers can change tool behavior without notice. Combine that with a list that can change at any time, and a one time approval is not enough.
A change control routine
- Record the approved tool list with names and descriptions on the day of approval.
- Re-export it on a schedule, such as weekly, and compare.
- Treat a new write tool as a new approval.
- Ask the vendor for release notes that mention tool changes.
- Disable tools you do not use from the chat app's tool menu.
A quick test
After connecting, note the tool count. Ask the vendor to enable one additional tool. Check how long the chat app takes to show it, and whether you must reconnect. That tells you what to expect in production.
A worked example: a quiet tool addition
This is illustrative. A team approved a connector in January with eleven read tools. In May the vendor releases an update that adds a twelfth tool, a write tool that creates tickets. The release notes mention it in a long list. The chat app picks up the new tool on its next refresh.
Nobody on the team reads the release notes closely. A user sees a prompt asking whether to allow the new tool, clicks Allow always, and a week later the assistant creates a handful of tickets that nobody asked for after misreading a result.
Now the better version. The team keeps a snapshot of the approved list. A weekly job exports the current list and compares it with the snapshot. The diff shows a new tool on Monday. The connector owner reads the description, tests it in a sandbox, and decides to keep prompts on. The change is recorded.
Step by step: build a tool list diff
- On approval day, export the full tool list with names, descriptions and input schemas. Save it with the date.
- Pick a schedule, such as weekly.
- On each run, export the list again.
- Compare names first, then descriptions, then schemas.
- Flag any added, removed or changed tool.
- Send the flag to the connector owner.
- Update the snapshot after a decision.
If your chat app cannot export the list, use the vendor's documentation or the vendor's test environment, and ask the vendor to provide a changelog you can trust.
Table: what a list change can mean
| Change | Likely meaning | Action |
|---|---|---|
| New tool | New capability | Review before use |
| Removed tool | Feature retired or renamed | Check dependent workflows |
| Description edited | Behavior or marketing change | Re-read and test |
| Input schema changed | Tool takes new arguments | Check for new data flow |
| Order changed only | Probably nothing | Ignore |
Why refresh timing matters
Because notifications are best effort and clients should poll, there can be a window where the app's list differs from the server's. During that window an approved tool might have been removed, or a new tool might not yet be visible. For security review this is mostly harmless, but for troubleshooting it explains why two users can briefly see different lists.
Authorization and lists
The specification allows the list to vary by the authorization on the request. So two users with different scopes may legitimately see different tools. When comparing snapshots, compare like with like, using the same test account each time.
Ask the vendor
How are tool changes announced? Is there a changelog, and does it list tools separately from other changes? Can administrators hold back new tools until approved?
Where Safeguard fits
Safeguard offers an MCP Guardrail for policy over tools agents may call, so a newly added tool does not become usable by default. The free scan is an easy place to start looking at findings.
Try it yourself
Click through it at your own pace, or open it full screen.
Find the list of tools the server exposes. That is the list to snapshot and compare after each vendor release.
Quick check
Will my chat app always know about a new tool right away?
Not guaranteed. The documentation says notifications are best effort and clients should poll too.
Can the tool list differ between two users?
Yes. The specification allows the set to vary by the authorization presented on the request.
Can I stop new tools from being used automatically?
Ask whether administrators can hold new tools, and keep approval prompts on for any tool you have not reviewed.
Sources
- MCP architecture overview
- MCP specification, tools
- Claude Help Center, custom connectors using remote MCP
Last reviewed: 19 October 2026.
