If you are building on the Model Context Protocol (MCP), you know the ecosystem is flooded with official remote servers from major SaaS vendors. A new independent audit by x1y1.co checked 61 of these official servers against the 2026-07-28 revision of the MCP authorization spec, and the results are a mixed bag for developers. While every server correctly implements basic OAuth 2.1 security measures, the majority are failing to adopt the newer, more robust client registration and issuer verification mechanisms that the spec now recommends.

The Basics Are Solid, The Future Is Missing

The good news is that the fundamental security hygiene is in place across the board. All 61 servers respond to anonymous requests with an HTTP 401 and advertise PKCE with S256, which prevents the most common authorization code interception attacks. Furthermore, 56 of the 61 correctly publish OAuth Protected Resource Metadata (RFC 9728) and point to it from the 401 response, allowing clients to automatically discover where to log in. However, this compliance stops at the basics. When it comes to the newer parts of the spec designed to streamline client onboarding and improve security against mix-up attacks, adoption is sparse.

Dynamic Client Registration Is the Bottleneck

The most significant gap is in Dynamic Client Registration (DCR). The current spec explicitly deprecates DCR in favor of Client ID Metadata Documents (CIMD), yet only 25 of the 61 audited servers advertise CIMD support. The remaining 36 servers still rely on dynamic registration or manual client setup. This means that for every new MCP client connecting to those 36 servers, developers still have to go through a registration step that the spec is actively moving away from. Notion and Fireflies were among the few to score a perfect 100, adopting CIMD, RFC 9207 issuer parameters, and proper scope hints.

Issuer Verification and Scope Hints Lag Behind

Beyond client registration, security against OAuth mix-up attacks is also under-implemented. The spec suggests that authorization servers should include the iss parameter in responses and advertise authorization_response_iss_parameter_supported. This allows clients to verify that the authorization code came from the expected server. Shockingly, 40 of the 61 servers do not advertise this support. Additionally, 22 servers provide no scope hints in their 401 responses or scopes_supported metadata, forcing clients to guess which permissions they need, often resulting in over-permissive access requests.

The Ecosystem Is Moving Slowly

There is some momentum, albeit slow. Between October 26 and November 4, six vendors updated their servers. Apollo, Cal.com, and Neon started advertising Client ID Metadata Documents. Neon and Mercado Pago began advertising the RFC 9207 issuer parameter, and Datadog updated its 401 response to point to its protected resource metadata. None of these companies proactively announced the changes, but their updates signal that the spec revisions are being picked up, just not all at once.

Key Takeaways

  • Basic OAuth security (PKCE, 401 responses) is universal across all 61 audited MCP servers.
  • Only 25 of 61 servers support Client ID Metadata Documents (CIMD), the spec's preferred method over Dynamic Client Registration.
  • 40 of 61 servers lack issuer verification (RFC 9207), leaving clients vulnerable to mix-up attacks.
  • 22 servers provide no scope hints, forcing clients to guess permissions and often over-requesting access.

The Bottom Line

For MCP server maintainers, the path to compliance is clear and relatively low-effort: advertise CIMD support, implement RFC 9207 issuer verification, and provide scope hints in your 401 headers. The fact that six vendors updated their servers in a nine-day window shows that the ecosystem is moving, but if you are building a client that needs to work seamlessly across the top 61 MCP servers, you still need to handle legacy registration flows and missing security hints. Don't assume your favorite SaaS is spec-compliant; check the audit data before you architect your auth flow.