The Short Answer
To get a product into ChatGPT you build a server that ChatGPT can call, using the Model Context Protocol, then submit it through the OpenAI developer platform with a listing, a working test account, eight written test cases and a short video. A reviewer tests it against published guidelines. If it passes, you choose when it goes live, and people can then find it in ChatGPT and use it inside their conversations. We went through this in the autumn of 2026 with one of our own tools, and the parts that take time are not the code. They are the test account, the test cases and the rules on selling.
The one sentence version
Build a server whose tools do one clear job, make it testable by a stranger in five minutes, describe it without a single claim you cannot back, and do not try to sell digital subscriptions through it.
What Being in ChatGPT Means Now
The vocabulary has moved several times, so it helps to pin it down. Today a third party integration in ChatGPT is a package that points at a server you host. OpenAI's developer documentation currently calls the submitted package a plugin, while most people, and most of the press, still say ChatGPT app. Either way the moving part is the same: an MCP server exposing tools, plus a listing that tells ChatGPT and its users what those tools do.
That is different from being cited by ChatGPT. Citation is ChatGPT quoting your website in an answer, which we cover in our guide to getting cited by ChatGPT. Being in ChatGPT means a person can ask ChatGPT to do something and ChatGPT calls your tool to do it. One is a source. The other is a capability. A product can have both, and they reinforce each other, but the work is entirely different.
| Term you will hear | What it actually is | Where you deal with it |
|---|---|---|
| MCP server | Your service, speaking the Model Context Protocol, exposing named tools | Your own infrastructure |
| Tool | One action the server offers, with a name, a description and typed inputs | Your server code |
| Plugin or app | The package and listing that point ChatGPT at your server | The OpenAI developer platform |
| Directory | Where people browse and add approved integrations | Inside ChatGPT, after approval |
| Review | OpenAI testing your submission against its guidelines | Between submission and publishing |
Before You Start: What You Need Ready
Most delays come from things that are not code. Gather these before you open the submission form, because the form will stop you at each one.
| Requirement | What it means | Where people get stuck |
|---|---|---|
| A verified organization | Individual or business verification in your OpenAI organization settings, so the listing can carry your name | Verification can take longer than the build |
| The right permission | Organization owners can submit; other members need the Apps Management Write permission | A developer without the permission sees no submit option |
| A public secure server | Your MCP server reachable on the open internet over an encrypted connection with a valid certificate | Servers behind a login wall or an IP allow list fail review |
| Four live URLs | Website, support, privacy policy and terms of service, all on secure addresses | A privacy policy that does not mention the integration |
| A demo account | A login and password for a fully featured account a reviewer can use | Demo accounts with limits that block the features being tested |
| Eight test cases | Five that should trigger your tools and three that should not | Writing them after the fact, vaguely |
| A video walkthrough | A recording of the integration working, linked by URL | Recording before the final version is deployed |
Step 1: Design Tools a Model Can Choose Correctly
A model decides whether to call your tool by reading its name and description, so those two strings do more work than any line of your code. OpenAI's guidelines ask for human readable, specific names written as verbs, like get_order_status, and descriptions that say what the tool does, when to use it and what its limits are. A tool that does three things should usually be three tools.
Every tool also needs three explicit annotations. They tell ChatGPT how careful to be before calling it, and reviewers check that they are honest.
| Annotation | Set it to true when | Set it to false when |
|---|---|---|
| readOnlyHint | The tool only retrieves or previews something | The tool changes state anywhere |
| destructiveHint | The tool deletes something or has an effect that cannot be undone | The tool only adds or creates |
| openWorldHint | The tool works with public or open ended things, such as the web | The tool works inside a bounded account |
Ask for the minimum input each tool needs. The guidelines are explicit that a tool should not request chat history or broad context just in case. On our own servers, agents sent short inputs: the median text sent to the main action was 153 characters. Design for a sentence, not a chapter, and return results fast enough that a person waiting in a chat does not think it broke. Our wider guide to MCP servers for business covers the server side in more depth.
Ship the boring helper tools
On our servers, the tools that list options, report remaining allowance and suggest a choice were called 314 times, against 931 calls to the main action. Agents plan before they act. Give them the tools to plan with.
Step 2: Authentication a Reviewer Can Actually Use
If your tools need an account, ChatGPT connects through OAuth, and you supply the OAuth details and a domain verification token with the submission. The rule that catches people is in the guidelines: provide a login and password for a fully featured demo account, and integrations that require additional login steps will be rejected. The reviewer must be able to sign in once and test everything.
What worked for us was splitting the tools in two. Basic actions work for a guest with no account, metered by address, so ChatGPT can use the tool immediately for anyone. Anything tied to a person's data sits behind OAuth, and the connect page asks for the user's existing API key in one field. The demo account we gave the reviewer was a full paid account, so nothing they tried was blocked by a plan limit.
Decide which tools need an account
If a tool can work anonymously with a limit, let it. Fewer login prompts means more people try it.
Keep the connect step to one screen
One field and one button. Extra verification steps are a common reason for rejection.
Return a clear message when a login is needed
A protected tool called anonymously should answer with a plain request to connect, not a vague error.
Give the reviewer a real account
Full features, no trial expiry during review, and credentials kept out of the package itself.
Step 3: Write a Listing That Survives Review
The listing has hard limits that are easy to miss. The display name can be at most 30 characters, and so can the short description. The long description can run to 4,000. Icons and screenshots can be PNG, JPEG, WebP or SVG, up to 5 MiB each.
The guidelines ask for names and descriptions that are clear, accurate and straightforward, without comparisons to other products, without disparagement and without claims that cannot be verified. That rules out most marketing copy. Write the long description like documentation: what the tools do, what they do not do, what an account adds, and what the limits are. It is the same discipline as writing a page that AI can extract cleanly, because a model reads it to decide when to call you.
| Field | Limit | What to put there |
|---|---|---|
| Display name | 30 characters | Your product name, nothing else |
| Short description | 30 characters | The single job, as a verb phrase |
| Long description | 4,000 characters | Every tool, its limits, what needs an account, what data you keep |
| Screenshots | PNG, JPEG, WebP or SVG, 5 MiB each | Real conversations using the tool, not mockups |
| Countries | Optional list of country codes | Leave it empty unless you have a legal reason to restrict |
Step 4: The Eight Test Cases
You submit five positive test cases, each a prompt that should trigger your tools with the expected tool call and result, and three negative ones that should not trigger anything. This is where reviewers spend their time, so write them as if a stranger will paste them in word for word, because one will.
Positive cases cover the main job
At least two prompts for your core action, one for each helper tool, and one that needs an account, so the reviewer sees the login flow work.
Negative cases prove restraint
A prompt that is near your topic but not your job, a request your tool should refuse, and an unrelated question. The right result for all three is no call.
Expected results are specific
Name the tool that should be called and describe the result in a sentence, so the reviewer can tell at a glance whether it passed.
Record the video walkthrough last, on the exact version you are submitting, running through two or three of the positive cases and the login. If anything changes after recording, record again.
The Rules on Selling Are Stricter Than You Expect
This is the section most product teams read too late. The current guidelines allow commerce for physical goods only. Digital products, subscriptions and upsells are prohibited, and an integration cannot link directly to a checkout or other transactional page. It can explain that a feature is unavailable.
For a software company that sells subscriptions, that changes the design. The integration cannot be a sales funnel. It has to be useful on its own terms, with a free tier that does real work, and the paid version reached by the person through your own website, not through a link pushed inside the chat. Plan your free limits so a reviewer and an ordinary user both get genuine value before they hit them.
Do not borrow the brand
Trademark care matters on your own pages too. When we built a landing page for our integration we kept the ChatGPT name in plain text, with no logo styling, and added a short trademark notice. A review is not the only place a brand owner looks.
Prohibited Categories and Data You Must Not Collect
Some products cannot be submitted at all. The guidelines list prohibited categories including sexual services, gambling, illegal drugs, counterfeit goods, malware, weapons, fake identification, unregulated financial services and speculative or fraudulent crypto schemes. Integrations must be suitable for people aged 13 to 17 and cannot target children under 13.
Separately, some data must never be collected through the integration: payment card details, health records, government identification and authentication credentials. Behavioural tracking and profiling are not allowed unless they are disclosed and under the user's control. Your privacy policy has to explain what you collect, why, who receives it, how long you keep it and what control the user has.
What Happened When We Submitted
We submitted one of our own tools in the autumn of 2026 and it went live on the 2nd of October. Three things from that experience are worth passing on.
The reviewer tests immediately
Within minutes of approval our server log showed the reviewer making 17 calls with the demo account. Make sure the demo account works the moment you press submit, not the next morning.
Review sessions show up in your log
Review traffic arrives under a distinctive client name, so you can watch exactly what the reviewer tried and fix anything that failed before they finish.
Chat traffic is real traffic
Over nine days across two of our servers, chat assistant clients made 849 tool calls from 960 connections, close to one call per connection. Coding agents and directory robots connect far more and call far less.
The last point is the one to remember once you are live. Most connections to an agent server are robots checking it is alive, and coding tools reconnecting at the start of every session. Count tool calls, split by client type, and judge adoption by the calls that came from a person asking for something.
After You Are Live
Publish when you are ready
Approval does not publish automatically. You choose when, so line it up with your landing page and support.
Treat every update as a new release
Publishing an update replaces the previous version, so test the new package as carefully as the first.
Give the integration its own page
A page on your site that explains what it does, with real examples, helps people find it and helps assistants describe it accurately.
Watch calls, errors and logins
Calls per client type, failed calls and login requests tell you what people try and where they give up.
If you also sell physical products, the integration can sit alongside the product feeds that agents read, which is a separate route into assistant shopping. And because ChatGPT now shows ads to some users, it is worth knowing how ads and citations interact before you plan any paid promotion around your listing.
Common Reasons Integrations Get Rejected
A login the reviewer cannot pass
Extra verification, expiring trials or a demo account without the features being tested.
Tools that do too much
One tool with several modes and a vague description, which a model cannot choose reliably.
Annotations that are not honest
A tool that changes data marked as read only, or a deletion not marked as destructive.
Selling inside the chat
Upsell messages, subscription offers or direct checkout links for digital products.
A listing that oversells
Comparisons with competitors, superlatives and claims that cannot be checked.
A privacy policy that ignores the integration
The policy must cover what the integration collects, not only the website.
The Bottom Line
Getting into ChatGPT is less about clever code and more about being easy to test and honest to describe. Build tools that each do one job, mark them truthfully, give the reviewer a real account, write eight test cases a stranger can run, and keep selling out of the conversation. Then count what actually happens: tool calls from people, not connections from robots. The documentation and its terms will keep changing, so read the current guidelines on the day you submit. The principles above have held through every version so far.