`@RolesAllowed` and `list/tools`call

[sebastienblanc]

Hi,

Not sure if it's a bug or a feature request : I'm securing my MCP Server with quarkus-oidc , on top of the @authenticated on the class level I have roles defined for my tools :

  @RolesAllowed("platform-team")
    @Tool(name = "add-new-db-region", description = "Add a new database region")
    public String addNewDBRegion(String region) {
        Log.info("Adding new DB region: " + region);
        return "New DB region added: " + region;
    }

    @RolesAllowed("feature-team")
    @Tool(name = "request-new-db-region", description = "Request a new database region")
    public String requestNewDBRegion(String region) {
        Log.info("Request a new DB region: " + region);
        return "DB region requested: " + region;
    }

Calling the tool where the token has not the role is working as expected but the MCP Client still receives this tool in the beginning when doing the list/tools, shouldn't the tools be filtered out based on the @RolesAllowed or is this a feature request ?

[mkouba]

shouldn't the tools be filtered out based on the @RolesAllowed or is this a feature request ?

That's a good question. In general, the MCP spec does not support filtering and we do not mention this in the docs either. So I guess that it's a feature request ;-).

But to be honest, I'm not quite sure we will be able to implement this easily because we don't reflect @RolesAllowed and friends in MCP metadata. It's processed by Quarkus Security, i.e. @RolesAllowed just means that the CDI bean method is intercepted.

[sebastienblanc]

Yeah and after submitting this issue I have been thinking : "It's probably the app using the MCP Client that would have to handle a 'not permitted'"

[mkouba]

Yeah and after submitting this issue I have been thinking : "It's probably the app using the MCP Client that would have to handle a 'not permitted'"

Yes, it makes sense IMO.

In theory, we could add something into the metadata, i.e. the _meta section of each tool. So that a client has more info. You can even add your own metadata with @io.quarkiverse.mcp.server.MetaField. But it won't help much without cooperation from the client 🤷.

[sberyozkin]

Interesting... I suppose what the security annotations like @RolesAllowed control here is an access to the tool itself, they don't prevent it being listed as an available tool. I guess it is similar to all REST endpoint methods shown in Swagger UI, even if the user may not be able to call all of them

[sberyozkin]

That said, it is an interesting enhancement idea...

[mkouba]

I suppose what the security annotations like @RolesAllowed control here is an access to the tool itself, they don't prevent it being listed as an available tool

Yes, exactly.

I guess it is similar to all REST endpoint methods shown in Swagger UI, even if the user may not be able to call all of them.

Yes, it's very similar.

[sberyozkin]

@BarDweller also thought about this feature, the problem is we can not apply a security interceptor to an individual operation like list/tools.

We can use HTTP security policy to restrict for example /mcp/* but I wonder if we could come up with some mechanism to tell Quarkus MCP server that a given MCP protocol operation is controlled by some specific policy.

@mkouba Hi Martin, without even considering the security for now, if it were possible to intercept somehow individual MCP protocol ops, it would give some base to apply specific policies to them later, maybe we can chat about it in a couple of weeks

[BarDweller]

Aye.. I think a server is well within spec to present different tool lists based on the identity of the authenticated user.. from the llm perspective it would never know other lists are even present.. the same could be achieved today via other routes that I don't see as being in conflict with the spec. I think as long as the tools/list is not dynamic for any particular identity, then all is well. (And I'm not ruling out the idea of dynamic tool lists for an identity, just that doing that requires a lot more care, as without a notification mechanism for the changes, we end up with clients spamming tools/list periodically to ensure their list is current (which ironically, is something I'm doing over in https://github.com/bardweller/mcp-gateway for the purpose of testing if the list content has changed maliciously).

On an implementation level, easiest might be a ToolListProvider bean that defaults to current behavior that could be overridden by a user bean, which could use the identity from the context to generate the list.. or possibly a ToolListFilter would be simpler that could be passed the known list of tools, and could modify it.

I'm thinking that with OAuth usage where roles dictate services from vast sets of api surfaces (eg Google etc), this would lead to a single mcp server endpoint that reflected all the activities the user was allowed to handle.

[mkouba]

On an implementation level, easiest might be a ToolListProvider bean that defaults to current behavior that could be overridden by a user bean, which could use the identity from the context to generate the list.. or possibly a ToolListFilter would be simpler that could be passed the known list of tools, and could modify it.

@BarDweller You can implement a filter to define a set of visible features for a specific identity. Filters are applied to both "list" and "call/get/read" operations. I.e. something like https://docs.quarkiverse.io/quarkus-mcp-server/dev/guides-using-filters-and-checks.html#_request_context_filtering.

Hi Martin, without even considering the security for now, if it were possible to intercept somehow individual MCP protocol ops, it would give some base to apply specific policies to them later, maybe we can chat about it in a couple of weeks

@sberyozkin Yes, we can discuss adding generic interceptors, although I'm not quite sure we want this for any MCP operation..

[shrap42]

We had similar issue to solve, and the result is using this filter:

public class RolesBasedToolFilter implements ToolFilter {
 
  private static final Logger LOG = Logger.getLogger(RolesBasedToolFilter.class);
   
  private final Map<String, Set<String>> toolRolesMap = new HashMap<>();
   
  @Inject
  SecurityIdentity securityIdentity;
   
  @PostConstruct
  void init() {
      // Scan all CDI beans for @Tool methods with @RolesAllowed annotation
      scanForToolRoles(MyMcpService.class);
      // Add more classes here if you have tools in other classes:
      // scanForToolRoles(AnotherToolService.class);
       
      LOG.infov("RolesBasedToolFilter initialized with {0} role-protected tools: {1}",
      toolRolesMap.size(), toolRolesMap.keySet());
   }
   
  private void scanForToolRoles(Class<?> clazz) {
      for (Method method : clazz.getDeclaredMethods()) {
          Tool toolAnnotation = method.getAnnotation(Tool.class);
          RolesAllowed rolesAllowed = method.getAnnotation(RolesAllowed.class);
           
          if (toolAnnotation != null && rolesAllowed != null) {
              // Tool name is the method name (quarkus-mcp-server convention)
              String toolName = method.getName();
              Set<String> roles = Set.of(rolesAllowed.value());
              toolRolesMap.put(toolName, roles);
              LOG.debugv("Tool {0} requires roles: {1}", toolName, roles);
           }
       }
  }
   
  @Override
  public boolean test(ToolInfo tool, McpConnection connection) {
      Set<String> requiredRoles = toolRolesMap.get(tool.name());
       
      // If tool has no @RolesAllowed annotation, it's visible to all authenticated users
      if (requiredRoles == null || requiredRoles.isEmpty()) {
      return true;
      }
       
      // Get user's roles from security identity
      Set<String> userRoles = securityIdentity.getRoles();
       
      // Check if user has at least one of the required roles
      boolean hasAccess = requiredRoles.stream().anyMatch(userRoles::contains);
       
      if (!hasAccess && LOG.isDebugEnabled()) {
          LOG.debugv("Hiding tool '{0}' from user '{1}' - requires roles {2}, user has {3}",
          tool.name(),
          securityIdentity.getPrincipal() != null ? securityIdentity.getPrincipal().getName() : "anonymous",
          requiredRoles,
          userRoles);
      }
       
      return hasAccess;
    }
}