We Checked 61 Official MCP Servers Against the Auth Spec

Most SaaS companies now ship an official remote MCP server, and most of them sit behind OAuth. We wanted to know how closely those servers follow the current MCP authorization spec (the 2026-07-28 revision), so we checked the official servers of 67 vendors from the outside. 61 of them require a login. This post is about those 61. The short version: the basics are done everywhere. The newer parts of the spec are not. How we checked We used our free MCP Server Check. It is passive. For each server it sends one unauthenticated initialize request, reads the public OAuth discovery documents, and calls tools/list only if the server answers without a token. It never calls a tool and never sends a token. We ran every server on October 26 and again on November 4, 2026. The numbers below are from November 4. Results are point in time and checked from Cloudflare's network, so a server can look different from another network or a few days later. What every server gets right All 61 answer an anonymous request with HTTP 401, and all 61 advertise PKCE with S256. That is the part of the spec that stops the most obvious mistakes, and nobody skipped it. 56 of 61 also publish OAuth Protected Resource Metadata (RFC 9728) and point to it from the 401 response, which is how a client finds where to log in. The other 5 either use the older 2025-03-26 discovery layout or publish the metadata without pointing to it in the 401. Where most of them fall behind Client registration. The current spec says Dynamic Client Registration "is deprecated and retained for backwards compatibility with authorization servers that do not support Client ID Metadata Documents." 25 of 61 advertise Client ID Metadata Documents (CIMD). The other 36 rely on dynamic registration or manual client setup. Nothing breaks today, but every client that connects to those 36 still needs a registration step the spec is moving away from. Issuer check. The spec says authorization servers SHOULD include the iss parameter in authorization responses (RFC 9207), and advertise it with authorization_response_iss_parameter_supported. It lets a client catch an OAuth mix-up attack, where a code from one authorization server is sent to another. 40 of 61 do not advertise it. Scope hint. 22 of 61 give the client no hint about which scopes to request, neither in the 401 nor in scopes_supported. The client then has to guess, and guessing usually means asking for more than it needs. Who moved in nine days Between October 26 and November 4, six changes showed up: Apollo, Cal.com and Neon started advertising Client ID Metadata Documents. Neon and Mercado Pago started advertising the RFC 9207 issuer parameter. Datadog's 401 now points to its protected resource metadata. None of these companies told us about it, and we did not contact them. It is a sign the spec changes are being picked up, just not all at once. The full table Score is out of 100 and also includes transport and HSTS checks that are not shown as columns. "Discovery: partial" means the server uses the older discovery layout or does not point to its metadata from the 401. Company Score CIMD iss (RFC 9207) Scope hint Discovery Fireflies 100 yes yes yes ok Notion 100 yes yes yes ok Airtable 98 yes no yes ok Apollo 98 yes no yes ok Canva 98 yes no yes ok Clerk 98 yes yes yes ok Klaviyo 98 yes yes no ok Linear 98 yes yes yes ok Neon 98 yes yes no ok Railway 98 yes yes yes ok Sentry 98 yes yes yes ok Tavily 98 yes yes yes ok Vercel 98 yes no yes ok monday.com 98 yes yes no ok Amplitude 96 yes no yes ok Cal.com 96 yes no no ok Grafana 96 yes no yes ok Granola 96 yes no yes ok Honeycomb 96 yes no yes ok MongoDB 96 yes yes no ok PostHog 96 yes no yes ok Resend 96 yes yes no ok Todoist 96 yes no yes ok Figma 95 no yes yes ok GitHub 95 no yes yes ok Supabase 95 no yes yes ok Semgrep 94 yes no no ok Asana 93 no no yes ok Buffer 93 no no yes ok ClickUp 93 no yes yes ok Close 93 no no yes ok Gamma 93 no yes yes ok GitLab 93 no no yes ok Jam 93 no no yes ok Miro 93 no no yes ok Netlify 93 no no yes ok Slack 93 no no yes ok Stripe 93 no no yes ok Ahrefs 91 no no no ok Box 91 no no no ok Cloudflare Bindings 91 no yes no ok Datadog 91 no no no ok Dropbox 91 no no yes ok Hex 91 no no no ok HubSpot 91 no no no ok Intercom 91 no no yes ok Mux 91 no no no ok PagerDuty 91 no no yes ok Postman 91 no no no ok Prisma 91 no no yes ok Wix 91 no no yes ok Make 90 no no no ok PayPal 90 no no no ok Render 90 no no no ok Square 90 no no no ok Webflow 90 no no no ok Apify 89 yes yes yes partial Mercado Pago 84 no yes yes partial Zapier 84 no no yes partial Plaid 82 no yes no partial Atlassian 80 no no no partial Notion and Fireflies passed every check. Six more vendors answered tools/list without a token: Hugging Face, Context7, Shopify (setup.shopify.com), DeepWiki, Firecrawl and Browserbase. They are documentation, search and scraping tools where open access looks like a deliberate choice, so we left them out of the auth numbers. Nine addresses we tried did not answer as MCP servers, usually because we guessed the wrong URL, and they are not reported. If you run one of these servers The three changes are small. Advertise client_id_metadata_document_supported once your authorization server supports CIMD, include iss in authorization responses and set authorization_response_iss_parameter_supported: true, and put a scope in the WWW-Authenticate header of the 401. If you think we scored your server wrong, run it through the checker and tell us at hello@x1y1.co. We would rather fix a rule than publish a wrong number. There is also a JSON API: https://x1y1.co/api/mcp-check?url=. Originally published at x1y1.co.