Enable FastMCP to filter tools, prompts, resources using a fine grained policy #1031

Activity

1. vndee commented on Jun 26, 2025

   

   vndee

   on Jun 26, 2025

   More actions

   same here, we need this feature!

   👍React with 👍4Reacted by Karel Antonio Verdecia Ortiz, dmiakotin, Violet O and Jessica Temporal
2. felixweinberger

   added

   authIssues and PRs related to Authentication / OAuthIssues and PRs related to Authentication / OAuth

   enhancementRequest for a new feature that's not currently supportedRequest for a new feature that's not currently supported

   on Oct 7, 2025
3. felixweinberger

   marked Enable Fine Grain Authz by Scopes or Other Ways to Specific Tools within MCP Server #1223 as a duplicate of this issue on Oct 7, 2025
4. jtemporal commented on Dec 12, 2025

   

   jtemporal

   on Dec 12, 2025

   More actions

   Just wanted to add a +1 in the need of this feature.

   Some more context in case it helps: Adding this would bring parity with the TS SDK that already is possible to use fine grained policies. At Auth0 we implemented a sample app in TS that has this capability and can be found here and we were looking to do the same in Python which is not possible in the tests we've done so far.
5. maxisbey

   added

   v2Affects the v2 line (2.x on main)Affects the v2 line (2.x on main)

   on Jan 5, 2026
6. Ram9199 commented on May 27, 2026

   

   Ram9199

   on May 27, 2026

   More actions

   @davemssavage this fine-grained policy idea is very close to the layer I am working on.

   I am building Agent_Sudo as a policy/audit gateway for MCP tool execution. The policy decision takes actor, tool, prompt/resource, arguments, target resource/path, TTL, and max-use constraints, then returns allow, deny, approval-needed, or delegated-allow. Each decision is logged.

   For FastMCP, would you expect this policy layer to live inside the server framework itself, or would a middleware/gateway around an MCP server be acceptable?
7. hippoley commented on Oct 3, 2026

   

   hippoley

   on Oct 3, 2026 – with ChatGPT Codex Connector

   More actions

   There is a useful scope split here now that #3613 has landed: the SDK has a documented mechanism that can refuse a tools/call before the handler runs, so the remaining question in this issue is less "can Python enforce a policy?" and more "what policy surface should FastMCP standardize?"

   I think it would help to separate two capabilities that are easy to conflate:

   • visibility/discovery policy — whether a tool/resource/prompt appears in */list for this principal;
   • execution authorization — whether a concrete invocation with concrete arguments is allowed to reach the handler.

   Those are not interchangeable. Hiding a tool from tools/list does not by itself authorize or deny a direct tools/call, and an execution gate may need argument/resource context that discovery-time filtering does not have.

   A minimal plugin contract could therefore stay policy-engine agnostic while exposing two explicit hooks (names illustrative):

   filter_capabilities(principal, capabilities) -> capabilities
   authorize_invocation(principal, method, validated_params) -> allow | deny
   

   One implementation could use Auth0/FGA, another ACLs, another local deterministic policy; the SDK would only define where the decision is consumed.

   One detail I would want nailed down before an API shape: should the execution hook receive raw request params or the SDK's validated/normalized params? For argument-sensitive authorization, that becomes a security boundary rather than just an ergonomics choice.

   If the intended scope of #1031 is discovery filtering only, I'd keep execution authorization explicitly out of it rather than let a single "policy" hook accidentally imply both.