MCP tools/list exposes tools the caller cannot invoke (security not evaluated)

Inizia con ApiPlatform\Mcp\Server\ListHandler e il punto di ingresso tools/list, quindi confrontalo con il comportamento di sicurezza di tools/call descritto in #8435. Esamina le domande sulla policy indicate per la sicurezza a livello di operazione e le espressioni con object, e usa i passaggi di riproduzione per verificare che gli strumenti negati non espongano più metadati in nessuna delle due modalità di listener.

Description

ApiPlatform\Mcp\Server\ListHandler enumerates every MCP tool when answering tools/list, regardless of the security expression declared on #[McpTool]. A caller who is not allowed to invoke a tool can still discover it: its name, description and full input schema are returned.

This is an information-disclosure issue rather than an access-control bypass — invocation itself is correctly denied. But the tool name, its description and the shape of its arguments frequently reveal internal domain structure that the security expression was meant to keep hidden.

Found while reviewing #8435, which fixed the related (and more severe) problem that security was a complete no-op on the tools/call path when use_symfony_listeners: true. That fix closed invocation; listing was out of its scope.

Current behaviour

• tools/call — security, securityPostDenormalize, securityPostValidation and Link-level security are all enforced (as of #8435, on both use_symfony_listeners modes).
• tools/list — no security expression is evaluated. Every registered tool is listed for every caller, anonymous included.

Expected behaviour

tools/list should omit tools whose security expression evaluates to false for the current caller, mirroring how collection operations filter what a user may see.

Open design questions worth settling before implementation:

• Only the operation-level security expression can reasonably be evaluated at list time — securityPostDenormalize and securityPostValidation need an object and arguments that do not exist yet. The listing filter should therefore be documented as best-effort on security only.
• Expressions referencing object cannot be evaluated during listing. Those tools need a defined policy: listed, hidden, or a configuration flag.

Reproduce

1. Declare a tool with a security expression that denies anonymous callers:

#[McpTool(name: 'secured_tool', security: "is_granted('ROLE_ADMIN')")]

2. Issue an unauthenticated tools/list JSON-RPC call to /mcp.
3. secured_tool appears in the response, with its description and input schema.
4. A subsequent tools/call for it is correctly rejected.

Reproduces in both use_symfony_listeners: true and the default mode — the listing path never consulted security in either.

Notes

• Pre-existing; not a regression from #8435.
• ApiPlatform\Mcp\Server\Handler is marked @experimental, so a behaviour change here is acceptable.