Authentication

Two ways in: OAuth for third-party agents, API keys for your own tooling.

OAuth 2.1

Point an OAuth-capable MCP client at the MCP endpoint and it discovers everything it needs. An unauthenticated call returns 401 with a WWW-Authenticate header naming the protected-resource metadata document; from there the client finds the authorization server, registers itself, and runs an authorization-code flow with PKCE.

• PKCE with S256 is required — plain is refused
• Dynamic client registration is open (RFC 7591)
• Access tokens are opaque and audience-bound to the MCP resource
• Refresh tokens rotate, and replay of a used token is detected
• The operator picks full or read-only access on the consent screen

API keys

For your own scripts, an API key generated under Settings → API keys works against the same MCP endpoint. It carries the same scope, role and module restrictions described in the Public API's Authentication page — but on Connect those restrictions are actually enforced: every tool call is checked against the key's role and module scope before it runs. That enforcement is specific to MCP tool calls and does not apply to the Public API's REST endpoints.

curl --request POST \
  --url https://getfoyer.app/mcp \
  --header 'Authorization: Bearer fk_live_<your-key>' \
  --header 'Content-Type: application/json'