fix(server): throw when resource subscribe capability is missing

[arimu1]

Summary

Fixes#2545 by making missing resources.subscribe a hard local capability error on both halves of the resource-subscription path:

1. Notifications — sendResourceUpdated → assertNotificationCapability('notifications/resources/updated') now requires capabilities.resources.subscribe and throws SdkError(CapabilityNotSupported), matching every other local capability mistake in this file (and the client, which already throws for resources/subscribe).
2. Handler registration — assertRequestHandlerCapability now gates resources/subscribe and resources/unsubscribe the same way, so setRequestHandler('resources/subscribe', …) without the advertised bit no longer succeeds silently.

notifications/resources/list_changed still only requires resources (not subscribe).

Test plan

• packages/server unit tests: throw without subscribe; succeed with subscribe; setRequestHandler reject/allow for subscribe & unsubscribe
• Full @modelcontextprotocol/server suite: 453/453
• pre-push typecheck / build / lint green

Notes

Switched from the initial warn-once approach to throw after review feedback: warn left the server half inconsistent with the client and with every other local capability check in server.ts.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 010294f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@2550

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@2550

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@2550

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@2550

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@2550

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@2550

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@2550

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@2550

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@2550

commit: 010294f

[ondraulehla]

Nice, this covers the notification side. One thing it doesn't touch: registering the handler is silent too. assertRequestHandlerCapability gates resources/list, resources/read and resources/templates/list on resources, but resources/subscribe and resources/unsubscribe aren't in that switch at all, so setRequestHandler('resources/subscribe', ...) works fine without the bit. That's the other half of #2545, the one where the client's subscribe request is what goes nowhere.

The other thing worth a maintainer call is warn vs throw. Every local capability mistake in this file throws SdkError(CapabilityNotSupported), and those checks aren't behind enforceStrictCapabilities, since Protocol.notification() calls assertNotificationCapability unconditionally and that option's docs call a mis-declared local capability a logic error. The client throws for resources/subscribe as well, so warning on the server side leaves the two halves inconsistent.

I'd gone down the throwing route with tests for both halves before I spotted your PR. Happy to hand that over or to open a follow-up for the handler gate once this lands, whichever works best.

[arimu1]

@ondraulehla Thanks — took both halves of the suggestion.

• Throw vs warn: switched to SdkError(CapabilityNotSupported) via assertNotificationCapability for `notifications/resources/updated` (same path as every other local capability mistake; not behind `enforceStrictCapabilities`).
• Handler gate: `assertRequestHandlerCapability` now requires `resources.subscribe` for `resources/subscribe` and `resources/unsubscribe`.

Tests cover send + both handler registrations. Still draft while the fork's ready-for-review slot is held by #2549; happy to mark ready once that clears (or if a maintainer wants it earlier).