vercel/ai · error

Incompatible auth server: does not support response type ${r

Error message

Incompatible auth server: does not support response type ${responseType}

What it means

startAuthorization hard-codes the OAuth response type 'code' (authorization code flow). If discovered authorization server metadata is present but its response_types_supported array does not include 'code', the function throws rather than building an authorization URL that the server would reject.

Source

Thrown at packages/mcp/src/tool/oauth.ts:702

    resource,
  }: {
    metadata?: AuthorizationServerMetadata;
    clientInformation: OAuthClientInformation;
    redirectUrl: string | URL;
    scope?: string;
    state?: string;
    resource?: URL;
  },
): Promise<{ authorizationUrl: URL; codeVerifier: string }> {
  const responseType = 'code';
  const codeChallengeMethod = 'S256';

  let authorizationUrl: URL;
  if (metadata) {
    authorizationUrl = new URL(metadata.authorization_endpoint);

    if (!metadata.response_types_supported.includes(responseType)) {
      throw new Error(
        `Incompatible auth server: does not support response type ${responseType}`,
      );
    }

    if (
      !metadata.code_challenge_methods_supported ||
      !metadata.code_challenge_methods_supported.includes(codeChallengeMethod)
    ) {
      throw new Error(
        `Incompatible auth server: does not support code challenge method ${codeChallengeMethod}`,
      );
    }
  } else {
    authorizationUrl = new URL('/authorize', authorizationServerUrl);
  }

  const challenge = await pkceChallenge();
  const codeVerifier = challenge.code_verifier;

View on GitHub (pinned to 69428b1f8b)

Solutions

  1. Reconfigure the authorization server/client to support the authorization code flow (add 'code' to allowed response types).
  2. Verify the server's metadata: curl the .well-known endpoint and check response_types_supported contains 'code'.
  3. Ensure you are connecting to the correct authorization server (the one advertised in the MCP server's protected resource metadata), not a different one.
  4. If the server only supports implicit flow, it cannot be used with MCP; switch to a compliant server.

Example fix

// before: AS configured with response types ["token"] (implicit only)
// after: enable authorization code flow for the client in the AS admin console
// { "response_types_supported": ["code", "token"] }
Defensive patterns

Strategy: validation

Validate before calling

const metadata = await discoverAuthorizationServerMetadata(asUrl);
if (metadata && !metadata.response_types_supported.includes('code')) {
  throw new Error('Auth server does not support the authorization code flow required by MCP');
}

Type guard

function supportsCodeFlow(m: { response_types_supported: string[] }): boolean {
  return Array.isArray(m.response_types_supported) && m.response_types_supported.includes('code');
}

Try / catch

try {
  await startAuthorization(asUrl, { metadata, clientInformation, redirectUrl });
} catch (error) {
  if (String(error.message).includes('does not support response type')) {
    console.error('Enable the authorization code flow on the auth server client configuration.');
  }
}

Prevention

When it happens

Trigger: Calling startAuthorization (directly or via auth()) with metadata whose response_types_supported excludes 'code' — e.g. a server advertising only implicit ('token') or hybrid flows.

Common situations: Pointing an MCP client at an authorization server configured for implicit-only flows (legacy OAuth2 setups, some old Azure AD v1 app registrations), or a metadata document with a truncated/incorrect response_types_supported list.

Related errors


AI-assisted analysis of vercel/ai@69428b1f8b (2026-08-30). Data as JSON: /api/errors/0f80bd1e87b5be6f. Report an issue: GitHub.