[RamjotSingh]

Makes subscriptions/listen all or nothing. A request that lists an entry the principal may not access is refused with -32602 (Invalid params), naming the entries in data.denied, instead of being acknowledged in part, and no stream opens. The refusal is an ordinary JSON-RPC error, sent to clients of every protocol version.

Motivation and Context

The specification does not say what a server does when a filter lists something the principal may not access. Leaving it out of the acknowledgment leaves a client believing it watches resources it does not, and a client that compares the acknowledgment with its request learns only that something is missing, not why. The question comes up whenever a client re-establishes a stream after access changed.

How Has This Been Tested?

Prototype on a TypeScript SDK fork, branch poc/authorization-lifetime (reviewer guide), which implements the combined draft in #63. When a stream opens, each entry of the filter goes through the same access check as notifications.

• Demo (pnpm --filter @mcp-examples/authorization-lifetime start:fast), scenario 3, step 4: a stream reopened with its old filter is refused, naming case-114.md, and the client reopens it on config.json alone and reports the change; another is refused the same way, and the client reports the loss without prompting.
• Tests: the refusal and its data.denied; the same refusal for a client of an earlier protocol version; the same filter without the denied entry acknowledged in full; a filter with no permitted entry refused, naming every entry.
• Build, lint, typecheck, and the SDK test suites pass, apart from three Windows-only failures that also occur on unmodified upstream main.

Breaking Changes

Behavioral, for every protocol version: such a request now receives -32602 instead of an acknowledgment. The code already exists, so older clients see an ordinary request error and need not understand data.denied.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change) - Soft Breaking
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

AI disclosure: Ideas and specs are mine but I have used AI to link it back into the existing protocol and SEPs that introduced them as well as formulate into official language from my draft. POC has been built by AI as well on my guidance.