PublishLesson 4 of 9
How to submit an MCP server to directories
Every directory has its own application process. One is a web form, one is a developer portal with a review queue, one is a command-line tool and a domain check. Some you can fill in yourself in an afternoon; some need an engineer to put a file on the server or publish from a terminal. They all ask for roughly the same facts, under different names and limits, and they all reply on their own schedule, mostly by email, sometimes months later. This lesson is the process that keeps that manageable: one fact sheet, verification done early, a test account per submission, published policies, a status tracker, an inbox someone reads, and a server that stays up.
Collect every fact once: the submission fact sheet
Section titled “Collect every fact once: the submission fact sheet”Lesson 3 showed the forms. Look at them side by side and the same questions come back: a name, a one-line summary, a long description, categories, an icon, a privacy policy, a support contact, test credentials, example prompts. Only the field names and the character limits change. Claude takes a 2,000-character description, while Grok’s form stops at 600.
Keep one document per server with every fact any directory has asked for, and copy from it into each form. In SEO terms it is the NAP sheet of local SEO: the name, address and phone number you keep identical across every citation, because inconsistencies cost you. The fact sheet holds:
- Identity. Company legal name, website, the name of the server as users will see it, a short and a long description, categories, the icon in several sizes, brand color.
- Contacts. A support email, a primary contact for reviewers, a security contact. Use shared
addresses (
support@,partners@), never one person’s inbox. - Technical. The public MCP URL, how users sign in, the list of tools with what each does, rate limits.
- Links. Website, documentation, privacy policy, terms of service.
- Review material. Example prompts, positive and negative test cases (prompts the server should and should not handle), screenshots of widgets, a short demo video.
- Variants. Where a directory needs a shorter text, write the short version next to the long one and note which directory uses it.
Every time a new form asks something new, add it to the sheet. By the fifth directory you will copy almost everything.
Verification: who you are and what you own
Section titled “Verification: who you are and what you own”Before a directory reviews the server, it checks the submitter. Start these early: some take days, and some need an engineer.
| Directory | What is verified | Who can do it |
|---|---|---|
| ChatGPT | Individual or business verification of the OpenAI organization, then domain verification of the server | Owner, engineer |
| Claude | You submit from the claude.ai organization that will own the listing; on Team and Enterprise, an Owner | Owner |
| Gemini | Access to the Connected Apps preview, then a token file at /.well-known/google-connected-apps | Engineer |
| Muse | An account with a work email and business verification evidence | Owner |
| Grok | A work email and an organization handle; you accept Cursor’s Publisher Terms | Anyone |
| Perplexity | Nothing upfront: a Google Form, and the team contacts you if it is a fit | Anyone |
| Official MCP Registry | Namespace ownership: a GitHub login, or a DNS or HTTP check on your domain, from a command-line tool | Engineer |
Domain verification is the step that usually needs an engineer. The directory gives you a token, and the server has to serve it at a fixed path on the same hostname you submit. Ask for it on day one, together with the decision on that hostname: directories tie a listing to it, and a new hostname later means a new submission.
Publish the privacy policy and terms first
Section titled “Publish the privacy policy and terms first”Every review-based directory asks for a privacy policy URL, and ChatGPT, Gemini, Muse and Perplexity also want terms of service. They have to be live, public pages on the company’s domain before you submit, and they have to cover the MCP server: what data the tools receive, why, how long it is kept and who it is shared with. Muse goes further with a data processing questionnaire. A policy written for the website alone, or a link that redirects to a login page, is a common reason a submission comes back.
One test account per submission
Section titled “One test account per submission”Reviewers sign in and run every tool, so any server with sign-in needs test accounts that work on the first try:
- One account per directory. Name them so you can tell them apart (
mcp-review+chatgpt@…,mcp-review+claude@…). In the user admin, the account’s Last Login Date then tells you which reviewer has started testing, often weeks before any email arrives. - Realistic data, limited access. A reviewer should see what a real user sees, without real customers’ data and without the power to break anything.
- No MFA, one-time codes or magic links, which a reviewer cannot receive.
- Valid for the whole review. Not tied to an employee who might leave, or a trial that expires. Muse states this explicitly, and a review can take months.
- Free paths for paid actions. If a tool buys or books something, give the reviewer a way to test it without real charges.
Never put a production token or a personal password into a form.
Track every submission
Section titled “Track every submission”You will run several submissions at once, each at a different stage, for months. Keep a tracker (a spreadsheet is enough) with one row per directory:
| Column | Example |
|---|---|
| Directory | Claude |
| Status | Draft, Submitted, In review, Changes requested, Live |
| Submitted on | 2026-11-10 |
| Test account | mcp-review+claude@…, last login 2026-12-02 |
| Version sent | The tool list and descriptions as submitted (a copy or a date) |
| Last message | 2026-12-03, three issues ranked high, medium, low |
| Next step | Fix the high issue, reply to the reviewer |
| Listing URL | Filled in when it is live |
Some directories show a status in their portal (Claude: Draft, In review, Changes requested, Not approved, Approved, Published; Muse: risk assessment, tool review, end-to-end QA). Others show nothing: Perplexity and Grok publish no timeline and no status page. The tracker is the only place where all of them sit together.
Keep the “version sent” column honest. If the server’s tools or descriptions change after submission, the reviewed version no longer matches the live one, and directories can reject or remove a listing for that. Lesson 7 comes back to this, because improving a description on purpose has the same effect.
Read the inbox
Section titled “Read the inbox”Most directories reply by email: OpenAI sends review feedback by email, Anthropic emails the primary contact with issues ranked by severity, and Perplexity writes only if the connector is a fit. The exception is Muse, which says to check the portal because it does not answer status emails.
Make sure the contact addresses on every form go to an inbox that someone reads every day, check spam for the directories’ domains, and log every message in the tracker. A reviewer’s question left unanswered for two weeks can send the submission to the back of the queue.
Keep the server up
Section titled “Keep the server up”You do not know when a reviewer will test the server: tomorrow, or on a Sunday three months from now. If the server is down or a tool fails at that moment, the submission comes back and you wait for another turn. After launch, the same is true of every user. So from the day you submit:
- Monitor the server’s uptime from outside the company’s network, with an alert to someone who can act.
- Agree with the engineers that the submitted hostname, sign-in and tools do not change without a note in the tracker.
- Check the test accounts weekly: they still sign in, and their data is still there.
Lesson 5 covers uptime and the rest of what to watch once the server is live.
Brief for the engineer
Hi, we are submitting [the server] to the AI assistant directories (ChatGPT, Claude, Gemini and others). A few steps need you:
- The public URL. Confirm the hostname we will keep. Directories tie a listing to it, and a new hostname means a new submission.
- Domain verification. Directories give us a token to serve at a fixed path on that hostname,
for example
/.well-known/google-connected-appsfor Gemini or OpenAI’s token for ChatGPT. It must answer200directly, with no redirect. - Official MCP Registry. Publishing is done with the
mcp-publishercommand-line tool and aserver.json, under a GitHub or domain namespace. Can you own that step? - Test accounts. One per directory (
mcp-review+chatgpt@…,mcp-review+claude@…), with realistic sample data, limited access, no MFA, codes or magic links, valid for months, and a way to test paid actions without charges. We will watch their last login dates. - Tool metadata. Every tool has a title, a description that says what it does and when to use
it, and explicit
readOnlyHint,destructiveHintandopenWorldHintannotations. No parameter asks for credentials, chat history or precise location. - Stability and uptime. Uptime monitoring with alerts, and a note to us before any change to the hostname, sign-in, tools or descriptions, since the live server has to match what reviewers saw.
Your task
Section titled “Your task”Gold Keeper is a dummy MCP server, safe to experiment with: the prices are demo prices, nothing is traded, no money moves and it never asks for payment details.
Do this for the server you work on, or for Gold Keeper on paper, for two directories, say ChatGPT and Claude.
- Build the fact sheet. For Gold Keeper, work from lessons 1 and 2: four tools,
get_ratesopen to everyone with a rates widget,get_balance,buy_goldandsell_goldbehind sign-in. Write a name of 30 characters or fewer, a one-sentence summary under 80 characters, a description and three example prompts. - Write five positive and three negative test cases. A good negative case for Gold Keeper: “Give me investment advice on gold”, which no tool should handle.
- List the verification steps for both directories, and mark the ones that need an engineer.
- Check the privacy policy and terms of service: are they public, on the company’s domain, and do they mention the MCP server?
- Plan the test accounts: one per directory, with names, data and an owner. Gold Keeper’s
buy_goldneeds a free path, which its demo prices already give. - Set up the tracker with a row per directory and the columns above.
Check yourself
Section titled “Check yourself”Why keep one fact sheet when every directory has its own form?
Because the forms ask for the same facts under different names and limits. One sheet keeps the answers consistent across directories, like NAP data in local SEO, saves retyping, and gives you a record of exactly what each directory received.
Why one test account per directory instead of one shared demo account?
Separate accounts show you, through each account’s last login date, which reviewer has started testing, long before any email arrives. They also let you rotate or fix one account without breaking another directory’s review.
The engineers renamed a tool a month after the Claude submission. What do you do?
Log the change in the tracker, compare it with the version you submitted, and resubmit or update the listing. A live server that no longer matches what reviewers saw can get the submission rejected or the listing removed.