Why Vercel Connect services get rejected

What reviewers and the rules say

The server works for you but not from the reviewer’s network. Review traffic goes through TLS-inspecting proxies and automated clients, which fail on things a browser at home never hits: Encrypted ClientHello advertised in DNS (the proxy resets the handshake, so nothing reaches your logs), a firewall or bot rule that answers scripts with 403, a 403 instead of a 401 for calls without a token, or a URL pasted with a trailing slash that 404s. ECH alone cost one developer three ChatGPT rejections. OpenAI uses the same wording when the test credentials don’t work, so check sign-in too.

How to fix it

• Turn off Encrypted ClientHello for the MCP host. On Cloudflare it’s a zone setting, and only reachable through the API on the free plan.
• Let automated clients through on the MCP path: no bot challenge, no user-agent or country rules.
• Answer calls without a token with 401 and a WWW-Authenticate header, never 403.
• Serve /mcp/ as well as /mcp.
• Test from outside your own network, with a TLS 1.2 client as well as a browser.
• Appeal by replying to the rejection email with your case ID, and ask what error the reviewer saw.

How common it is: in our scan of Claude’s connector directory on 29 September, 16% of servers advertise Encrypted ClientHello in DNS (505 of 3,185), and 39% of servers stop working when the URL has a trailing slash (221 of 562).

Caught by

• server.ech DNS does not advertise Encrypted ClientHelloServer check
• server.bot-filter Automated clients are not blockedServer check
• auth.401 Unauthenticated calls get 401 with resource_metadataServer check
• server.trailing-slash The URL with a trailing slash works tooServer check
• server.reachable Server answersServer check
• server.tls12 A TLS 1.2 client can connectmcplane CLI

Check your servermcplane docs

What reviewers and the rules say

Reviewers sign in as strangers, on a network you don’t control, with the account you gave them. It breaks when the account needs an emailed code, a magic link, MFA or a Google login, when the sign-in page waits on JavaScript from another domain that is slow or blocked (they see a blank page), when that domain sits behind a bot challenge, or when OAuth discovery or client registration fails.

How to fix it

• Give reviewers a dedicated account with a login and password that works immediately: no MFA, no email or SMS codes, no magic links, not your Google or SSO login, and seeded with data for every test case.
• Sign in once as a brand-new user, in a fresh browser, from outside your network. Make the page show something before any JavaScript loads.
• Keep bot challenges off your sign-in and auth domains, not just the MCP path.
• Serve protected-resource metadata on the MCP host, authorisation-server metadata and PKCE (S256), and Dynamic Client Registration that accepts the store’s redirect URIs.
• Accept private-use redirect schemes such as cursor:// in client registration, or desktop clients can’t sign in at all.

Caught by

• auth.prm Protected-resource metadata resolves on the MCP hostServer check
• auth.as-metadata Authorization-server metadata resolvesServer check
• auth.pkce PKCE (S256) is supportedServer check
• auth.dcr Dynamic Client Registration is offeredServer check
• auth.dcr-native Registration accepts native redirect URIs (with --register)mcplane CLI
• A reviewer account a stranger can use, and a sign-in page that renders without third-party scriptsBy hand

Check your servermcplane docs