How to Submit Your App to the ChatGPT Directory
The end-to-end playbook for getting your app listed in the ChatGPT apps directory in 2026 — eligibility, the submission flow, what OpenAI's review actually checks, and the post-approval steps that determine whether users find and stick with your app.
The short version
ChatGPT apps live in the apps picker inside ChatGPT and are powered by MCP servers built with the OpenAI Apps SDK. The path is: build a clean MCP server, ship the minimum OAuth scope you can defend, assemble the compliance items, submit through the developer dashboard, respond fast to review feedback, and then measure connection-completion and first-call-success rather than vanity installs.
If you're new to the protocol, start with our ChatGPT MCP explainer and the Apps SDK quickstart before this page — they cover the engineering setup that this guide assumes.
Step-by-step submission flow
- Step 1
Confirm eligibility and the use case fit
Before writing any code, confirm your app makes sense inside ChatGPT. The best fits are apps that produce or operate on real-world artifacts the user owns (Drive files, Notion pages, Stripe charges, Calendar events) or that augment a conversation with something the model can't do well alone (math, image generation in a specific style, structured database query). Generic 'chat with our data' apps without a real differentiator usually don't clear the bar — the bar isn't 'does it work' but 'does it earn the user's time inside a conversation'.
- Step 2
Build the MCP server and Apps SDK manifest
ChatGPT apps are MCP servers. Use the OpenAI Apps SDK to scaffold the server, define your tools (the discrete actions the assistant can call), and write the manifest. Keep tools narrowly scoped — one tool, one verb, one resource. Avoid omnibus 'do_thing' tools with a dozen parameters; they perform worse in practice because the model has trouble routing to the right call. Document each tool's parameters with descriptions a non-technical reader could follow — those descriptions are what the model reads to decide whether to call your tool.
- Step 3
Lock down the OAuth scopes
Request the smallest scope set that lets your app deliver its core value. Reviewers explicitly check for scope creep: an app that says 'connect Calendar' but requests full Drive write access will get rejected fast. If you have a write tool that 90% of users will never use, ship it behind a separate, optional scope — read access by default, opt-in writes on demand. Scope minimization is also the single biggest determinant of user trust at the connection screen.
- Step 4
Write the user-facing copy: name, description, icon, screenshots
Your name and one-line description are what users see in the app picker. The name should be the brand of the service — not 'AI Notion Helper', just 'Notion'. The description is a single sentence answering 'what does this app do in ChatGPT?' in plain English. Icons must be on-brand, square, and legible at 32px. Screenshots show real in-chat usage — not marketing screenshots from your main product.
- Step 5
Ship the compliance items
Privacy policy, terms of service, abuse contact, and a verifiable publisher identity are all checked. The privacy policy needs to specifically address what data the app accesses through ChatGPT — generic 'we may collect data' boilerplate is insufficient. The terms should be linked from the app metadata and not behind a login. The abuse contact must be monitored — if a user reports issues and you don't respond, the listing gets suspended.
- Step 6
Submit through the developer dashboard
The submission flow lives in the OpenAI Apps SDK dashboard. You'll provide the MCP server endpoint, the manifest, the metadata, and the compliance links. Submit a real, production-ready endpoint — staging endpoints get rejected because reviewers can't predict their behavior under real load.
- Step 7
Respond to the review
Reviewers will run your app, call your tools, and check a sample of real flows. Expect specific, actionable feedback. The fast path is to respond within 24 hours with either a clarification or a deployed fix. Slow responses extend the queue; clean responses ship.
- Step 8
Launch and measure the right things
Once approved, your app shows up in the picker and is searchable. The metrics that matter on day one: connection completion rate (did users finish OAuth), first-call success rate (did the first tool call return a useful result), and retention after seven days. If first-call success is low, your tool descriptions or scoping are off — iterate there first, before chasing distribution.
Pre-submission checklist
Go through this list before you hit submit. Every item below maps to something reviewers check.
- App is built on the OpenAI Apps SDK and MCP
- All tools have single-verb names and minimal parameters
- OAuth scopes are minimal — write access opt-in if applicable
- Privacy policy specifically covers ChatGPT-connector data flow
- Terms of service URL is public (no login required)
- Abuse / support email is monitored
- Icon is brand-consistent and legible at small sizes
- Screenshots show real in-chat usage with realistic content
- Production endpoint is up, not staging
- Internal team has stress-tested at least 20 real prompts
What reviewers actually check
Three things, in order of weight. First, does the app deliver value inside a conversation that a user couldn't get more cheaply elsewhere (e.g., by just opening your web app). Second, are the scopes minimal and the data-handling story coherent — because the connection screen is the user's only real defense and reviewers treat it as the user's interest, not the developer's. Third, is the tool surface stable and predictable — reviewers will call your tools repeatedly; intermittent failures or surprising side effects extend the review or trigger rejection.
The reviewers are notably less interested in marketing copy and very interested in real behavior under realistic prompts. If you haven't stress-tested at least 20 real prompts in-chat before submitting, you're not ready. Submit a polished, narrow app instead of a sprawling one — narrow apps clear review faster and rank better in the directory because users complete the connection flow more often.
After approval
Approval is the start, not the finish. The two highest-leverage post-launch moves: (1) iterate the tool descriptions based on real misroutes — if you see the model picking the wrong tool for a common prompt, the description is the cheapest thing to fix; (2) tighten or expand scopes based on real usage — most apps over-scope on day one and would be better off shipping a narrower default and an opt-in upgrade for power users.
Distribution-wise: an editorial review on a directory like this one is a stronger signal than a vanity install count. We test apps hands-on and publish dated reviews; the app-submission form is the fastest way to get on our queue once you're live.
Frequently asked questions
Frequently asked questions
- Who can submit an app to the ChatGPT directory?
- Any developer or company that has built an MCP-compatible app using the OpenAI Apps SDK can submit. You need a working server, a published OpenAI developer account, and the basic compliance items in place — privacy policy, terms, identifiable publisher, and a way to handle abuse reports.
- Is there a cost to list an app in ChatGPT?
- No listing fee at the time of writing. OpenAI takes no upfront cost for app submission. Costs accrue on your side — hosting the MCP server, the underlying service you're exposing, and whatever monetization model you operate inside the app.
- How long does the ChatGPT app review take?
- Initial response is typically days, not weeks, but full approval depends on the complexity of the integration and how clean your submission is. Apps that touch sensitive data, financial transactions, or write-heavy scopes are reviewed more carefully and take longer.
- Can I update my ChatGPT app after it ships?
- Yes. The MCP server you host is the source of truth, so server-side tool changes propagate without re-submission. Manifest, metadata, scope, and category changes go through a lighter review. Major scope expansions (e.g., read-only → write) trigger a re-review.
- What if my app gets rejected?
- Rejections typically cite a specific compliance item, scope concern, or unclear value proposition. The review feedback is actionable — fix the cited issue and re-submit. The single most common rejection cause is requesting broader scopes than the workflow actually needs.