MCP OAuth registration omits response_types, breaking servers that require it (e.g. Neon)

Summary

Connecting an MCP server over Streamable HTTP with OAuth fails at startup against authorization servers that require response_types in the dynamic client registration request. Crush's registration metadata never populates that field.

Environment

• crush v0.94.2 (Homebrew)
• macOS, Apple Silicon
• Target server: https://mcp.neon.tech/mcp

Reproduction

Configure the server and start Crush:

mcp add neon --type http --url "https://mcp.neon.tech/mcp" --oauth true

The same startup also configures Linear at https://mcp.linear.app/mcp, and that one authenticates successfully, so the failure is specific to the remote server's registration requirements rather than to HTTP MCP transport in general.

Actual behaviour

The client fails to initialise during registration:

ERROR MCP client failed to initialize
  error="calling \"initialize\": sending \"initialize\": rejected by transport:
  failed to register client: registration failed: invalid_request
  (response_types is required and must only include supported response types)"
  name=neon

Cause

internal/oauth/mcp/handler.go builds the dynamic client registration metadata without ResponseTypes:

Metadata: &oauthex.ClientRegistrationMetadata{
    ClientName:   "Crush",
    RedirectURIs: []string{redirectURL},
    GrantTypes:   []string{"authorization_code", "refresh_token"},
},

The registration request itself is issued by the oauthex package from github.com/modelcontextprotocol/go-sdk, so the field is simply never set by Crush before the SDK sends it.

Note on the specification

response_types is optional in RFC 7591 §2 — if omitted, the client is assumed to use only the code response type. So the server here is being stricter than the RFC requires, which is presumably why other providers work fine.

Sending the field explicitly is still RFC-valid, and it makes Crush compatible with servers that require it, so it seems worth adding on the client side.

Suggested fix

Include the response type in the metadata:

Metadata: &oauthex.ClientRegistrationMetadata{
    ClientName:   "Crush",
    RedirectURIs: []string{redirectURL},
    GrantTypes:   []string{"authorization_code", "refresh_token"},
    ResponseTypes: []string{"code"},
},

Workaround

Authenticate with the provider's API key instead of OAuth, which bypasses registration entirely:

mcp add neon --type http --url "https://mcp.neon.tech/mcp" \
  --header Authorization "Bearer $NEON_API_KEY"