8 October 2026

Submitting an MCP app to the Claude and ChatGPT directories

I submitted one MCP app to two directories on the same day. The app is Energy Figures: seven read-only tools over public data on Australian home batteries (rebates, advertised prices, installs by postcode) that answer with a small card inside the chat.

The Claude directory has a ten-step form. The ChatGPT directory has no form at all, just an upload box for a ZIP file. Neither was hard, but both had rules I only found out about by breaking them.

What each portal asks for

Claude’s portal is at claude.ai/directory/manage and needs a paid plan. On Team and Enterprise, only an Owner or a member with the Directory permission can submit, and the listing belongs to that organisation. The first question is whether you’re submitting an MCP connector or a plugin bundle. Anthropic says to submit a remote server as a connector, even if a plugin also uses it. A plugin needs a public GitHub repo and a human review for each version, so I skipped it.

Connectors get an automated scan and go up as “Community” by default. Anthropic may escalate one to Verified review, and there isn’t a published timeline. After publishing, you change tools by deploying your server. The tool names on the listing are listing text, though, so renaming one means a listing edit a reviewer approves. The slug is permanent.

ChatGPT’s portal at platform.openai.com/plugins takes a plugin ZIP and nothing else. Everything a reviewer reads lives in plugin.json: the listing copy, the category, your test cases and a link to a demo recording. When something is missing, you find out from an error message after uploading.

Tool descriptions can’t mention other tools

This was the one rule that made me change code. Claude’s compliance step has a required box saying tool descriptions contain no instructions about model behaviour or other tools, and the Software Directory Policy (section 2.D) says the same.

Two of my descriptions broke it. One said it took “a configuration id from find_battery”. Two tool results also suggested what to call next. I’d written them that way on purpose, because steering the model from one tool to the next is common advice and it works. For a directory listing, it’s not allowed.

The fix was to describe what each tool does and when it applies, and let the model work out the order. I deployed that, then checked the live tools/list response before ticking the box.

What needs to be live before you open the portal

Both portals ask for links, and a reviewer will open them. I had most of this, but not all of it:

• A docs page that lists what the app can look up and has a troubleshooting section, which policy 3.C asks for.
• A support address that actually delivers. I set one up with Cloudflare Email Routing just before submitting.
• A privacy policy with a section about the app itself.
• readOnlyHint: true on every tool, because Claude’s form checks your read/write answer against the annotations.
• A demo recording at a URL a reviewer can open, which ChatGPT requires.

Record the demo while you’re building, with the developer-mode connector you already test against. I left mine until ChatGPT asked for it, halfway through submitting.

Use cases that return a full answer today

Claude asks for up to three use cases with example prompts. Reviewers see them; the public listing doesn’t. Pick prompts that produce a complete result with the data you have right now. I dropped a price prompt for the Tesla Powerwall 3 because no shop was advertising one that week, and a reviewer would have opened an empty card.

Look at the real category list before you write anything. My prepared answer guessed “Reference”, “Lifestyle” and “Home”, and none of them exist. I chose Commerce & Shopping and Data & Analytics, and left out Financial Services so nobody would read rebate figures as financial advice.

Testing in claude.ai itself

I’d tested the card in Storybook against a Claude-like host and in the MCP Inspector. Adding the server to claude.ai as a custom connector found three more problems:

• Card buttons that send a prompt back into the chat trigger a red “Use caution before running this prompt” warning. I removed them.
• A transparent card looks unfinished on the chat background. It needs a surface painted from the host’s background colour variable.
• The connector icon comes from Google’s favicon cache for your domain, not from the icons your MCP server declares. Change the favicon days before you submit, not on the day.

Claude Code had its own surprise. It shows the model only the structuredContent of a result, never the text content. If the full answer only lives in the text, the model in Claude Code never sees it, so I put it in both.

ChatGPT’s errors, and what fixed them

Every ChatGPT problem showed up as an error after upload. In the order I hit them:

• “Extra inputs are not permitted” meant my test cases were under the wrong key. They go under review.test_cases.positive and .negative. An AI summary of the docs had given me a key that doesn’t exist, so read the raw reference table for key names.
• “Select a valid category” meant the value has to match a dashboard category title exactly. I couldn’t find an official list and pieced one together from another developer’s pull request.
• “Incomplete review information” meant the demo recording URL was missing. I recorded 73 seconds with the macOS screen recorder, compressed it to 1.9 MB and hosted it on the app’s own site rather than YouTube or Loom.
• After the first scan, 4 of my 7 tools said “This tool update needs further review before it can go live”. Clicking Rescan with no changes cleared all four.

Domain verification is a token from the portal that your server returns as plain text at /.well-known/openai-apps-challenge. I stored it as a Worker secret and added one route.

The reviewer test prompts needed one more change. In developer mode, starting a prompt with “Using Energy Figures,” didn’t make ChatGPT call the server. Ending it with “Use the energy_figures MCP.” did. I added that line to the reviewer prompts so a reviewer always reaches the tools, and left the public starter prompts in plain language.

The policy is a design spec

Very little of this was about the portals. Most of the time went on things the policy expects your server to do already: annotations that match what the tools do, descriptions that only describe their own tool, docs with a troubleshooting section and a card that looks finished in the real host.

Read the directory policies before you write your first tool description, not after. Servers that rely on descriptions telling the model which tool to call next will have to be rewritten before they can be listed, and as both directories fill up, I expect that rule to be checked automatically at scan time rather than left to a checkbox.