Findings · 2026-10-09 · By VSNARY | Emmanuel Orta · 0 views
MCP servers that ask for a login: what 1,366 request first
We read the login requirements of every MCP server in the official registry that asks for one, without signing in. 44% had at least one finding: most often a default request for every scope the server offers, or no metadata telling a client what to ask for.
On 9 October 2026 CrawlCheck read, without signing in, the login requirements of 1,366 MCP servers from the official MCP Registry that ask for authorisation; 1,360 still asked when read. 597 (44%) had at least one finding. The most common: 244 make a client request every listed scope, including write or admin ones, although read-only scopes exist; 152 publish no protected-resource metadata, so a client cannot discover what to ask for; 133 issue tokens valid for more than the server itself; 97 ask for a refresh token by default; 39 request administrative or wildcard scopes.
An agent that connects to an MCP server on someone’s behalf usually has to log in, and the login decides what the agent can do afterwards. The person approving it sees a consent screen; the agent sees whatever the server asks for by default. We read what the servers in the official MCP Registry ask for, without ever signing in.
The registry lists 40,688 server entries, 25,686 with a remote endpoint. On our current pass we sent the MCP handshake to 3,854 of those endpoints: 1,775 answered with a tool list and 1,391 asked for authorisation first. For each server that asked, we read only what an unauthenticated client can read: the challenge it returns, its scopes, its protected-resource metadata and its authorisation server’s metadata. The figures below are from 10:05 AM Mountain Time on 9 October 2026.
| Finding | Servers | What it means for an agent |
|---|---|---|
| Requests every scope by default, including write or admin | 244 | The server names no scope in its challenge, so a client asks for everything listed, although read-only scopes exist |
| No protected-resource metadata | 152 | A client cannot discover which authorisation server or scopes apply |
| Token audience wider than the endpoint | 133 | A token for this server is also valid for the rest of the host |
| Refresh token requested by default | 97 | The agent receives a long-lived grant whether or not the task needs one |
| Administrative or wildcard scope requested | 39 | The default request includes rights to administer, not just use |
| Token audience on another host | 14 | The metadata names a different host as the resource; a strict client must refuse it |
| Authorisation server metadata missing | 11 | The login cannot be discovered as the specification describes |
| PKCE S256 not advertised | 2 | The protection against intercepted login codes is not offered |
A server can have several findings, so the rows add up to more than 597. By severity: 55 servers had a high finding, 389 medium, 153 low; 763 had none.
Asking for everything is the default #
The MCP authorisation specification builds on OAuth: a server that wants a login answers 401 with a challenge, and publishes protected-resource metadata (RFC 9728) saying where to log in and which scopes exist. A careful server names the scope a client should request in the challenge itself. Most do not. Of the 1,360 servers we could read, 283 name a scope in the challenge, 648 leave the client to take the full list from the metadata, and 429 give the client nothing to go on.
When a client takes the full list, it requests everything, and a person clicking through a consent screen rarely reads it. In 244 cases that list includes write or admin scopes although the same server offers read-only ones. Nothing points a client at the smaller set. An agent asked to “look up my last invoice” ends up holding the right to change it.
Tokens that reach further than the server #
In 133 cases the token’s audience is the whole host or a broader path than the MCP endpoint, so a token issued for the MCP server also works on the rest of that service. In 14 the metadata names a different host entirely. RFC 9728 requires a client to check that the resource in the metadata matches the server it connected to; a client that does so must refuse those 14. A client that does not will send its token wherever the metadata points.
Long-lived by default #
97 servers have clients request offline_access by default, which returns a refresh token: a grant that outlives the conversation. For an agent doing a one-off task that is more access, for longer, than the task needs. We cannot see token lifetimes without a token, so this counts what is requested, not what is issued.
A correction to our own scan #
Our first pass at tool shadowing across the same registry flagged 11 servers as copying another publisher’s tools. When we read the homepages behind each pair, none held up as copies: one operator running the same server in several languages, sister brands under one parent company, and a network of microsites generated from one template. Those pairs were public for a few hours before we withdrew them, and while they were up they lowered the connect decision agents received for those domains. Two rules now apply before anything is published: both homepages are read and must show no shared operator, and a tool description published word for word by three or more publishers counts as a template, not as a copy. Pairs we cannot read are held back.
What to do with this #
- Server owners: name the minimum scope in your
WWW-Authenticatechallenge, publish protected-resource metadata whose resource is exactly your endpoint, advertise PKCE S256, and leaveoffline_accessout of the default. - Agent builders: request the narrowest scope that does the task, check the resource in the metadata against the endpoint you connected to, and refuse a mismatch. Our guide on checking an MCP server before connecting covers the tool list itself.
- Anyone: check a server’s login without signing in:
curl -s "https://crawlcheck.io/api/v1/mcp/auth?url=<MCP endpoint>"(documented in the API reference).
Method #
Servers are imported from the official MCP Registry and re-imported weekly. Each remote endpoint receives the MCP handshake (initialize, then tools/list; no tool is ever called). Servers that answer with an authorisation challenge are read without signing in: the challenge, the protected-resource metadata, the authorisation server metadata and the scope list. Token lifetimes and what a server does with a token are not observable this way and are not counted. Individual servers are not named here; the live census and a lookup by host are at /api/mcp/index. Earlier figures on what registry servers answer: the registry census.
Every figure above came out of CrawlCheck.
Point it at your own domain and see the same measurements, free.
The main product
Found this on your own site? We fix it for $749.
Scan free to see where you stand. The fix is one site, every finding implemented and re-measured, with a sealed before and after.
Questions this post answers
What scopes do MCP servers request when an agent logs in?
Often all of them. Of 1,360 login-gated servers read on 9 October 2026, only 283 named a scope in their challenge; 648 left the client to request the full listed set and 429 gave no guidance. 244 of those defaults included write or admin scopes where read-only ones existed.
What is protected-resource metadata in MCP?
A JSON document defined by RFC 9728 that an MCP server publishes to say which authorisation server issues its tokens and which scopes exist. 152 login-gated servers in the registry publish none, so a client cannot discover how to log in correctly.
Why does token audience matter for AI agents?
The audience says where a token is valid. If it is wider than the MCP endpoint, a token issued to an agent for one tool also works across the rest of the service. Clients should check that the metadata’s resource matches the endpoint and refuse a mismatch.
Is requesting offline_access by default a security problem?
It gives the agent a refresh token, a grant that outlasts the task. 97 registry servers request it by default. It is not a flaw on its own, but it is more access for longer than a one-off agent task needs.
How did CrawlCheck read MCP login settings without signing in?
By reading only what any client can read before logging in: the server’s 401 challenge, its protected-resource metadata, the authorisation server metadata and the listed scopes. No account was created and no tool was called.
Which MCP servers had findings?
We do not name individual servers in this post. Anyone can check a specific server’s login requirements, without signing in, through CrawlCheck’s MCP auth check.
Related findings
Comments
Comments are read before they appear. Nothing is published automatically, and no account is needed.
Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.