feat(client,core): application_type client metadata with native/web inference (SEP-837)

[mattzcarey]

Summary

Implements SEP-837 (clarify client type requirements) for dynamic client registration. The draft authorization spec, basic/authorization/client-registration.mdx § "Application Type and Redirect URI Constraints", is MUST-level:

Clients MUST specify an appropriate application_type during dynamic client registration. OIDC-based registries default the field to "web", which conflicts with native/loopback redirect URIs; authorization servers that do not implement OIDC registration ignore the field. Native applications (desktop, CLI, loopback redirects) SHOULD register with "native"; remote browser-based applications SHOULD use "web".

Previously the SDK made compliance impossible: OAuthClientMetadataSchema uses .strip() and had no application_type, so any user-supplied value was silently dropped from DCR request bodies, and OAuthClientInformationFullSchema stripped it from registration responses.

What changed

• @modelcontextprotocol/core (packages/core/src/shared/auth.ts): OAuthClientMetadataSchema gains optional application_type (typed z.string() because OIDC permits extension values beyond 'web'/'native'; JSDoc documents the standard values and SEP-837 semantics). Since OAuthClientInformationFullSchema merges the metadata schema, the field now also survives DCR response parsing.
• @modelcontextprotocol/client (packages/client/src/client/auth.ts): registerClient() infers application_type when it is absent from the provided metadata: 'native' if every redirect_uris entry is loopback (localhost, 127.0.0.1, [::1]) or a custom non-http(s) scheme; otherwise 'web'. The rule lives in a new exported helper inferApplicationType(redirectUris). Empty/unparseable inputs conservatively yield 'web' (the OIDC default).
• JSDoc on OAuthClientProvider.clientMetadata and a short note in docs/client.md.
• Tests: request-body round-trip, response parse retention, and inference cases (loopback-only → native, custom scheme → native, https → web, mixed → web, localhost.example.com is not loopback, explicit value never overridden).
• Changeset: client minor (new export + behavior), core patch (additive optional schema field).

Design choice for maintainers

Inference only applies when the field is absent — an explicitly provided application_type is never overridden. Happy to drop the inference entirely and make this docs-only (schema field + JSDoc) if you'd prefer registration bodies stay byte-for-byte what the provider supplies.

Validation

• pnpm build:all, pnpm typecheck:all, pnpm lint:all — clean
• @modelcontextprotocol/client tests: 379/379 pass (11 files)
• @modelcontextprotocol/core tests: 463/463 pass (22 files)
• Client conformance suite (pnpm run test:conformance:client:all): the 13 scenarios that failed only on the SEP-837 application_type DCR check now pass, so they are removed from test/conformance/expected-failures.yaml (the runner fails on stale entries). auth/scope-step-up stays in the baseline for an unrelated SEP-2350 scope-union WARNING.

Downstream impact: cloudflare/agents' DurableObjectOAuthClientProvider uses remote https redirect URLs on Workers → inferred 'web', which is correct; no changes needed downstream.

Closes #2198

[changeset-bot]

🦋 Changeset detected

Latest commit: 7f811c4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@modelcontextprotocol/client	Minor
@modelcontextprotocol/core	Patch

Not sure what this means? Click here to learn what changesets are.

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

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@2266

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/codemod@2266

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@2266

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server-legacy@2266

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@2266

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/fastify@2266

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@2266

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@2266

commit: 7f811c4

[felixweinberger]

Needs a rebase first (conflicting with main), and the conflict is in test/conformance/expected-failures.yaml. Main is now on conformance 0.2.0-alpha.3; this branch still pins alpha.1. As part of the rebase, two conformance things:

1. Bump the pin to 0.2.0-alpha.3 and reconcile the baseline.
2. Drop auth/scope-step-up from expected-failures.yaml.

Once #2265 is in main (scope union plus the harness fix) and application_type is here, auth/scope-step-up passes end to end.

I verified it goes 28/28 with both SEPs in, so it should come off the baseline with this PR once #2265 is fixed & landed and we rebased this one on top.