[RFC] Server-Side Filtering of Primitives based on Client Scopes (Governance & Security)

[titoparizotto]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

[RFC] Server-Side Filtering of Primitives based on Client Scopes (Governance & Security)

Context

As a Technical Architect focusing on MCP governance, I’ve identified a gap in how discovery and authorization interact within the current protocol specification.

Currently, when an McpClient connects to an McpServer, they exchange security information during authentication. Subsequently, the client calls discovery methods like {primitives}/list (e.g., tools/list, resources/list) to understand the server's capabilities.

The Problem

Today, the discovery process is largely "all or nothing." If a client is authenticated, the server typically returns the full list of available primitives. However, in enterprise environments with strict governance, we often face:

1. Diverse Clients: Clients with different privilege levels (e.g., read-only vs. admin) connecting to the same server.
2. Sensitive Tools: Some tools/resources should remain invisible to unauthorized users to prevent "discovery-based" security risks and to reduce LLM hallucination (attempting to use tools the user shouldn't know exist).

Today, to ensure this security layer is applied, developers are forced to implement a custom orchestration or middleware layer between the Client and the Server to intercept and filter JSON-RPC responses.

Proposed Idea: Scope-Aware Discovery & Notifications

I propose that the MCP Specification formally supports Server-Side Filtering during the listing phase and targeted notifications. The server should validate the client's credential scopes against the required permissions of each primitive before including it in the {primitives}/list response or triggering a change notification.

Example Scenario

• Client A has read scope.

• Client B has write scope.

• Client C has read-write scope.

• Tool A requires read permission.

• Tool B requires write permission.

Resulting behavior:

• tools/list for Client A returns only Tool A.
• tools/list for Client B returns only Tool B.
• tools/list for Client C returns both.

Benefits

• Enforcement of Principle of Least Privilege (PoLP): Security starts at discovery. We ensure that clients (and LLMs) only interact with what they are strictly allowed to access.
• Reduced LLM Hallucinations: Filtering ensures the model's action space is always valid, preventing errors when an LLM tries to call a tool it cannot execute.
• Optimized Token Economy: Filtering reduces payload size and prevents polluting the LLM's context window with irrelevant tools.
• Infrastructure Simplification: Eliminates the need for "Governance Proxies". A single MCP Server can securely serve different roles.
• Information Leakage Protection: Prevents unauthorized clients from knowing that restricted primitives were added or modified via global notifications.

Implementation Thoughts

1. Capability Declaration (Server-Side)

Servers can declare their ability to handle scope-based visibility and notifications through a new capability flag:

{
  "capabilities": {
    "tools": {
      "listChanged": true,
      "authRequired": true
    }
  }
}

2. Parameterized Listing (Client-Side)

To ensure this layer of security is applied directly at the MCPServer side, I propose adding parametrization to the listing call. This allows the server to explicitly validate the scope of the credential against the required permission of each primitive:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "cursor": "optional-cursor-value",
    "credentials": "your-auth-token-or-scope-identifier"
  }
}

3. Scoped Notifications

When authRequired is true, the server optimizes notifications. The notifications/tools/list_changed signal is only sent to clients whose specific authorized view has changed. This avoids unnecessary refreshes for unauthorized clients and prevents information leakage.

Conclusion

The goal is to ensure the RequestContext in the SDKs carries the authenticated identity/scopes, allowing the list and notification handlers to prune results dynamically.

I would love to hear the community's thoughts on standardizing authRequired and this listing parametrization to improve MCP's security posture for production environments.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[PederHP]

This is already doable with the protocol as it is. The C# SDK has examples of how to use Authorization middleware to filter primitives. You can freely design and apply your permissions model by using either OAuth or custom auth, and deriving claims/scope from these. There is some work on-going for tool scopes and for more fine-grained auth at a protocol level, but what you describe should be doable with the current spec and SDKs. You can do this in the server, and you don't need custom middleware.

See for example: https://github.com/modelcontextprotocol/csharp-sdk/blob/main/docs/concepts/filters.md

[scottslewis]

If I understand this proposal correctly, it's meant to specify dynamic server-side filtering, so that all implementations (of clients and servers) could be depended upon to provide this mechanism (i.e. interoperability).

Without specification, clients and servers in multiple languages cannot depend upon the mechanism behaving consistently across individual specific impls of clients and servers.

[rsdouglas]

Really thoughtful RFC @titoparizotto! The "all or nothing" discovery problem you're describing is a significant gap.

Your point about reducing LLM hallucinations by filtering the action space is spot-on. We've been tackling a related problem—agents needing API access without credential exposure—and found that capability-based filtering at the API level can work well alongside tool filtering.

For example, an agent might be approved to "read GitHub repos" (specific API capability) but not "delete repos", even though both would technically use a "github" tool. The approval happens at request time with TTL expiration, so the access naturally expires.

This creates a nice layering:

1. Protocol level (what your RFC addresses): Which tools/resources are visible
2. Runtime level: Which specific API calls within those tools are permitted

The interesting question is how these layers should interact in the spec. Should servers declare capability requirements in their tool schemas? Or is this better handled at a different protocol layer?

We've been experimenting with this in Janee (https://github.com/rsdouglas/janee) if you want to see one implementation approach, but I'm curious how you're thinking about the spec-level changes needed.

Would capability metadata in the tool schema be sufficient, or does this need deeper protocol changes?