Yes, in one specific way. The current MCP draft says a tool list may vary by the authorization on each request, such as only tools the caller's scopes allow, but not per connection or as a side effect of other requests. Hiding tools by identity helps if the server still enforces access on every call.
What the spec allows
The draft says a server that declares tools must respond to a tools list request with the tools currently available to the requesting client. The set may be empty and may change over time. It must not vary per connection or as a side effect of other requests. It may vary by the authorization presented on the request, because credentials are per request input, not connection state.
Why filter the list at all
A model that never sees a tool cannot be talked into calling it. Filtering the list reduces the attack surface, shortens the prompt and avoids confusing the model with options it cannot use. It matches the OWASP advice to give the model only the extensions it needs.
Filtering is not enforcement
| Layer | Purpose | Can it stand alone |
|---|---|---|
| Filtered tool list | Reduce what the model sees | No |
| Per call authorization | Block calls the caller may not make | Yes |
| Scope step up | Ask for more access when needed | No, it depends on the above |
A hidden tool can still be called by a client that knows its name. The spec requires servers to implement access controls, so check authorization on every call and return 403 with the scope challenge when the token is not enough.
A design that works
- Define scopes by action, such as read, write and admin, not by product area.
- Issue the smallest set at first sign in.
- Build the tool list from the scopes on the current token.
- Check the same scopes again on every tool call.
- On a denied call, return an insufficient scope response naming the missing scope so the client can ask for it.
- Log the elevation request and the result.
What to avoid
Do not vary tools by an unauthenticated header, a session the client sets itself or the order of earlier calls. That breaks the rule that the list must not change as a side effect, and it makes behaviour hard to test.
Safeguard includes agent identity and policies, gates and guardrails for per agent access. A free scan is at https://gold.safeguard.sh/scan.
Try it yourself
See which Safeguard tools the assistant has available in the demo, and compare that list with what a different account might be allowed to see.
Click through it at your own pace, or open it full screen.
Quick check
Does hiding a tool prevent calls to it?
No. Servers must still check access on each call. The list is a convenience for the model, not a security boundary.
Can the tool list change during a session?
It may change over time, but not as a side effect of other requests on the connection. Clients should expect list changes and re-check approvals.
Sources
- MCP specification: Tools (draft)
- MCP specification: Authorization (draft)
- OWASP GenAI: LLM06 Excessive Agency
Last reviewed: 19 October 2026.
