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
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
- Declare a tool with a
security expression that denies anonymous callers:
#[McpTool(name: 'secured_tool', security: "is_granted('ROLE_ADMIN')")]
- Issue an unauthenticated
tools/list JSON-RPC call to /mcp.
secured_tool appears in the response, with its description and input schema.
- 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
Description
ApiPlatform\Mcp\Server\ListHandlerenumerates every MCP tool when answeringtools/list, regardless of thesecurityexpression 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
securityexpression was meant to keep hidden.Found while reviewing #8435, which fixed the related (and more severe) problem that
securitywas a complete no-op on thetools/callpath whenuse_symfony_listeners: true. That fix closed invocation; listing was out of its scope.Current behaviour
tools/call—security,securityPostDenormalize,securityPostValidationand Link-levelsecurityare all enforced (as of fix(mcp): fix no security / validation in mcp tools when using symfony listeners #8435, on bothuse_symfony_listenersmodes).tools/list— no security expression is evaluated. Every registered tool is listed for every caller, anonymous included.Expected behaviour
tools/listshould omit tools whosesecurityexpression evaluates to false for the current caller, mirroring how collection operations filter what a user may see.Open design questions worth settling before implementation:
securityexpression can reasonably be evaluated at list time —securityPostDenormalizeandsecurityPostValidationneed an object and arguments that do not exist yet. The listing filter should therefore be documented as best-effort onsecurityonly.objectcannot be evaluated during listing. Those tools need a defined policy: listed, hidden, or a configuration flag.Reproduce
securityexpression that denies anonymous callers:tools/listJSON-RPC call to/mcp.secured_toolappears in the response, with its description and input schema.tools/callfor it is correctly rejected.Reproduces in both
use_symfony_listeners: trueand the default mode — the listing path never consulted security in either.Notes
ApiPlatform\Mcp\Server\Handleris marked@experimental, so a behaviour change here is acceptable.