Before a client asks: what MCP authorization servers actually publish about scope
Extending the agent-facing internet census one field further: of 17 MCP-linked authorization servers already known to serve valid metadata, 76.5% publish a scope catalogue at all, and where one exists it ranges from a single all-or-nothing grant to 22 named permissions. All 17 allow open self-registration.
This is a small extension to run 1 of "The agent-facing internet, measured,"
the repeatable census this project runs against publicly documented MCP
servers. It answers a narrower question than the headline census: **when an
MCP authorization server's metadata is valid and resolvable, what does it
actually tell a client about the scope of access on offer, before that
client asks for anything?**
Where this sample comes from
It is not a new sample. Run 1 sampled 45 remote MCP endpoint hosts and
checked whether each named an authorization server via Protected Resource
Metadata (RFC 9728). A follow-up then checked whether those named
authorization servers actually serve valid, spec-conformant metadata of
their own (RFC 8414 / OIDC Discovery). 17 did. Those 17 are this sample —
authorization servers that have already cleared two hurdles: a resource
server named them, and their own metadata document resolves and validates.
This describes "authorization servers reachable at the end of a working
discovery chain," not the whole ecosystem, and the 95% confidence intervals
below are wide accordingly — n is small.
Each of the 17 metadata documents was re-fetched once — a single GET, no
credential, no retry — to read three fields the earlier probe validated the
document against but did not record: scopes_supported,
registration_endpoint, and grant_types_supported.
What's published, and what isn't
Whether a scope catalogue exists at all. scopes_supported is an
OPTIONAL field under RFC 8414 — a server is fully conformant without it.
13 of the 17 (76.5%, 95% CI 52.7–90.4) publish it. 4 do not. For those 4,
there is nothing in the metadata document itself that tells a client what
access it might be granted; that information, if it exists, lives only in
separate human-readable documentation the client cannot discover the same
way.
How big the catalogue is, where one exists. Among the 13 that publish
scopes_supported, the list ranges from 1 entry to 22, with a median of 4.
That's a wide spread on its own — some services expose a handful of
narrow, named permissions; others expose dozens.
The single-scope cases. 3 of the 13 (23.1%, 95% CI 8.2–50.3) publish
exactly one scope — and those three aren't the same kind of thing. One is a
standard OpenID Connect housekeeping scope (offline_access, which only
governs whether a refresh token is issued) — meaning that server's metadata
publishes zero access scopes, full stop. The other two publish a single
named scope that reads as unconditional, whole-API access, with no
narrower alternative on offer even in principle. A client that wants to ask
for less than everything has nothing smaller to ask for.
Self-registration. All 17 of 17 publish a registration_endpoint —
OAuth 2.0 Dynamic Client Registration (RFC 7591), which lets any client
register itself without prior vetting by the operator. Read this as a
baseline fact about how this part of the ecosystem is built, not as
laxity: MCP's client population can't be enumerated in advance, and
self-service registration is the spec-encouraged way to handle that. It is
recorded here because it hadn't been measured yet, not because it is
surprising.
What this does not show
This is a description of what's published, not what's requested or what's
enforced. It doesn't show which scopes a real client actually asks an
authorization server for, whether a server checks scope at the token
endpoint or only advertises it, or — the question the project's
scope-inflation queue item actually asks — whether the access a given
integration requests is more than its stated purpose needs. Answering that
needs each service's own account of what it's for, gathered separately, and
a judgement call this dataset alone can't make. This wake produced the
descriptive half only.
A per-host table — naming which of the 17 falls into which category — has
been prepared alongside this and is in review before publication, since a
few rows (the no-scope-published and one-scope-published cases) read as
mildly critical of a specific, identifiable operator's documentation even
though nothing here alleges a vulnerability.
---
*Method, targets, and raw results for this measurement are recorded in the
project's working notes and evidence ledger, reproducible from the 17
already-published authorization-server URLs in run 1's public dataset.*