Why a directory listing is distribution
A user who asks Claude Code or ChatGPT for a tool gets two or three names and expects to use one immediately. A directory listing turns that recommendation into an install with your skill attached, so the assistant already knows your workflow on the first call. It is the closest thing to an app store SaaS has had since Slack's, and most of the directories are still small enough that a well-made listing gets seen.
- Claude plugins: Claude Code and Cowork, automated review, updates mirror from your repo
- ChatGPT and Codex plugins: the largest audience and the strictest human review
- Cursor Marketplace: two-click install inside the editor your customers write code in
- xAI plugin marketplace: a pull request adding one SHA-pinned catalog entry, reviewed by xAI code owners
- The MCP Registry: no review, and the upstream that every other MCP directory syncs from
Build one source of truth first
Do not hand-write five manifests. Generate all of them from the definition your API already runs on. Our generator reads the operation registry and writes the OpenAPI spec, llms.txt, the CLI tool table, the skill, and the Claude, ChatGPT and Cursor plugin folders in one run, then a drift check in CI fails the build when any artifact is stale. A release bumps one version and every listing moves together.
- 1Write the skill once: the three or four workflows a customer actually runs, with the API reference as a side file
- 2Host one remote MCP server over streamable HTTP with OAuth 2.1, dynamic client registration and PKCE, plus an API key header for scripts
- 3Publish the local MCP server to npm so a plugin works on a fresh machine with npx
- 4Generate each directory's manifest from the same data and sync each plugin repo from CI
- 5Keep every plugin repo public with a LICENSE file: two of the five directories reject closed source
The order that wastes the least time
Each directory reuses the previous one's files, and the reviews get stricter as you go, so do them in this order and fix problems where they are cheapest.
- 1MCP Registry: npm publish with an mcpName, then mcp-publisher init, login and publish. Fifteen minutes, no review.
- 2Claude plugins: public repo, claude plugin validate, submit the repo link from the Console. Automated review.
- 3Cursor Marketplace: same skill, Cursor manifest, remote MCP. Submit the repo URL; a person reviews every version.
- 4xAI plugin marketplace: fork xai-org/plugin-marketplace, add your entry with a full commit SHA, regenerate the index, open the PR. The Claude plugin repo can be the source.
- 5ChatGPT and Codex plugins: verified identity, domain challenge, demo account, eight test cases, tool annotations. Budget a week.
What the reviews reject
Every rejection we saw was in the materials around the code, not the code. Prepare these before opening any submission form:
- A reviewer demo account that needs MFA, an email confirmation or a VPN. Make it plain login and keep it funded.
- Tool responses carrying internal ids, debug fields or secrets. Run each tool with a realistic prompt and read the JSON.
- A listing identity that does not match the verified organization: publisher name, website, support, privacy and terms must agree.
- A domain challenge token that is stale, or shared between two plugins on one host
- An icon over the size cap. ChatGPT's portal takes 10KB; a 256px PNG passes.
- Free-text inputs a model will send in prose. ChatGPT sent "English" where we expected an ISO code, and the reviewer's first run failed.
- Generic keywords in the xAI catalog entry. Words like video or api mis-fire the plugin suggestion and get pushed back; use your brand and the domains you own.
Test the whole OAuth round trip from a clean account in each assistant before you submit. Our first ChatGPT review died on a stale database index that broke token exchange, which no unit test would have caught.
Write the listing for the model, not the store
The description in a plugin directory is read by a person once and by the model on every call. Write the short description as the sentence you want the assistant to repeat, use the category words your buyers use, and give two starter prompts that show a real workflow end to end. Then say who the product is not for; a listing that overpromises gets uninstalled in the same chat it was installed in.
Measure installs like a channel
- Tag the OAuth client or API key each assistant creates, so signups and usage attribute to the directory
- Log which tools get called and which fail; a tool nobody calls is a skill sentence to rewrite
- Run five buyer prompts in each assistant monthly and note whether it suggests the plugin
- Watch the directory review inbox: the author email in the manifest is where update questions land
Key moves
0/8Reading is warm-up. Check these off as you actually ship them; progress saves in your browser.
See a finished listing set
Viraloop ships as a REST API, remote and local MCP servers, a CLI and a Claude skill, all generated from one registry. The agents page shows what that looks like from the outside.