Skip to content

CHANGELOG.md

Latest commit

 

History

History
48 lines (34 loc) · 4.7 KB

CHANGELOG.md

File metadata and controls

48 lines (34 loc) · 4.7 KB

@modelcontextprotocol/client

2.0.0

Minor Changes

  • #1527 dc896e1 Thanks @felixweinberger! - Add discoverOAuthServerInfo() function and unified discovery state caching for OAuth

    • New discoverOAuthServerInfo(serverUrl) export that performs RFC 9728 protected resource metadata discovery followed by authorization server metadata discovery in a single call. Use this for operations like token refresh and revocation that need the authorization server URL outside of auth().
    • New OAuthDiscoveryState type and optional OAuthClientProvider methods saveDiscoveryState() / discoveryState() allow providers to persist all discovery results (auth server URL, resource metadata URL, resource metadata, auth server metadata) across sessions. This avoids redundant discovery requests and handles browser redirect scenarios where discovery state would otherwise be lost.
    • New 'discovery' scope for invalidateCredentials() to clear cached discovery state.
    • New OAuthServerInfo type exported for the return value of discoverOAuthServerInfo().

  • #1614 1a78b01 Thanks @pcarleton! - Apply resolved scope consistently to both DCR and the authorization URL (SEP-835)

    When scopes_supported is present in the protected resource metadata (/.well-known/oauth-protected-resource), the SDK already uses it as the default scope for the authorization URL. This change applies the same resolved scope to the dynamic client registration request body, ensuring both use a consistent value.

    • registerClient() now accepts an optional scope parameter that overrides clientMetadata.scope in the registration body.
    • auth() now computes the resolved scope once (WWW-Authenticate → PRM scopes_supported → clientMetadata.scope) and passes it to both DCR and the authorization request.

Patch Changes

  • #1343 4b5fdcb Thanks @christso! - Fix OAuth error handling for servers returning errors with HTTP 200 status

    Some OAuth servers (e.g., GitHub) return error responses with HTTP 200 status instead of 4xx. The SDK now checks for an error field in the JSON response before attempting to parse it as tokens, providing users with meaningful error messages.

  • #1534 69a0626 Thanks @josefaidt! - remove npm references, use pnpm

  • #1386 00249ce Thanks @PederHP! - Respect capability negotiation in list methods by returning empty lists when server lacks capability

    The Client now returns empty lists instead of sending requests to servers that don't advertise the corresponding capability:

    • listPrompts() returns { prompts: [] } if server lacks prompts capability
    • listResources() returns { resources: [] } if server lacks resources capability
    • listResourceTemplates() returns { resourceTemplates: [] } if server lacks resources capability
    • listTools() returns { tools: [] } if server lacks tools capability

    This respects the MCP spec requirement that "Both parties SHOULD respect capability negotiation" and avoids unnecessary server warnings and traffic. The existing enforceStrictCapabilities option continues to throw errors when set to true.

  • #1534 69a0626 Thanks @josefaidt! - clean up package manager usage, all pnpm

  • #1279 71ae3ac Thanks @KKonstantinov! - Initial 2.0.0-alpha.0 client and server package
⚡