MCP OAuth vs API Keys: Why DCR Wins for Agents

Most MCP servers authenticate with an API key in a config file. It works, it takes an afternoon to build, and it is the wrong design for a credential an AI agent uses on your behalf. The MCP specification says as much: OAuth 2.1 is the designated authorization framework for remote servers, with metadata discovery and Dynamic Client Registration as the expected path.

Almost nobody does it. Across the e-signature category, one server implements DCR. Here is what the difference actually buys, and what it costs to build.

What the user does

The gap shows up most clearly in setup steps.

With an API key, you open the vendor's dashboard, generate a key, copy it, find your MCP client's config file, paste the key into a JSON header block, and restart the client. If the server is a local npm or Python package, add an install step.

With OAuth and DCR, you paste a URL and click Allow.

{
  "mcpServers": {
    "signvoy": {
      "url": "https://api.signvoy.com/mcp",
      "transport": "streamable-http"
    }
  }
}

No credential appears in that file, because there isn't one. The client registers itself and stores a token it manages.

The step count matters more than it looks like it should. The person connecting an MCP server is usually mid-task in a chat window, testing whether something is possible. Every credential you ask them to create is a place they abandon the attempt.

What OAuth without DCR still costs

It is worth separating OAuth from DCR, because you can have the first without the second and most of the friction survives.

Docusign's MCP server uses OAuth. It supports only the confidential Authorization Code Grant, which requires a pre-registered client holding a secret. So before the connector works, the user creates an Integration Key, generates a Client Secret, and pastes both of Claude's callback URLs — https://claude.ai/api/mcp/auth_callback and https://claude.com/api/mcp/auth_callback — into the app's Redirect URIs field.

That is OAuth done correctly and still five manual steps, because the client could not register itself. DCR is the piece that collapses them.

Why static keys are worse than they feel

Three properties, each of which is fine in isolation and bad in combination.

They live in plaintext on disk. An MCP config file is a place people paste things and forget. .cursor/mcp.json sits inside a repository. Config files end up in screenshots when someone asks for help, and in commits when someone runs git add -A. This is not a hypothetical failure mode; it is the most common way keys leak.

They over-scope. Most e-signature API keys carry the permissions of the account that created them. If you belong to three workspaces, the key reaches all three. An agent asked to check a status in one workspace holds the authority to void a document in another.

They do not expire. A leaked key is valid until a human notices and rotates it, and rotation breaks every other integration using the same key — which is why people delay it.

An OAuth access token inverts all three. It is held by the client rather than written to a file you edit, it is scoped to the workspace you consented to, and it expires on its own. Signvoy's grants are bound to a single workspace, and revoking one grant leaves your API keys and other clients untouched.

How the discovery chain works

The part that makes zero-configuration setup possible is metadata discovery. The client hardcodes only the MCP endpoint; everything else it learns.

An unauthenticated request gets a 401 with a pointer:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://api.signvoy.com/.well-known/oauth-protected-resource/mcp"

That document names the authorization server. The authorization server's own metadata document at /.well-known/oauth-authorization-server advertises its registration, authorization and token endpoints. The client then registers itself per RFC 7591, receives a client_id, and runs a standard Authorization Code flow with PKCE — public client, no secret, its own redirect URI.

The user sees one browser consent screen. The client hardcoded one URL. Everything in between was discovered.

The objections, taken seriously

"DCR lets anyone register a client." True, and it is the point. Registration produces a client identity, not authorization. Nothing happens until a human completes a consent screen while authenticated. An unconsented registration is an entry in a table.

"Token refresh is a new failure mode." Also true. Access tokens expire and a client that mishandles refresh breaks in a way an immortal API key would not. In practice, MCP clients handle this well because the spec pushes them to, and the failure is recoverable — the server returns a 401 with the WWW-Authenticate pointer and a compliant client re-runs the flow without asking the user for anything. Signvoy returns JSON-RPC -32001 for this case, documented in the troubleshooting guide.

"OAuth is more work to build." The strongest objection, and it is straightforwardly correct. You need metadata endpoints, a registration endpoint, token issuance, PKCE support and consent UI. Signvoy delegates to Clerk, which already implements DCR — which is what made the build tractable rather than a quarter of work. If your identity provider does not support DCR, the honest calculation is different.

But note who pays. The API-key design moves the cost from you to every user, every time they connect a client. You pay once.

Where API keys are still right

This is not an argument that keys are obsolete.

Local stdio servers launched as a subprocess inherit the credentials of the process that started them. There is no browser, no redirect, and the MCP spec exempts them for exactly this reason. BoldSign, SignWell and SignNow all ship local servers, so their key-based auth is a defensible consequence of that choice rather than a shortcut.

Server-to-server automation — cron jobs, CI, backend services — has no user to consent. A scoped API key is the correct primitive. Signvoy's REST API uses sk_live_… keys, workspace-scoped and SHA-256 hashed at rest, and that is not going to change.

The dividing line is whether a human is present at connect time. When one is, ask them for a click. When one isn't, ask the machine for a key.

That same question decides which surface you should be building on in the first place, not just how it authenticates — MCP or REST API works through the trade.

What this looks like in the category

Six e-signature vendors ship MCP servers. Five use static API keys or, in Docusign's case, OAuth with manual client registration. One implements DCR. That is not a moral ranking — hosting a remote server is a prerequisite for OAuth, and three of those vendors chose local servers deliberately.

But it does mean the setup experience varies by an order of magnitude across a category where the products are otherwise similar, and the full comparison puts the numbers side by side.

Try it

Paste https://api.signvoy.com/mcp into Claude or Cursor and count the credentials you create.