MCP OAuth: The Spec Says Optional, 57% Guard Anyway

No, the specification does not require OAuth. It says authorization is OPTIONAL for MCP implementations, and only then constrains what authorization has to look like if you add it [1]. We still found that 30 of 53 public endpoints refused an anonymous call between 20 July and 5 August 2026, which is the more interesting half: this ecosystem guards itself without being told to.

Below is the exact spec wording, the sentence we published wrongly and corrected, our numbers set against a 7,973 server measurement study, and the list of requirements that genuinely do bind the moment you turn OAuth on.

TL;DR:

• The spec settles it in its own Protocol Requirements section. "Authorization is OPTIONAL for MCP implementations" [1]. Guides calling OAuth 2.1 mandatory are reading conditional requirements as unconditional ones.
• We published the wrong version too, and corrected it on 18 August 2026. Our glossary told readers the spec "requires internet-facing servers to use OAuth 2.1". It doesn't.
• 30 of 53 endpoints refused us anonymously (57%). A separate study of 7,973 live remote servers found 40.55% expose tools with no authentication [2]. Different samples, three orders of magnitude apart, same direction.
• Two vendors shipped both at once. Cloudflare and X each ran one open documentation server and one guarded product server. The decision is about what sits behind the tools, not about the protocol.

Does the MCP specification require OAuth?

No. The 2025-11-25 authorization specification opens its Protocol Requirements section with one sentence that settles the question: "Authorization is OPTIONAL for MCP implementations" [1]. Everything after it is conditional. A server that never implements authorization is not violating the spec.

The three lines that follow scope it by transport, and they are worth reading in full because they are where the nuance lives [1]:

• Implementations using an HTTP-based transport SHOULD conform to this specification.
• Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment.
• Implementations using alternative transports MUST follow established security best practices for their protocol.

Note the verbs. HTTP gets a SHOULD, not a MUST. stdio gets an explicit SHOULD NOT, because a stdio server is a subprocess you launched on your own machine and the operating system already decided who may run it.

Where does "OAuth is mandatory" come from?

From reading the requirement list without its opening line. The document is dense with MUSTs: authorization servers MUST implement OAuth 2.1, MCP servers MUST implement Protected Resource Metadata, clients MUST implement PKCE. Every one of them sits under the heading "When supported". Detach them from that heading and the page reads like a mandate.

You can watch it happen in the material that ranks for this query. One 2026 developer guide states that "any MCP server accessible over the internet must implement OAuth 2.1 with PKCE (Proof Key for Code Exchange using the S256 method)", adds that there are no exceptions, and calls OAuth 2.1 "the authorization framework mandated by the Model Context Protocol specification for all remote HTTP-based servers" [3]. Another says "The Model Context Protocol spec mandates OAuth 2.1 as the standard" [4].

The engineering advice underneath that is fine. An unauthenticated server holding real data is a bad idea, and the second source makes exactly that argument. The sourcing is what is wrong: it is good advice wearing the spec's authority, and the spec did not say it. Some references get this right, and it is worth knowing they exist. Speakeasy's page states plainly that "Authorization is optional in the specification, but when an HTTP-based MCP server supports it, the June 2025 revision defines a clear model" [5].

What did we get wrong?

The same thing, on a page whose whole job is to be accurate. From 6 August 2026 until 18 August 2026 our own MCP authorization glossary entry told readers "The specification requires internet-facing servers to use OAuth 2.1." That sentence sat in the entry's definition block, which is the one written specifically to be quoted by an answer engine.

Two things made it worse than a typo. Our internal decision record made the claim first, in July, when we built support for checking auth-guarded servers, and the glossary inherited it without going back to the source. Our own content notes had also flagged the error on 5 August, one day before the glossary shipped, with the instruction to reword it and not restate it in any published copy. Nobody executed that. The page was written the next day and restated it four times.

We corrected all four on 18 August 2026. We are leading with it because a post arguing that other people misread a spec has no standing if it hides that we misread the same spec, on a live page, for twelve days.

How many MCP servers actually require authentication?

More than half of the ones we could reach. We called 53 public endpoints between 20 July and 5 August 2026 and recorded what came back. Thirty refused with a 401 or 403, fourteen answered a tools/list request in full, and the remaining nine were broken, misaddressed, or gone.

