The Model Context Protocol made an appealing promise: build one server, and every AI assistant can use it. For the protocol itself, that promise holds. Our MCP server speaks to Claude, ChatGPT, Cursor, and a growing list of agent platforms through the same endpoint, the same OAuth flow, the same eighteen tools.
Distribution is a different story. Each platform gates its catalog behind its own review process, and this month we took the same server through two of them: OpenAI’s app submission for ChatGPT, and Google’s connector intake for Gemini Enterprise, with Anthropic’s directory flow running alongside. The processes could hardly be more different in shape. They are also, underneath, checking the same things.
These are our field notes. If you run an MCP server and want it distributed where agent users actually are, this is what to expect.
The human review: OpenAI
OpenAI’s process certifies what a human reviewer experiences. Everything you submit exists so that a person, following your instructions in a real ChatGPT session, has a good first encounter with your connector.
That framing explains every artifact they ask for:
Compatibility tool shapes. ChatGPT expects two specific tools, search and fetch, with documented result schemas, declared via outputSchema and returned as structured content. Your richer tools can coexist with them, but the pair must be exactly right.
A written justification for every safety annotation. Each tool carries three flags: read-only, open-world, destructive. The portal asks you to justify each flag on each tool in a sentence. For our eighteen tools that meant fifty-four small essays. It sounds bureaucratic and turned out to be the best audit of our own annotations we ever did. If you cannot justify a flag in one sentence, the flag is wrong, or the tool is.
Example prompts, displayed verbatim in your listing. You get three. We learned to verify each one against the live corpus before submitting: one candidate prompt had thousands of matching segments, another had thirty-eight. The second would have demoed as a failure to the reviewer and to every future user who clicked it, so it went. Never submit a query you have not run.
Negative test cases. This one surprised us: alongside five scenarios showing what your connector does, they want three showing when it should not trigger. Adjacent-sounding intents your server cannot serve. For an audio search tool, that means “play the latest episode” (we search speech, we are not a player), “turn this post into a podcast” (we transcribe audio, we do not generate it), and “what are they saying on the live stream right now” (we index published recordings, not live streams). Writing these sharpens your own understanding of the product boundary, and they exist so the model does not invoke your connector for requests it will fail.
Static reviewer credentials. Our platform is passwordless by design: OAuth sign-in and magic links only. The review process needs a username and password that grant immediate access. The answer was not to bolt password auth onto the product. We built a narrowly scoped, environment-gated reviewer sign-in that lands in a dedicated demo account, seeded with sample data so every user-scoped tool returns something meaningful. If your product is passwordless, budget for this: it is a small build, and the review does not proceed without it.
Plus the expected trimmings: a demo video, screenshots, domain verification through a well-known challenge endpoint, and working privacy, terms, and support pages. Automated checks fail on a broken support link just as surely as a human does.
The machine review: Gemini Enterprise
Google’s process certifies machine-checkable behavior. Your submission feeds an automated evaluation pipeline, and vagueness fails where a human reviewer might have shrugged.
Isolated test instances, plural. The intake asks for three separate environments on your production system: one for general evaluations, one exclusively for mutative actions, one for quality testing, with data, configuration, and auth isolation between them, and a roster of named evaluation accounts pre-provisioned in specific roles: admin, read-write, read-only. If your architecture is multi-tenant, this is a morning of provisioning. If it is not, this requirement is the forcing function that tells you something about your architecture.
A golden evaluation dataset. This is the heart of it: a shared spreadsheet with two tabs. One maps natural-language queries to golden answers and golden documents, the other maps mutative requests to the exact tool and grounded parameters they should trigger. They ask for at least five queries per tool and coverage of well over half your tool surface. Two lessons from building ours. First, ground every golden answer in data you have verified, because an automated judge will execute your queries and compare. Second, phrase answers for tools whose output changes over time so they stay true as data changes: assert that a known item appears, not that a query returns an exact count.
Short fixtures for anything mutative. Evaluation pipelines re-run your write tools, repeatedly, forever. If a test case submits an hour of audio to a processing pipeline, automated re-runs burn quota and wall-clock until something breaks. We pointed every mutative test parameter at short clips hosted on infrastructure we control: a couple of minutes each, stable URLs, negligible cost per run.
Attestations. You confirm your transport (streamable HTTP), and that the platform’s published IP ranges can reach you. That second one deserves a real check, not a reflexive checkbox: platform traffic funnels many end users through shared egress IPs, and if your rate limiting is keyed per IP, aggregate legitimate traffic can hit ceilings no individual user is near.
And a click-through provider agreement. Read the license scope and the data-use clauses before accepting, and save a dated copy, because catalog terms can change after you accept.
The third lane: Anthropic and the open registry
Anthropic’s connector directory recently moved to a self-serve submission flow inside Claude itself: you submit and manage the listing from the product where the connector runs. The requirements will feel familiar if you have done the OpenAI pack, and the collateral reuses directly: the same remote server and OAuth flow, the same seeded demo account, the same review credentials. One part is refreshingly automated: the portal reads your live tools/list and lints it, so honest titles and annotations either pass on sync or get flagged immediately, with nothing to paste.
Three practical notes from our pass. Connector slugs are global and permanent, so check availability and choose an unused one early; it is the kind of small detail you want settled before you fill anything else in. Check your CDN’s bot rules before you connect: edge settings that block AI crawlers can also block an assistant platform’s egress ranges, and the failure presents as broken authorization even though your OAuth is fine. And alongside the directory sits the open MCP registry, where a server.json under a domain-verified namespace (verification runs through a well-known endpoint on your host) gets you long-tail discovery in Cursor and every other client that reads the registry. Our server has been listed there since January, and it has quietly been the discovery channel that costs nothing and keeps working.
The self-serve shape is its own philosophy, sitting between the other two: lighter than a human review, more trusting than an eval pipeline, with automated verification carrying the trust that a reviewer or a golden dataset carries elsewhere.
Two philosophies, one bar
Put side by side: OpenAI asks “will a person have a good experience,” Google asks “does the behavior verify against ground truth.” An experience review and a behavior review. We suspect the platforms will converge on hybrids of both, because each catches what the other misses.
But here is the thing we did not expect: beneath the wildly different artifacts, both processes verify the same fundamentals. OAuth discovery that works from a cold start, without pre-shared secrets. Safety annotations that are honest. Every declared tool actually executing, with clean failures for missing arguments, invalid inputs, and absent auth. Test accounts that come seeded with data, so user-scoped tools are testable. Example queries verified against real data before anyone else runs them. A live legal and support surface. And enough observability on your side to know when review traffic arrived and whether it succeeded.
We distilled that shared core into two runnable guides in our docs, free of any platform specifics: Testing Your Integration for the REST path and Testing Over MCP for the protocol path. They are the checklists we now run against our own server, and they apply to any MCP or API integration, including ones built against platforms that are not ours.
What this means if you run an MCP server
The bar for agent-platform distribution is rising, and it is rising toward things you should want anyway. Honest tool annotations, discoverable OAuth, seeded test accounts, golden datasets, negative trigger cases, short fixtures: every one of these made our server better independent of any listing. The platforms are effectively outsourcing a quality process that most small teams would not impose on themselves.
Our advice: build the assets once, and treat each platform’s intake as a projection of the same underlying kit. The tool inventory with justified annotations, the seeded demo environment, the golden query set, the negative cases, the short fixtures. Each review then becomes a formatting exercise instead of a scramble.
And run your own review before anyone else does. Cold start against your production endpoint, from a machine that has never seen it. The platforms will do exactly that, and so will every user who matters.
