Skip to content
MCPCompare

Guide

MCP authentication explained: OAuth 2.1, discovery metadata and scopes

A compliant remote MCP server answers an unauthenticated request with 401 and a WWW-Authenticate header naming its protected-resource metadata. That document names the authorization server and lists supported scopes; the authorization server's own metadata says whether dynamic client registration is available. You can read all of it without an account — and the scope list is what tells you whether read-only access can be granted at all.

The discovery chain#

An MCP client that receives a 401 reads the WWW-Authenticate header, follows resource_metadata to the protected-resource document, finds the authorization server, fetches that server's metadata, and begins an ordinary OAuth flow. Each hop is a plain HTTPS GET.

Two practical notes from running this at scale. The protected-resource document is located by inserting the well-known segment into the path, not by appending it — a detail that makes a compliant server look non-compliant if you get it wrong. And endpoint behaviour can depend on your request headers, so send the protocol version and accept both JSON and event-stream before concluding anything about a vendor.

Reading a scope list#

The scope list is the most decision-relevant thing a server publishes, and the variation across real servers is enormous.

Some publish granular, verb-separated scopes — separate read and write permissions per resource. An administrator can grant exactly what a use case needs.

Others publish a single opaque scope. There is no read-only option: approving the connection approves everything the server can do, and no amount of client configuration changes that.

Across the servers we profile that publish any scope list, 8 of 16 fall into the second category.

Dynamic client registration#

If the authorization server publishes a registration_endpoint, clients can register themselves and connect without an administrator pre-provisioning anything. If it does not, someone registers each client by hand.

Neither is wrong. But the second has a real operational cost that only shows up once more than a handful of people want to connect, so it is worth knowing before rollout rather than during it.

When there is no OAuth at all#

5 of the 33 servers we profile accepted an unauthenticated connection when we checked, returning their capabilities to anyone who asked.

For a public documentation search tool that is a reasonable design. For anything touching business data it is a question to resolve before connecting, because a server that requires no credential from you requires none from anyone else either.

Questions

Can I check a server's authentication myself?
Yes, and it needs no account. Send one unauthenticated request to the endpoint and read the status code and WWW-Authenticate header, then fetch the two well-known documents. Every server profile here shows the exact request we used so you can reproduce it.
Does OAuth support mean the server is secure?
No. It means authorization is delegated and revocable rather than resting on a shared static secret, which is a meaningful improvement. It says nothing about what the server does with data once authorized.

Related

Figures in this guide are computed from the catalog on and update when it does.

Put this into practice

Build a shortlist, apply these criteria, and export an evaluation with every source and date attached. No account needed.

Build a comparison and export itSee a sample report — no email