Skip to main content
mcp-agent cloud supports multiple authentication modes so you can choose the right balance between security and accessibility. This page introduces the architecture and flows; the detailed configuration lives in the sub-pages.

​
Components

Agents exposed as MCP servers, sitting between MCP clients and downstream MCP servers

​
Modes at a glance

​
Current flow (Bearer tokens)

  1. Developer or user runs mcp-agent login.
  2. Browser-based auth returns an API key (lm_mcp_api_*), stored locally.
  3. CLI and MCP clients use the key in the Authorization: Bearer header.
  4. Deployment validates the token before executing tools/workflows.

​
Upcoming OAuth architecture

The forthcoming OAuth implementation follows the MCP Authorization specification:
  • /.well-known/oauth-authorization-server metadata endpoint (RFC 8414).
  • Authorization endpoint (/oauth2/authorize) supporting Google, GitHub, and custom IdPs.
  • Token endpoint (/oauth2/token) returning access + refresh tokens.
  • Resource server metadata (/.well-known/oauth-protected-resource) for deployments advertising supported methods (bearer_methods_supported, scopes).
  • Token introspection and JWKS endpoints for JWT validation.
We aim to make the default configuration zero-touch for mcp-agent cloud deployments while still allowing you to point at other OAuth providers if you self-host.

​
Choosing an authentication mode

  • Internal tools or staging → keep bearer tokens (fastest path).
  • Publishing to ChatGPT Apps → deploy with --no-auth, optionally combine with rate limiting in code.
  • Customer-facing apps → use bearer tokens initially, migrate to OAuth when available to integrate with existing identity providers.
  • Agents calling other MCP servers → configure outbound auth in mcp_agent.config.yaml. This is independent of how end-users authenticate to your deployment.