We have built twelve MCP connectors for our own products and packaged them for OpenAI's app directory and Claude's connector directory. None of the steps are hard on their own. What costs time is the handful of requirements that are not obvious until a dialog loops or a scan flags something. These are our notes, in the order you will meet them.
1. Developer identity: it has to be a business
The upload dialog asks for a verified developer identity, and in our account it only listed business verifications. An approved individual verification never showed up, and the dialog sent us back to organization settings in a loop. Once the business verification was approved, every connector went under that one name. Sort this out first, because nothing else can be uploaded until it is done, and the developer name in your package must match it exactly.
2. Categories are a fixed list
You pick from the portal's list: Productivity, Creativity, Developer Tools, Business & Operations, Data & Analytics, Communication, Education & Research, Security, Finance, Healthcare, Travel, Entertainment and Other. There is no Sports category, so our league and scorekeeping tools went in as Productivity and our draft tool as Entertainment. Choose the one a user would browse, not the one that describes your industry.
3. Annotate every tool, honestly
OpenAI runs an automated scan over your tools after you connect the server. Each tool should carry a title and all three hints: read-only, destructive and open-world. Our rule became simple. Anything that only reads is read-only. Anything that changes something other people will see, like a published schedule, a posted announcement or a price on a storefront, is open-world. Anything that can overwrite or delete is destructive, and those tools take a confirm flag: called without it, they return a preview of the change instead of making it.
4. Exactly five positive and three negative test cases
The package asks for test cases: prompts that should trigger your tools and prompts that should not. We write exactly five positive and three negative cases, each with the expected behaviour checked against the real server, plus three starter prompts for the listing. Negative cases matter more than they look. They are how a reviewer checks your tool descriptions do not grab requests that belong to someone else.
5. A reviewer account that works on its own
If your app needs sign-in, the reviewer needs an account on production with enough demo data to run every test case without help. We build ours with a seed script that creates the account and a demo league, store or club behind it, and we design test cases that create what they need rather than depending on data a reviewer might change. If your server needs no sign-in, leave the credential fields empty: they are only asked for when sign-in is required.
6. The privacy policy has to be specific
A general privacy policy is not enough. Ours each gained a section for ChatGPT and Claude that names the data categories each tool sends, what is never sent, and how long anything is kept. Writing it forced a useful product decision: one roster tool could have returned parents' contact details, and we removed that before submitting rather than explain it.
7. The bugs that only show up in review conditions
- The consent bounce. On one app, pressing Allow on the consent page sent users back to the login screen. The session cookie was being dropped on the cross-site redirect from the assistant. Test the full OAuth flow from inside ChatGPT, not just from your own browser.
- Domain verification. OpenAI checks a challenge served from your domain. It is a deploy, so plan it before you submit, not during.
- No pricing in the listing copy. Describe what the app does, not what it costs.
- Keep the reviewed version still. When we added tools during review, we hid them from ChatGPT behind a flag until approval, so the reviewer saw the version we submitted.
8. Record the demo on the reviewer account
The submission takes a demo recording. Record it in ChatGPT, connected as the reviewer account, running the same flows as your test cases. Two to three minutes of a real screen is plenty. It doubles as the video for your own site's ChatGPT page.
What we would tell anyone starting
Budget the packaging as real work: identity, annotations, test cases, reviewer data, privacy wording and a demo. It is a few days on top of the build the first time, and most of it carries over to the next connector. If you would rather not learn it on your own product, this is exactly the work we do.