MCP Auth and API Keys for Search Servers

The three patterns

With OAuth, the client finds the authorization server through protected resource metadata, opens a browser, and receives a token. The MCP specification requires clients to send a resource parameter, so the token is tied to the specific server. Claude, Claude Code and Cursor each run this flow for servers that support it.

A bearer key is a fixed API key sent in an Authorization header. Claude's connector screen accepts custom request headers for this. Tavily's docs also list a key placed in the URL, but a header keeps the key out of logs and links, so use it when the client allows.

Keyless access lets you try a server without an account. Exa's keyless search and fetch work within a rate limit and need a direct IPv4 connection. Firecrawl's keyless option carries daily usage caps. Keyless is useful for testing, but a team workflow usually needs a key.

Storing and rotating keys

Keep keys out of committed files. Claude Code's project .mcp.json is meant for sharing, so put the key in your environment or in a headersHelper command. Remote entries in Cursor cannot read an env file, so reference shell variables instead.

Create one key per tool or per team member. That way, revoking one key does not break every integration. Choose the narrowest scope the vendor offers, and rotate a key when a person leaves the team or when the key appears in a log.

Reading the errors

The MCP specification says a 401 means authorization is required or the token is invalid. A 403 means the token lacks the scope a tool needs. Exa returns a 429 error when keyless traffic exceeds its limit, and signing in or adding a key resolves it.

When a key stops working, check three things in order. First, confirm the key sits in the header or environment variable your client actually reads. Second, check that the key has not expired or been rotated. Third, confirm that the key's plan or scope includes the tool you called and that your rate limit has not been reached. Write these checks into your team runbook.

Checklist

• Pick OAuth, a bearer key or keyless access based on what your client supports.
• Store each key in an environment variable or secret manager, not in a committed file.
• Create one key per tool or per team member, with the narrowest scope offered.
• Send a test query and check the response for 401 or 403 errors.
• Rotate or revoke a key when someone leaves the team or the key leaks.

Questions & answers

Sources for this entry

• MCP specification: Authorization
• MCP security best practices
• Claude Code documentation: MCP
• Exa MCP server reference
• Firecrawl MCP server documentation

Vendor descriptions are attributed to the vendor. Prices change; confirm with each vendor.

Continue this reading path

• Setup
• Search MCP Server
• Resource directory

Cite this entry