Docs: registerClient's @deprecated notice cites SEP-2577; DCR deprecation is PR #2858 (SEP-2577 is Roots/Sampling/Logging)

Start at the registerClient declaration in dist/index.d.mts, then check the .d.cts and source equivalent mentioned in the issue. Update the DCR deprecation reference from SEP-2577 to PR #2858, and verify the generated declarations or source remain consistent; done means the docstring identifies the correct deprecation while retaining the SEP-991 migration reference.

Summary

The @deprecated JSDoc on registerClient attributes the Dynamic Client Registration deprecation to SEP-2577. Per the 2026-07-28 changelog, DCR was deprecated by PR #2858; SEP-2577 deprecates Roots, Sampling, and Logging — an unrelated change.

Where

@modelcontextprotocol/client@2.0.0, dist/index.d.mts (and the .d.cts / source equivalent), on declare function registerClient:

/**
 * @deprecated Dynamic Client Registration is deprecated as of protocol version
 * 2026-07-28 (SEP-2577) in favor of Client ID Metadata Documents (SEP-991).
 * Remains functional during the deprecation window (at least twelve months).
 * Prefer a CIMD URL `client_id` when the authorization server advertises
 * `client_id_metadata_document_supported`; the SDK already gates on this for you.
 */

What the spec says

From the 2026-07-28 changelog, Deprecated:

1. Deprecate the Roots, Sampling, and Logging features (SEP-2577).

4. Deprecate the OAuth 2.0 Dynamic Client Registration Protocol (RFC7591) as a client registration mechanism in favor of Client ID Metadata Documents (PR #2858). It remains available for backwards compatibility with authorization servers that do not support Client ID Metadata Documents.

So the docstring has the two deprecations' identifiers crossed.

Why it's worth fixing

This docstring is doing real work — it is often the first and only place an implementer encounters the deprecation, since it surfaces in editor hovers and in tsc deprecation warnings without anyone opening the changelog. We cited SEP-2577 from it in an internal design document and a team-wide announcement before checking the primary source, and had to issue a correction. Anyone quoting the SEP number to a vendor or an auditor — a plausible use, given this is an auth deprecation with a compliance-visible migration — propagates it further.

Suggested fix

- * @deprecated Dynamic Client Registration is deprecated as of protocol version
- * 2026-07-28 (SEP-2577) in favor of Client ID Metadata Documents (SEP-991).
+ * @deprecated Dynamic Client Registration is deprecated as of protocol version
+ * 2026-07-28 (PR #2858) in favor of Client ID Metadata Documents (SEP-991).

Happy to open a PR if that's useful.

Two smaller notes on the same docstring

1. "at least twelve months" is accurate but slightly undersells the guarantee — the feature lifecycle policy (SEP-2596) sets a minimum twelve-month window, making 2027-07-28 the earliest date DCR is eligible for removal. A concrete date is more actionable than a relative window for anyone planning a migration.

2. "the SDK already gates on this for you" reads as though registerClient itself checks client_id_metadata_document_supported and short-circuits. As far as I can tell from the type signature, registerClient performs the registration unconditionally and the gating lives in the higher-level auth() flow. If that's right, callers using registerClient directly — which the deprecation notice is precisely aimed at — get no gating, and the sentence may lead them to skip the capability check. Worth a clarifying clause on where the gate actually lives.

Environment

@modelcontextprotocol/client 2.0.0