Limitation
The Asgardeo MCP Auth SDK currently enforces authentication at the /mcp route level by default. While this simplifies protection, it introduces a few key limitations:
- MCP servers cannot expose a mix of public and protected tools within the same endpoint.
- There is no support for fine-grained, tool-level access control, such as defining required scopes per tool.
Suggested Improvement
Introduce fine-grained, tool-level access control for MCP servers.
Developers should be able to define authorization requirements at the individual tool level, including specifying the scopes required to invoke each tool. This would enable:
- Selective exposure of public and protected tools within the same MCP server
- More precise enforcement of access control based on user permissions
- Better alignment with real-world use cases where different tools require different levels of access
This capability was previously supported in the MCP Auth Proxy (now deprecated), where tool-level scope configuration could be defined[1].
[1] https://github.com/wso2-attic/open-mcp-auth-proxy/blob/main/config.yaml#L55
Limitation
The Asgardeo MCP Auth SDK currently enforces authentication at the
/mcproute level by default. While this simplifies protection, it introduces a few key limitations:Suggested Improvement
Introduce fine-grained, tool-level access control for MCP servers.
Developers should be able to define authorization requirements at the individual tool level, including specifying the scopes required to invoke each tool. This would enable:
This capability was previously supported in the MCP Auth Proxy (now deprecated), where tool-level scope configuration could be defined[1].
[1] https://github.com/wso2-attic/open-mcp-auth-proxy/blob/main/config.yaml#L55