I Classified 8,000+ MCP Servers by Auth Appropriateness. Most Get It Wrong.
Last month Astrix Security published a study of 5,200 MCP servers and found 53% use static API keys. That number got a lot of attention. But it misses the real question.
A weather API with a static key is fine. A database server with a static key is not. “Does it have auth” is the wrong frame. “Does it have the right auth for what it does” is the question that matters for production deployments.
I built a pipeline to answer it.
The Auth Appropriateness Framework
Most security assessments treat auth as binary: present or absent. That’s useful for headlines but not for risk decisions. A server that reads public weather data doesn’t need the same auth as one that writes to your production database.
I classify servers on two dimensions:
Sensitivity tier — what can this server access or modify?
| Tier | Score | What it does | Examples |
|---|---|---|---|
| Critical | 5 | Write to production data, financial ops, infrastructure | Databases, cloud provisioning, payments, email send |
| High | 4 | Read private/business data | CRM, HR, private repos, customer records |
| Medium | 3 | Org-internal data | Project management, analytics, internal docs |
| Low | 2 | Public data access | Web search, weather, stock quotes |
| None | 1 | Local-only, no network sensitivity | Math, text formatting, local file tools |
Auth strength — what authentication does it actually implement?
| Method | Score | Detection method |
|---|---|---|
| None detected | 0 | No env vars, no headers, no auth mentions |
| Static API key | 1 | environmentVariables with isSecret, README mentions API_KEY |
| API key + documented rotation | 2 | README mentions rotation/expiry |
| OAuth client credentials | 3 | Registry shows OAuth, README mentions OAuth |
| OAuth user delegation | 4 | Describes user consent flow |
| OAuth 2.1 + PKCE | 5 | Explicit PKCE/2.1 documentation |
Gap score = sensitivity tier - auth strength (clamped to 0). A gap of 0 means auth is appropriate. A gap of 4 means a critical-sensitivity server with a static API key or nothing at all.
This is the framework I’m calling the Auth Appropriateness Score. It’s not about whether a server has auth — it’s about whether the auth is proportional to the risk.
Data sources and methodology
I pulled data from four sources:
| Source | Servers | What it contributes |
|---|---|---|
| Official MCP Registry | 12,486 entries (4,205 unique after version dedup) | Auth headers, env vars with isSecret/isRequired flags, transport types, source URLs |
| ToolSDK MCP Registry | 4,548 servers | Tool definitions (8,010 tools), categories, env var specs |
| Awesome MCP Servers | 537 entries | GitHub URLs, community categorization |
| PulseMCP | unavailable | API returned 404 at time of collection |
After deduplication by normalized name and GitHub URL: 8,216 unique servers.
For each server, I:
- Merged metadata across sources (official registry auth data is authoritative)
- Fetched 6,833 GitHub READMEs and scanned for auth patterns, rate limit mentions, and audit/logging mentions
- Classified sensitivity based on category, tool verb analysis (create/update/delete vs. read/list/get), and description keywords
- Assessed auth strength from registry metadata and README scanning
Important caveats:
- This is passive analysis. No live servers were probed. Auth detection relies on documented metadata and README content.
- Sensitivity classification uses heuristics. A server categorized as “database” gets tier 5; that’s usually right, but edge cases exist.
- Some servers may have auth mechanisms not documented in their README or registry entry.
- The official registry includes versioned entries, so some servers appear multiple times. Dedup catches most but not all of these.
The findings
Auth strength distribution
| Auth Level | Count | % |
|---|---|---|
| None detected | 4,158 | 50.6% |
| Static API key | 3,405 | 41.4% |
| API key + rotation | 0 | 0.0% |
| OAuth client credentials | 588 | 7.2% |
| OAuth user delegation | 0 | 0.0% |
| OAuth 2.1 + PKCE | 65 | 0.8% |
Half the ecosystem has no detectable auth. Another 41% use static API keys. Combined: 92.0% rely on static credentials or nothing.
65 servers — less than 1% — implement OAuth with PKCE. Zero document key rotation.
These numbers are broadly consistent with Astrix’s findings (53% static keys), though our dataset is larger and our classification is more granular. The key difference: we don’t stop at “has auth.”
Sensitivity distribution
| Tier | Count | % |
|---|---|---|
| Critical | 1,459 | 17.8% |
| High | 379 | 4.6% |
| Medium | 1,657 | 20.2% |
| Low | 4,721 | 57.5% |
Most MCP servers access public data or perform low-risk operations. That’s expected — the ecosystem is dominated by search tools, web scrapers, and utility servers.
But 1,838 servers handle critical or high-sensitivity data. These are database connectors, cloud provisioning tools, payment processors, CRM integrations, email senders.
The gap
| Gap Level | Count | % | Meaning |
|---|---|---|---|
| Appropriate | 470 | 5.7% | Auth matches sensitivity |
| Minor | 1,901 | 23.1% | Slightly underprotected |
| Moderate | 3,355 | 40.8% | Notably underprotected |
| Severe | 1,054 | 12.8% | Significantly underprotected |
| Critical | 1,436 | 17.5% | Critically underprotected |
Only 5.7% of servers have auth appropriate to their sensitivity level.
30.3% — 2,490 servers — have severe or critical auth gaps. These are servers handling sensitive data with weak or no authentication.
The moderate category (40.8%) is the bulk. These are medium-sensitivity servers (project management, analytics, developer tools) with static API keys. That’s underprotected but not catastrophic. The severe and critical categories are where the real risk sits.
Worst categories
| Category | Servers | Avg Sensitivity | Avg Auth | Avg Gap |
|---|---|---|---|---|
| Databases | 348 | 5.0 | 0.51 | 4.48 |
| Cloud platforms | 213 | 5.0 | 0.71 | 4.27 |
| Finance/fintech | 470 | 5.0 | 0.76 | 4.21 |
| Communication | 346 | 5.0 | 1.03 | 3.97 |
| Version control | 104 | 4.0 | 0.78 | 3.22 |
| Code execution | 90 | 3.1 | 0.44 | 2.64 |
| Analytics | 89 | 4.1 | 0.74 | 3.35 |
| Customer data platforms | 56 | 4.4 | 1.16 | 3.25 |
Database servers are the worst offenders. Average sensitivity: 5.0 (max). Average auth strength: 0.51. That’s 348 servers that can write to production databases, and on average they’re barely protected by a static key. Many have no auth at all — the database connection string is the only gate.
Cloud platforms and fintech follow the same pattern. These categories are inherently critical — they provision infrastructure, handle payments, move money — and the auth is nowhere close to matching the risk.
Communication servers (email, Slack, SMS) are interesting: average auth is higher (1.03) because most require an API key for the messaging service. But that key authenticates the server, not the user. Every request goes through with the same credential regardless of who initiated it.
What the highest-gap servers look like
The servers with gap score 5 (critical sensitivity, zero auth) include:
- Kubernetes MCP servers — cluster management with no auth beyond kubectl context
- MongoDB/Postgres connectors — full database access gated only by the connection string
- Cloud provisioning tools — AWS, GCP, Azure management with no additional auth layer
- Email senders — servers that send email on behalf of the user with no identity verification
These are all stdio-transport servers, which means they run locally and inherit whatever credentials are in the user’s environment. That’s the security model: if you can run the binary, you get full access.
For local development, this is arguably fine. For production agent deployments where multiple users share an agent runtime, it’s a critical gap.
What “right auth” looks like
The framework suggests what auth should be, per tier:
| Sensitivity | Minimum appropriate auth | Why |
|---|---|---|
| Critical (5) | OAuth user delegation or higher | Write operations to sensitive systems need per-user identity |
| High (4) | OAuth client credentials + scoping | Business data access needs scoped, rotatable credentials |
| Medium (3) | API key with rotation | Internal data access needs credentials that expire |
| Low (2) | Static API key acceptable | Public data access — risk is low |
| None (1) | No auth needed | Local operations — no network exposure |
The ecosystem is approximately one full tier behind where it should be, across the board.
What this means in practice
The Astrix framing — “53% use static keys” — tells you what auth is. The Auth Appropriateness framework tells you what auth should be relative to the risk.
A static key for a weather API is a gap score of 0 — appropriate. A static key for a database connector is a gap score of 4 — critical. Both show up as “static API key” in a flat count. Only one is a problem.
This matters because MCP adoption is accelerating. Enterprises are connecting these servers to production systems. The question isn’t “does this server have auth” — it’s “is this server’s auth appropriate for the access it has.”
For 94.3% of the ecosystem, the answer is no.
The data
The collection pipeline, methodology, and classification logic are documented and reproducible. Collected 2026-03-26 from public registry APIs and GitHub READMEs. No live servers were probed.
What to do about it
If you’re evaluating MCP servers for production use, the Auth Appropriateness Score gives you a framework: classify the server’s sensitivity, check its auth, calculate the gap. If the gap is 2+, you need a compensating control.
That compensating control is an Agentic Control Plane — a layer between the agent runtime and your backend that enforces per-user identity, scoped authorization, and audit regardless of what the MCP server itself implements.
The server doesn’t need to implement OAuth if the control plane handles identity. The server doesn’t need rate limiting if the control plane enforces budgets. The server doesn’t need audit logging if the control plane records every tool call with user context.
This is the architecture pattern. The data just tells you how urgently you need it.
Read the reference architecture → · Get started free →