Many MCP servers on the internet expect a fixed API key with every request, for example as Authorization: Bearer … or in a custom header such as X-API-Key. Self-built servers, automations and many plugins work this way. Claude's connectors, on the other hand, are built around OAuth: you add an address, sign in, done. If you want to bring the two together, there are four options today. This guide shows which one fits when.
Check first: does your server already support OAuth?
Before you change anything, look at the server's settings. Some vendors now offer OAuth next to the key:
- The n8n MCP Server Trigger supports the authentication modes none, Bearer, Header and n8n OAuth2, according to its documentation.
- The WordPress plugin Royal MCP offers an API key in the
X-Royal-MCP-API-Keyheader or OAuth 2.1, according to its directory listings.
If your server offers OAuth, use it: everyone signs in individually, and you need none of the options below.
Option 1: request headers directly in Claude
Since late August 2026, Claude can send fixed headers for custom connectors. According to the Claude documentation, this feature is still in beta and only available to some organisations. Here is how:
- In Claude, open Customize → Connectors → Add custom connector.
- Enter the server address, for example
https://mcp.example.com/mcp. - Choose No sign-in for authentication and add the header under Request headers.
- Enter the complete value – for bearer tokens that is
Bearerincluding the space, followed by the key.
Good to know:
- If you don't see the Request headers section, it is not enabled for your organisation yet.
- Up to four headers are allowed. Common names such as
authorizationandx-api-keyare on the list; other names must be approved by Anthropic first. - The key is shared by everyone who uses the connector. The documentation therefore recommends headers for shared credentials, and OAuth when each person should sign in with their own account.
- Credentials can't be changed later: for a new key, remove the connector and add it again.
Option 2: Claude Code, Cursor or VS Code
Developer tools have supported headers for a long time. For Claude Code, one command is enough:
claude mcp add --transport http my-server https://mcp.example.com/mcp --header "Authorization: Bearer YOUR_KEY"
In Cursor, add the server to ~/.cursor/mcp.json:
{
"mcpServers": {
"my-server": {
"url": "https://mcp.example.com/mcp",
"headers": { "Authorization": "Bearer YOUR_KEY" }
}
}
}
In Visual Studio Code, the configuration goes into .vscode/mcp.json. To keep the key out of the file, VS Code can ask for it on start:
{
"inputs": [
{ "type": "promptString", "id": "api-key", "description": "API key", "password": true }
],
"servers": {
"my-server": {
"type": "http",
"url": "https://mcp.example.com/mcp",
"headers": { "Authorization": "Bearer ${input:api-key}" }
}
}
}
The catch: this only helps on your own computer. In the browser, in the Claude app on your phone and for colleagues without these tools, the server stays out of reach. And the key sits on every laptop where it is set up.
Option 3: put your own OAuth layer in front
You can place your own service in front of the server that speaks OAuth to Claude and adds the key towards the server. It is doable, but more work than it looks:
- Publish protected resource metadata (RFC 9728) and authorization server metadata (RFC 8414).
- Build sign-in, a consent page, PKCE, client registration (dynamic or via Client ID Metadata Documents) and refresh tokens.
- Bind tokens to exactly this server and make them revocable.
- Store the API key encrypted and keep it out of logs.
- Run, secure and maintain the service, and keep up with a specification that changes regularly.
For a development team with its own infrastructure this is a manageable project. For a single server that should simply work in Claude, it rarely pays off.
Option 4: the XenMCP OAuth bridge (in preparation)
XenMCP plans to offer exactly this layer as a service. At the start of the closed beta, you will enter your server's address and key and get an address such as https://your-name.xenmcp.com/mcp, which you add to Claude as a normal OAuth connector. The plan:
- The key is stored encrypted (AES-256-GCM) and never shown again.
- Each person on your team signs in individually; you can revoke one person's access without changing the key.
- A log shows who called which tool and when – metadata only, no content.
- Operated in Germany, with a fixed outbound IP address for your firewall.
How the bridge works is described on the page OAuth bridge for API-key servers; details on data protection are on the security page. What Claude itself does with the server's responses happens at Anthropic; a bridge does not change that.
Which option fits?
- Your server supports OAuth: use OAuth directly.
- You work alone or with a shared service account and see Request headers in Claude: option 1.
- You only use the server in developer tools: option 2.
- Several people should sign in individually, access should be revocable and calls traceable, and you don't want to run your own service: build option 3 yourself or wait for option 4.
How to set up a connector in Claude on all your devices is shown in the guide Connect an MCP server to Claude.
FAQ
Why doesn't my bearer token work in Claude?
First check whether the Request headers section appears in your connector dialog – it is not enabled for every organisation yet. If it does: Claude sends the value exactly as you enter it. Without the word Bearer in front of the key, most servers reject the request.
Is a shared API key a security problem?
Not necessarily, but it has limits: all users work with the same rights, and when someone leaves the team you have to rotate the key. So give the key only the rights that are really needed.
Does a connector added on the web also work in the Claude mobile app?
Connectors you add to your Claude account belong to the account. Local configurations in Claude Code, Cursor or VS Code, on the other hand, only work on that computer.
When will the XenMCP OAuth bridge be available?
It is planned for the start of the closed beta. Join the waitlist and tell us which server you want to connect.