The refusals are not obscure projects. They include mcp.linear.app/mcp, api.githubcopilot.com/mcp/, mcp.notion.com/mcp, mcp.stripe.com, mcp.slack.com/mcp, mcp.sentry.dev/mcp, mcp.figma.com/mcp, mcp.atlassian.com/v1/mcp, mcp.vercel.com and mcp.supabase.com/mcp, each checked on 4 or 5 August 2026. If you are building a client, the servers you most want to reach are the ones most likely to want a token first.

Two vendors are the clearest illustration, because they shipped both answers at once. mcp.cloudflare.com/mcp refused us; docs.mcp.cloudflare.com/mcp connected and returned 2 tools. api.x.com/mcp refused us; docs.x.com/mcp connected and returned 3. Same companies, same protocol, opposite decisions, and the thing that differs is what the tools reach. Documentation search is public already. Your Cloudflare account is not.

A larger measurement backs the direction. A May 2026 study identified 7,973 live remote MCP servers and found that 40.55% "expose tools without authentication" [2]. Set against the 44 endpoints in our sample that answered as MCP servers at all, 14 exposed tools anonymously, or 32%. Two samples three orders of magnitude apart, gathered by different methods, landing within single digits of each other. Their number is the one to quote for the ecosystem. Ours is the one we can show the working for, endpoint by endpoint, on our corpus page.

Why do published figures disagree so much?

Because "MCP server" and "no authentication" both name more than one population, and most figures skip saying which. You will see 8.5%, 25%, 40.55% and our 57% quoted in the same conversation as though they contradict each other. Mostly they do not. They are counting different things.

Three questions decide the number before any measuring happens:

• Remote or everything? Registries are dominated by local stdio servers, which the spec explicitly tells you not to put OAuth on. Include them and the OAuth share collapses, correctly and uninterestingly.
• No auth, or refused you? "Exposes tools without authentication" and "declined our anonymous request" are different observations. A server using a static API key is authenticated and would still refuse us.
• Endpoints or checks? Our own corpus reads 30 of 53 endpoints or 40 of 82 checks, because several addresses were tested more than once. Both are true. A figure that does not name its denominator is two facts wearing one number.

Ours, stated plainly: 53 public Streamable HTTP endpoints we could find and call, counted once each by their most recent check, between 20 July and 5 August 2026. We tested once and never re-tested, so every figure here describes those dates and makes no claim about what any server is doing now.

What does the spec actually require once you add OAuth?

Quite a lot, and this is the half worth your attention. The moment a server is protected, the conditional requirements become real ones, and they are mostly about discovery and audience rather than about login [1].

The practical version for a server author is short. Return a 401 carrying resource_metadata. Publish the metadata document. Reject every token that was not minted for you. You are a resource server, not an authorization server, and the spec is explicit that the authorization server's own implementation is outside its scope.

That second-to-last row is where the real risk lives, and it is not hypothetical: the same 7,973 server study reports that every one of the 119 OAuth-enabled servers it could test exhibited at least one flaw [2]. We have not audited anyone's implementation and we do not publish a rating that implies we have. We point at their finding because it is a better thing to worry about than whether the word "mandatory" applies.

If you are shipping a remote MCP server

Decide on the data, not on the spec. If your tools reach a user's account, a paid API, or anything private, put OAuth in front of them and follow the discovery requirements above so clients can actually complete the flow. If your server searches your public docs, leaving it open is a legitimate choice that Cloudflare and X both made deliberately, alongside the opposite one.

Whichever you pick, check what your server returns before anyone else does. A 401 with no WWW-Authenticate header leaves a conforming client nothing to parse, and that is the most common way a correctly guarded server still fails to connect. You can see exactly what an anonymous caller gets from your endpoint with our connection tester, which takes an optional token if you want to check the authenticated path in the same run. If the outcome surprises you, the failure taxonomy covers what each response actually means, and auth_required covers why a refusal is the healthy answer rather than a broken one.

When it is returning what you expect, put it in a week. A listing carries what your server returned on the date we asked it and nothing we did not measure, which includes saying plainly when a server declined us. Guarded servers are welcome and always have been: 30 of the 53 endpoints above are the tier we would most like on the board. If you want to see what that receipt looks like first, the 14 servers that answered us are published with their tool counts and the rubric behind them.

Sources

1. Model Context Protocol specification 2025-11-25, Authorization
2. A First Measurement Study on Authentication Security in Real-World Remote MCP Servers, arXiv:2605.22333 (May 2026)
3. MCP OAuth 2.1 Authentication: Complete Developer Guide 2026
4. Prefect, MCP OAuth: How OAuth 2.1 Works in the Model Context Protocol
5. Speakeasy, What is MCP authorization?