We graded 93 MCP servers for enterprise readiness. Here's what we found.
An aggregate analysis of security posture across the MCP ecosystem, covering 2416 tools from 44 vendor-maintained and 49 community-maintained servers.
Key Findings
Only 37 of 93 servers implement MCP OAuth
34 servers are stdio-only, meaning per-user authentication requires spawning a separate server process per user. Another 22 support HTTP/SSE transport with per-request credentials but not full OAuth. In total, per-user auth is achievable natively on 59 of 93 servers (63%). For the rest, a hosting platform must inject credentials at the transport layer or run an instance per user.
Tool descriptions are a prompt injection surface
36 of 93 servers (39%) include instructional language in tool descriptions, such as "always call this first" or "do not confirm with the user." LLMs read these descriptions as guidance, so anything written there becomes an instruction the model may follow. This is the most common high-severity finding in the ecosystem.
Most servers return everything by default
59 of 93 servers (63%) do not let callers select which fields to return, and 35 list operations across the ecosystem lack pagination. Both contribute to context bloat and over-exposure of sensitive fields when a tool is called for a narrow purpose.
Destructive operations are rarely isolated
43 of 93 servers (46%) expose admin-level tools, and 10 combine read and write operations inside a single tool. When read and write live together, a client cannot grant read-only access without disabling the tool entirely.
OAuth Adoption Over Time
Share of audited servers that support the MCP OAuth tier (authentication scored 23/25 or higher), by audit date. Hover a point for exact figures.
Counts reflect what each audit reflected at the time. The latest step reflects the changelog re-score plus a deliberate shift to scoring vendors' official hosted (remote) MCP servers with OAuth wherever they supersede an old self-hosted or community server. This covers newly verified/corrected OAuth (Supabase, Square, PostHog, QuickBooks, Railway, Kafka) and hosted conversions across two review passes (Vercel, Linear, HubSpot, Box, Datadog, New Relic, Axiom, Intercom, Apify, Salesforce, Asana, ServiceNow, Notion, Shopify, Snowflake, Zoom). Some OAuth support predates the audit (e.g. Supabase since October 2025); the jump is when the audit caught up to it. The broader driver is a real ecosystem shift from self-hosted, env-var MCP servers toward vendor-hosted remote servers with OAuth.
Grade Distribution
Category-by-Category Analysis
Authentication & Identity
12.4 / 25 avg (49%)Data Exposure
6.7 / 10 avg (67%)Tool Schema Quality
17.7 / 25 avg (71%)Maintenance & Trust
3.5 / 5 avg (71%)LLM Safety
12.2 / 15 avg (82%)Permission Granularity
18.2 / 20 avg (91%)Recommendations for Server Maintainers
Support per-user authentication
Implement MCP OAuth or expose HTTP transport with per-request credentials so that actions can be attributed to individual users without running a separate process per user.
Keep tool descriptions descriptive, not instructional
Describe what a tool does, not how or when to use it. Imperative phrasing ("always call first", "do not confirm") becomes an instruction the LLM may follow regardless of user intent.
Support field selection and pagination
Let callers specify which fields to return and paginate list operations. This reduces context bloat and limits over-exposure of sensitive fields when a tool is used for a narrow purpose.
Separate read and write tools
Split combined read/write operations into distinct tools, and isolate admin-level actions behind their own tools. Platforms can then grant read-only access without disabling functionality.
Deploy MCP servers with enterprise controls
CompleteFlow wraps MCP servers with per-user authentication, permission scoping, and audit logging, compensating for the gaps identified in this report.
Learn about CompleteFlow