DEV Community: Dialog Brain

How to publish an MCP server in the Claude connectors directory

Dialog Brain — Thu, 15 Oct 2026 07:58:41 +0000

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.

The call transfer that reported success and rang nobody

Dialog Brain — Wed, 02 Sep 2026 04:21:46 +0000

Our voice agents can hand a live phone call to a human. Getting there took two rewrites, and the first one shipped without ever delivering a single call — while our own logs said it worked. This is what the feature does now, and what the failure taught us.

What the caller hears

Someone asks to speak to a person, or the agent decides the question is not its own: a complaint, a payment, something outside its instructions. The agent says one short line, and from there the caller hears real ringing — the second number is being dialled.

When the phone is answered, the agent goes quiet. Two people are on the line and nothing else is on it with them. If nobody answers, nothing happens: the caller stays with the agent, which knows the dial failed and can offer a callback or take a message.

The route a transfer takes

A transfer here is not "hand the line to the carrier". It is a second call, dialled into the same conversation.

Is the number on the agent's approved list? If not, refused — and the agent is still on the line.
Is this a phone call at all? A messenger chat or a web voice widget has no second line to connect.
Dial the second number into the same call. The caller hears ringing; the agent is still there.
Did they pick up within 45 seconds? If not, the dial is cancelled and the caller stays with the agent.
They picked up — the agent loses the right to speak, and the two of them talk.

Both gates sit before anything is dialled, so a refusal never costs the caller a single ring. The pickup fork is the only place where a call becomes a transferred one.

Why not SIP REFER

Telephony has a cheaper way: a REFER, after which the carrier connects the two parties itself and you leave the call — the minutes stop flowing through you.

We built that first. It never delivered a call. Telnyx answered every REFER with 200 OK and did nothing: no progress NOTIFY, no ring at the destination. Meanwhile our own bookkeeping recorded outcome = transferred, so the dashboards were green while the caller was simply dropped.

The documentation explains it. REFER-based external transfer on a SIP trunk requires an active inbound call to your own number to match against, plus a Diversion header carrying that number. We were sending REFER on calls we originated — the one shape it cannot work on. And LiveKit's TransferSIPParticipant has no field for a custom header, so the requirement is unreachable from there anyway.

Two other explanations were tested and disproved rather than assumed: enabling third-party call control on the connection changed nothing, and neither did a sip: URI instead of tel:.

Three things measurement changed

Presence in the room is not a pickup signal. The dialled participant appears in the media room the moment dialling starts — measured at 310 ms, with no call at the destination. Only wait_until_answered tells you a human lifted the handset.

Removing the agent takes the call with it. Measured in isolation on a live call: RemoveParticipant, and within five seconds the room was empty, carrier leg included. The room does not outlive its agent job. So the agent is silenced, not removed.

Silencing alone is not enough. Revoking publish stops the agent being heard. Its job keeps running: nine seconds after one handover it composed and "spoke" a line that went into the call history, while it carried on transcribing two people who had just been handed to each other. It now gets an explicit stand-down.

The honest cost

Bridging means the conversation runs over our media path, and minutes are billed on both legs — exactly what a REFER avoids. In exchange it works identically on inbound and outbound calls, on any carrier, with nothing to configure on the telephony side.

If your logs can say "transferred" without anyone's phone ringing, that is the bug worth looking for first.

Originally published at dialogbrain.com, where the same piece has a flow diagram.