generated: '2026-08-13'
method: probed
source: https://mcp.mutinyhq.com/.well-known/oauth-authorization-server
docs: https://help.mutinyhq.com/articles/5003451538-connecting-mutiny-to-claude
summary: >-
  Mutiny's only machine-callable surface is its hosted MCP server, and it is protected by a full OAuth
  2.1 authorization-code flow with mandatory PKCE and RFC 7591 dynamic client registration. There is no
  API-key path, no personal access token, and no public REST API to authenticate against.
apis:
- api: Mutiny MCP Server
  base_url: https://mcp.mutinyhq.com/mcp
  security_schemes:
  - id: mutiny_mcp_oauth
    type: oauth2
    profile: OAuth 2.1 as required by the MCP authorization specification
    issuer: https://mcp.mutinyhq.com
    flows:
    - type: authorization_code
      authorization_endpoint: https://mcp.mutinyhq.com/oauth/authorize
      token_endpoint: https://mcp.mutinyhq.com/oauth/token
      pkce_required: true
      code_challenge_methods_supported:
      - S256
      response_types_supported:
      - code
      token_endpoint_auth_methods_supported:
      - client_secret_post
      - none
      scopes:
      - read_asset_groups
      - create_asset_groups
      - publish_asset_groups
      - read_library_content
      - manage_library_content
    dynamic_client_registration:
      supported: true
      spec: RFC 7591
      endpoint: https://mcp.mutinyhq.com/oauth/register
      note: >-
        Anonymous client registration is what lets Claude web/Desktop/Code register themselves as
        connectors without a human copying a client_id out of a developer portal.
    discovery:
      authorization_server_metadata: https://mcp.mutinyhq.com/.well-known/oauth-authorization-server
      protected_resource_metadata: https://mcp.mutinyhq.com/.well-known/oauth-protected-resource
      specs:
      - RFC 8414
      - RFC 9728
      - RFC 7636 (PKCE)
      - RFC 7591 (DCR)
    refresh:
      supported: false
      note: >-
        grant_types_supported declares authorization_code only; no refresh_token grant is advertised in
        the metadata, so a client must re-run the authorization flow when the access token expires.
  unauthenticated_behaviour:
    endpoint: https://mcp.mutinyhq.com/mcp
    method: POST
    http_status: 401
    body: '{"jsonrpc":"2.0","error":{"code":-32001,"message":"Authentication failed."},"id":null}'
    checked: '2026-08-13'
    gap: >-
      The 401 carries no WWW-Authenticate header pointing at the protected-resource metadata. RFC 9728
      and the MCP authorization spec expect that challenge so a client can discover the authorization
      server automatically from a failed call; here a client must already know to fetch
      /.well-known/oauth-protected-resource.
- api: Mutiny application (app.mutinyhq.com)
  base_url: https://app.mutinyhq.com
  security_schemes:
  - id: session
    type: session
    note: >-
      Interactive browser session only. Every path probed on app.mutinyhq.com — including
      /.well-known/* and /openapi.json — returns 401. Enterprise plans add SSO per the pricing page.
      No developer-facing credential is issued.
api_keys:
  supported: false
  note: Mutiny publishes no API key, secret key, or personal access token surface.
notes: >-
  Everything above is read from live, anonymous probes of Mutiny's own discovery documents on
  2026-08-13, plus the connection instructions in Mutiny's help centre. No securityScheme was derived
  from an OpenAPI document because Mutiny publishes none.