Every MCP server needs to answer one question before it does anything useful: who is asking?

Some servers skip that question entirely. Others require an API key, redirect through OAuth, or charge per request using x402. The auth method shapes how you connect, what data you can touch, and how much setup stands between you and a working agent.

If you have wired up more than a couple of MCP servers, you have probably hit all four. Here is what each one actually looks like in practice.

The Four Auth Models

MCP does not enforce a single authentication standard. Instead, each server declares its own auth requirements. When your agent connects, it needs to satisfy whatever the server asks for. In practice, that falls into four categories.

None (Open Access)

Some MCP servers require no authentication at all. These are typically local-only servers that run on your machine and access resources you already control: file systems, local databases, clipboard, or system utilities. They trust the connection because it comes from localhost.

Open-access servers are the fastest to set up. No tokens, no configuration, no third-party accounts. You point your agent at the server, and it works. Most developers start here without even thinking about it — if you have used a local file system MCP server, you have used open-access auth.

The tradeoff is obvious: the moment you need audit trails or user-level data, open access is not enough.

API Key

API key auth is the most common pattern for hosted MCP servers. The server operator issues a static key, and your agent includes it with every request. The server checks the key, maps it to permissions, and either allows or rejects the call.

In practice, this usually means adding the key to your MCP client configuration. Claude Desktop, for example, accepts API keys in its claude_desktop_config.json file. Most agent frameworks handle this through environment variables or config objects.

{
  "mcpServers": {
    "example-server": {
      "command": "npx",
      "args": ["example-mcp-server"],
      "env": {
        "API_KEY": "your-key-here"
      }
    }
  }
}

API keys are simple but carry tradeoffs. They do not expire unless you rotate them. They grant the same level of access every time. And if a key leaks, anyone who has it can make requests as your agent until you revoke it.

For single-developer setups and SaaS integrations, this is usually fine. Where it breaks down is multi-user apps — when different people need different permissions, a single static key cannot express that.

OAuth 2.0

OAuth shows up when an MCP server needs to act on behalf of a specific user. Instead of a static key that represents one developer account, OAuth generates scoped tokens tied to individual users and their permissions.

The flow works like any other OAuth integration. Your agent redirects the user to an authorization page, the user grants access, and the server issues an access token (often with a refresh token). The agent stores that token and presents it on each request.

This is the pattern behind MCP servers that connect to Google Workspace, Slack, GitHub, or any other platform with per-user data. The server itself does not store the user’s credentials. It holds a token that says “this user granted read access to their calendar.”

OAuth adds real setup complexity. You need a registered OAuth application, callback URLs, token storage, and refresh logic. It is more work than most developers want for a side project. But for multi-user or multi-tenant scenarios, it is the only auth model that properly separates user permissions. If you are building anything that touches someone else’s data, this is where you end up.

x402 (Pay-Per-Request)

x402 is the newest auth model in the MCP space. Instead of verifying identity, it verifies payment. Your agent includes a payment header with each request, and the server checks that the payment clears before processing the call.

The protocol builds on HTTP status code 402 (Payment Required). When your agent hits an x402-gated server without payment, it gets back a 402 response with pricing details: how much the request costs, which payment methods are accepted, and where to send funds. The agent’s x402-compatible wallet handles payment automatically, and the request goes through.

This model works well for metered services where usage-based pricing makes more sense than subscriptions. A server that runs expensive inference, queries a premium dataset, or performs heavy computation can charge per call without requiring account creation or API key management.

x402 is still early. Not many MCP servers use it yet. But for anyone building a paid tool and dreading the Stripe integration, it is worth watching.

How to Tell What Auth a Server Uses

Most MCP server listings include the auth type in their metadata. On AgentNDX, you can filter servers by auth method to find ones that match your setup requirements.

If the listing does not specify, check the server’s documentation or README. Servers that need auth will typically fail fast with a clear error message telling you what is missing. A 401 means you need credentials. A 402 means you need payment. A successful connection with no credentials means the server is open.

Mixing Auth Models in Agent Workflows

Real agent workflows rarely use a single MCP server. Your agent might query an open-access file system server, pull data from an API-key-gated analytics server, and post results to an OAuth-connected Slack server, all in one task.

Each server handles its own auth independently. Your MCP client configuration holds the credentials for each connection. The agent does not need to understand the auth differences. It presents the right credentials, and the server either accepts or rejects.

This is one of the better parts of MCP’s design. Auth is per-server, not per-protocol. You do not need a single auth system that covers every possible server. Each server picks what works for its use case, and the client adapts. In practice, this means your config file does most of the heavy lifting — set up the credentials once and the agent handles the rest.

Picking the Right Auth for Your Server

If you are building an MCP server, the auth choice depends on three things:

  1. Who are your users? Single developer = API key. Multiple users with different permissions = OAuth. Anonymous paying customers = x402.
  2. What data do you expose? Public or local data = none. User-specific third-party data = OAuth. Premium data = x402 or API key.
  3. How do you want to monetize? Free tool = none or API key. Subscription = API key with rate limits. Usage-based = x402.

There is no wrong answer as long as the auth model matches the trust model. A file system server that requires OAuth is overengineered. A server that exposes user email without OAuth is underprotected. When in doubt, start with API key auth and add complexity only when you actually need it.

FAQ

Q: Can an MCP server support multiple auth methods? A: Yes. Some servers accept both API keys and OAuth, letting developers choose based on their setup. A server could also offer a free tier (API key) and a premium tier (x402) for the same endpoints.

Q: How do I store MCP credentials securely? A: Use environment variables or your platform’s secret manager. Never hardcode API keys in configuration files that get committed to git. For OAuth tokens, use encrypted storage and handle refresh tokens properly.

Q: Does MCP itself handle auth, or is it up to each server? A: MCP defines the transport layer but leaves auth to individual servers. The protocol does not mandate a specific auth standard. Each server declares its own requirements, and the client satisfies them.