Use the hosted Firecrawl MCP service in one of three modes. Choose based on whether a person can sign in and whether the client can securely store an API key.
Connect an account
Use this mode for an interactive, OAuth-capable client such as Claude or Codex. Add this URL to the client; it discovers Firecrawl’s authorization metadata, opens the browser, and asks you to approve the team it should use.
The client receives short-lived, resource-bound tokens rather than your Firecrawl API key. You can review and revoke access from MCP settings.
If the client asks for an OAuth Client ID or Client Secret, leave both blank. Compatible clients use Client ID Metadata Documents or Dynamic Client Registration.
Run unattended
Use this mode for CI, servers, scripts, or any runtime without a browser. Keep the API key in an environment variable or secret store and send it as an Authorization header.
This uses the full Firecrawl MCP tool surface. New configurations should not put an API key in the URL or commit it to a project configuration file.
Try keyless
Use this mode to try Firecrawl without an account or API key:
Keyless MCP is rate-limited per IP and exposes exactly Search, Scrape, and Parse while eligible. Connect an account or use an API key when you need the complete tool surface or higher limits.
Pick the right mode
Client-specific help
See client setup for configuration examples. If your client cannot complete a remote OAuth flow, use the unattended header-based configuration or keyless mode instead. If it cannot send custom headers either, see the legacy fallback below.
Legacy API-key URL support
This legacy form exists only for existing configurations and clients that cannot complete OAuth or send a custom Authorization header. It is not the recommended setup for new integrations.
Authorization: Bearer header whenever the client supports either. If this URL is exposed, rotate the API key. Never paste it into chat, screenshots, issues, or shared configuration.
This fallback applies only to the full /v2/mcp surface. It does not work for the OAuth-only search resource.
Compatibility during migration
Existing /v2/mcp OAuth connections remain supported during the migration to the dedicated account endpoint. New interactive account connections should use /v2/mcp-oauth; new tokens for that account resource are not accepted by /v2/mcp. 
