[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