ChatGPT plugin directory submission checklist for SaaS builders
A practical guide for SaaS founders preparing a ChatGPT or Codex plugin listing, with metadata, policies, MCP tools, screenshots, and review notes.
Short answer
Plugins are now a discovery layer for workflow capabilities across ChatGPT and Codex, so the listing has to explain what users can safely do.
Prepare your plugin name, short and long descriptions, category, website, logo, support URL, privacy policy, terms, auth flow, and test path.
If the plugin includes an MCP server, tool names and descriptions should be specific, accurate, and tied to real user goals.
A strong plugin submission gives reviewers a clear install path, accurate tool behavior, and enough public product context.
Quick answer
Treat a ChatGPT plugin submission like a product launch for a workflow, not like another link in a launch spreadsheet.
The listing has to explain what the user can install, what the plugin can do, what system it touches, what permissions it needs, and where the user remains in control.
That is why the plugin listing needs to be more specific than a normal SaaS launch blurb.
List your SaaS on IndieFame before you send reviewers and early users to a plugin that has no public product context.
What changed
OpenAI's help center says that, as of July 9, 2026, the app directory moved to the Plugin directory. It describes plugins as the primary way to discover workflow capabilities across ChatGPT and Codex, while apps remain integrations that connect ChatGPT or Codex to external data and actions.
That distinction matters for SaaS founders.
You are not just submitting a brand. You are submitting a capability that may include:
- Skills.
- An MCP server.
- App-style integrations.
- App templates.
- Optional UI.
- Workflow prompts.
OpenAI's plugin submission docs say a plugin can include skills, an MCP server, or both. The same docs say the submission form collects listing information, MCP server details, skills, starter prompts, test cases, country availability, and policy attestations.
That is a lot more specific than "write a good description."
Submission checklist
Prepare this before opening the portal.
| Material | What to prepare |
|---|---|
| Plugin name | Brand-specific, not a generic single-word category |
| Short description | One workflow, one audience, no hype |
| Long description | What it does, what it does not do, and how users start |
| Category | The closest real category, not every possible use case |
| Logo | Clean mark that matches the product brand |
| Website | Public product page with matching name and value prop |
| Support URL | Page or email where users can get help |
| Privacy policy | Public URL that matches actual data access |
| Terms URL | Public URL for usage terms |
| Auth details | OAuth, API key, workspace approval, or demo access |
| Demo credentials | If review needs a logged-in account |
| MCP server URL | If the plugin exposes server-backed tools |
| Tool metadata | Accurate names, descriptions, schemas, and permissions |
| Starter prompts | Real prompts users would ask |
| Test cases | Workflows reviewers can reproduce |
| Countries | Where the plugin should be available |
| Policy attestations | Safety, privacy, and compliance claims you can defend |
The product page is part of the submission story. If the website says "AI productivity for teams" and the plugin says "update healthcare billing records," the mismatch creates avoidable review risk.
Name the workflow, not the category
Weak plugin names sound like this:
- "CRM AI"
- "Docs Assistant"
- "Automate"
- "Best Sales Agent"
Better names tie the brand to a job:
- "Acme CRM customer lookup"
- "Northstar support ticket drafts"
- "LedgerOps invoice search"
- "Briefly meeting follow-up"
OpenAI's plugin guidelines say names and descriptions should be clear, accurate, and straightforward. They also warn against overly generic names unless tied to the brand.
A directory listing is not the place to be mysterious. The model, reviewer, admin, and end user all need the same thing: a clean description of what gets installed.
Tool descriptions decide whether users trust it
If your plugin includes an MCP server, do not mirror your internal API.
Bad:
| Tool | Problem |
|---|---|
query | Does not say what can be queried |
execute_action | Hides risk |
sync_everything | Too broad |
best_recommendation | Promotional and vague |
Better:
| Tool | Why it works |
|---|---|
search_accounts | Says what the tool retrieves |
draft_ticket_reply | Makes clear it drafts, not sends |
create_invoice_after_confirmation | Names the action and approval point |
get_subscription_status | Describes the output plainly |
OpenAI's guidance on defining tools says tool names should be human-readable, specific, and descriptive of what the tool does. Tool descriptions should explain purpose explicitly and accurately.
This helps the model call the right tool. It also helps buyers and admins decide whether the plugin belongs in their workspace.
Do not skip policy pages
Policy URLs feel boring until review or enterprise rollout blocks on them.
Your public pages should answer:
- What user data does the plugin access?
- Does it store prompts, files, or retrieved records?
- Who can revoke access?
- Are write actions logged?
- Is there a human confirmation step?
- What support channel handles account removal?
- Which company owns the plugin?
Keep these answers consistent across the plugin listing, SaaS homepage, privacy policy, and terms page.
Build a reviewer-friendly demo
A reviewer should be able to test the core workflow in minutes.
Good demo path:
- Install the plugin or connect the MCP server.
- Authenticate with demo credentials.
- Ask one starter prompt.
- See a safe read result.
- Try one write action that requires confirmation.
- Find the relevant support and policy links.
Bad demo path:
- Create a full production account.
- Import sample data manually.
- Guess which prompt works.
- Hit a write action with unclear scope.
- Email support for setup.
If the workflow cannot be demonstrated cleanly, the listing is probably too early.
Where IndieFame fits
IndieFame is not a replacement for the Plugin directory. It is the public SaaS context around it.
Use your IndieFame profile to clarify:
- Product name.
- Category.
- Buyer.
- Use case.
- Website.
- Pricing or offer.
- Screenshots and proof.
- FAQ.
Use the plugin listing to clarify:
- Installable workflow.
- Tools and permissions.
- Auth.
- Safety limits.
- Starter prompts.
- Review test path.
If the plugin includes a server-backed integration, use OpenAI's MCP documentation as the baseline for explaining what the server connects, what tools it exposes, and how users authorize access.
Those pages can link to each other cleanly. One explains the company and product. The other explains the installable ChatGPT or Codex capability.
Sources
- OpenAI Help Center: Plugins in ChatGPT and Codex
- OpenAI Developers: Submit plugins
- OpenAI Developers: Plugin guidelines
- OpenAI Developers: Building MCP servers for plugins and API integrations
- OpenAI Developers: Define tools
Submit your SaaS to IndieFame so your plugin has a public product page behind it.
Questions this article answers
These answers are visible on the page and mirrored in structured data.
What is the ChatGPT plugin directory in 2026?
OpenAI says the app directory moved to the Plugin directory on July 9, 2026. Plugins are used to discover workflow capabilities across ChatGPT and Codex.
What can an OpenAI plugin contain?
OpenAI documents plugins that can include skills, an MCP server, or both. Some plugins may also include app-style integrations or templates.
What should SaaS builders prepare before submitting a plugin?
Prepare listing copy, logo, category, website, support URL, privacy and terms URLs, auth details, MCP tool metadata, demo credentials if required, and test cases.
Is a plugin listing the same as a SaaS directory listing?
No. A SaaS directory listing explains the product. A plugin listing explains what workflow capability ChatGPT or Codex users can install and use.
Should I submit a plugin before my normal SaaS profile is clear?
Usually no. A clear product page helps reviewers and users understand the company behind the plugin.
Reviewed product pages can appear in IndieFame category pages, sitemaps, and the public LLM brief after approval.