On 30 September 2026 we submitted DialogBrain to Anthropic's connectors directory and it went live the same day. This is what the portal asks for, which rules quietly hold a submission, and why running every one of your own tools before you submit is the step that actually pays.
What a listing is, and what it is not
A connector listing puts your remote MCP server in the directory people browse inside Claude. They add it in one click, sign in with your OAuth, and your tools are in their conversation. It is not a plugin: a plugin is a bundle of skills and configuration that comes from a GitHub repository and is a separate submission. If you have both, you submit both.
The listing is published as a Community connector by default. An automated policy scan runs first; some submissions also get a human reviewer. Ours went from submitted to approved to published inside a day, but the portal says review can take weeks, so do not plan a launch around a date.
Everything below follows the portal at claude.ai/directory/manage, which any paid Claude plan can open.
Decide which tools you are submitting
This is the decision that matters, and it comes before the form. A reviewer reads every tool your listing exposes. Our full MCP catalogue carries raw SQL, a Python sandbox, an Android device farm and browser-session capture, all legitimate for the engineers who connect it themselves, and all wrong for a listing anyone can install. OpenAI had already rejected exactly that surface for the same reason.
So the server answers on two paths. The full catalogue stays where it was; a second path serves a curated set: read and answer conversations, search, contacts, tasks, notes, reminders, knowledge, agent drafts, call transcripts. The paths cannot be merged, because the resource value a client reads back from the protected-resource document has to be the URL it registered: one shared path breaks one of the two listings.
If your server was built for your own users, assume you will need this split. It is a dozen lines and it is the difference between a listing a reviewer can approve and a conversation about why you expose a SQL console.
# One tool set, one path per directory. The resource a client reads back
# must be the URL it registered, so the paths cannot be merged.
PROFILES = {"directory": DIRECTORY_TOOLS}
PROFILE_PATHS = {
"/mcp/chatgpt": "directory",
"/mcp/claude-directory": "directory",
}
Check the four things the portal reads automatically
Remote and reachable over HTTPS. A local server cannot be submitted on its own; it belongs in a plugin.
OAuth 2.0 with dynamic client registration, or no authentication at all for public data. The portal detects which you have. Ours advertises a registration endpoint in /.well-known/oauth-authorization-server, and the 401 your server returns without a token has to point at the protected-resource document for the exact path being submitted.
Every tool carries a title and the applicable readOnlyHint or destructiveHint. The portal flags the ones that do not, and a wrong label is a common rejection: anything that sends or deletes is destructive, anything that writes is not read-only.
Documentation URL, privacy policy URL, support contact and an icon. All four are public links a reviewer will open.
curl -i -X POST https://api.dialogbrain.com/mcp/claude-directory \
-H 'Content-Type: application/json' -d '{}'
# HTTP/2 401
# www-authenticate: Bearer error="invalid_token",
# resource_metadata="https://api.dialogbrain.com/
# .well-known/oauth-protected-resource/mcp/claude-directory"
Run every tool before you submit: this is where the bugs are
The portal asks you to confirm you have run each tool, and it is tempting to tick that box because the tools obviously work. We ran them instead: added the server as a custom connector in Claude, signed in as the reviewer account, and asked Claude to call each tool in turn and report the result. It took twenty minutes and found three real defects, two of which had been shipped for weeks.
A read tool that answered "agent_id is required. Pass it as a parameter when calling from MCP." A person asking "what reminders are set?" has no agent id and cannot get one, so that tool could not answer for anyone connecting over MCP. It had been in our ChatGPT listing since September.
A tool whose error message pointed at another tool the listing did not expose: files.read refuses a binary file and tells you to use files.get_base64, which was outside the curated set. The advice led nowhere and a customer's photo could not be opened.
A tool that reported success for work it had not done: removing a tag that was never on the conversation answered success: true, indistinguishable from a real removal.
None of these would have been caught by a reviewer in the first five minutes, and all three would have been found by a user in the first week. Twenty minutes of your own time is a cheap way to not learn about them from a stranger.
Call each of these tools exactly once, in order, and do not ask me
anything in between: workspace_current, channels_list, search_threads,
contacts_find, messages_read_history, tasks_create, tasks_update,
notes_save, reminder_set, reminder_list, reminder_cancel, files_read.
Then print one line per tool: the name, OK or FAILED, and for a failure
the exact error text.
The ten steps, and what each one actually wants
Connection. Paste the URL and authorise. The portal reads your tool list live. If your server hides tools for channels a workspace has not connected, the count here is what that account can see, not your full set: say so in the notes rather than letting a reviewer wonder.
Tools. Your tools and their annotations, synced from the live connection. Anything flagged here is fixed on your server, not in the form.
Listing. Name, slug, a one-liner up to 200 characters, a description up to 2,000, categories, documentation, privacy, support, icon. The slug is permanent once published: ours is dialogbrain, and that is the one field you cannot take back.
Use cases. Three things people will do, each with an example prompt, plus what they need before connecting, and whether the connector reads, writes, or both.
Company, Authentication, Data handling. Company name and a contact a reviewer can reach; the authentication mode, which is detected; and whether the API is your own, whether personal health data is involved, whether any content is sponsored.
Test & launch. Access instructions detailed enough for a reviewer to connect and run the tools: the URL, real credentials for a populated account, and what to try. Say plainly which tools reach real people: ours deliver messages to actual customers, so the instructions ask reviewers to read and not send.
Compliance. Seven acknowledgements, including prompt injection and conversation-data collection. Read them. If your product stores other people's private messages, as an inbox does, say so in the notes instead of hoping the checkbox covers it.
Review and submit. A summary and the button.
Two traps worth knowing
Reconnecting the server resets fields you already filled. We reconnected on the Connection step to pick up two newly added tools, and the portal silently put the listing name and slug back to the auto-derived api.dialogbrain.com and api-dialogbrain-com. The slug is permanent after publishing. Check the Listing step again after any reconnect.
A draft lives in the browser tab. The form says "Draft saved in this tab". Leave that tab and the draft is not in your submissions list; come back to the same tab and it is still there, on the step you left. Do not close it.
After it is live
The listing appears in the directory within about an hour, with Community and New badges. Health, rank and usage start about a day after the first calls.
Edits after publishing go through review before they replace what is live, so the listing you publish is the one people see for a while. Edits before publishing send the submission back to draft for another review, which is why, if you are staring at an approved submission and a small copy change, publish first and edit after.
Questions and answers
Do I need a separate submission for a plugin?
Yes. A connector is one remote MCP server submitted by URL. A plugin is a bundle of skills, commands and MCP configuration read from a GitHub repository, submitted as "Plugin bundle". If your plugin references a server you run, submit the server as a connector too.
Can I submit while another submission is in review?
Yes. Unlike Meta's app review, the portal is open for new submissions at any time, and an organisation can create up to ten in 24 hours.
What happens if a tool fails while a reviewer is testing?
It becomes a question you answer by email, and the listing waits. That is the argument for running every tool yourself first: a failure you find is a commit, a failure a reviewer finds is a week.
Does the listing cost anything?
No. Any paid Claude plan can submit, and a Community listing is free. What it costs you is the work of making the tool surface defensible.
Can I change the name or slug later?
The name follows the listing and can be edited through review. The slug is permanent once the listing is published, so decide it before you press publish.
Originally published at dialogbrain.com.
Top comments (1)
The "draft lives in the browser tab" trap is a good catch, thanks for writing that down.
One addition from the other side, since you mention that a local server can't be submitted on its own: we're on the Auten team and ship a local stdio MCP server, so we went the plugin-bundle route. A few things we hit while preparing it:
claude plugin validate(and--strict) locally before the portal does. It catches manifest mistakes in seconds..claude-plugin/marketplace.json, people can install it right away with/plugin marketplace add <owner>/<repo>, which is handy while a directory review is still pending.