How to get an MCP server into the Claude directory: 20 days, €52/month, and everything the docs don't tell you

Petr Kushnir — Tue, 04 Aug 2026 12:54:32 +0000

I built a travel-logistics MCP connector — 6 tools (car rentals, airport transfers, tours, travel eSIM, luggage storage, flight compensation), 3 of them rendering MCP Apps widgets. Remote Streamable HTTP, no auth, solo project.

Four days from an empty repo to a submitted server, then twenty days of waiting: submitted to the Anthropic connector directory on July 10, approved on July 30.

When I was preparing the submission I found almost nothing written about the process. So here are the notes I wish I'd had — the actual gates, the undocumented caching rules that will burn you if you learn them late, and what the directory looks like from the publisher's side after you're in.

This is not a "what is MCP" article. It assumes you have a working server and are wondering whether to submit it.

The short version, if that's all you came for:

The submission portal needs a Team or Enterprise org. The minimum is 2 seats, not 5 — around €52/month.
No legal entity required. I submitted as an individual author.
20 days from submission to approval, zero pings from me. There is no published SLA.
Approval puts you in the Community tier by default, and there is no published path from there to Verified.
Your tool set freezes at connect time for everyone already connected. Descriptions stay editable forever; the tool list does not.
Connected from the directory, your tools arrive with "always allow" by default. Connected by URL, they don't. Same server.

The rest of this is how I learned each of those, and what it cost.

The one gate that costs money

The submission portal lives in the org admin settings, and it is only available to Team or Enterprise organizations. There is no individual path.

For a solo developer that means creating an organization and paying for a Team plan. The often-quoted minimum is 5 seats, which is what scared me off for weeks. It's wrong: the actual minimum is 2 seats — about €52/month including VAT.

That's the honest price of entry. Everything else in the process is free.

The question I could not answer before paying, and still can't: is that an entry fee or rent? Does an approved listing survive if you downgrade the org afterwards? I put that to the review team in writing on the day I submitted. A month later, no answer. Until someone demonstrates otherwise, budget it as a subscription for as long as you want the listing up — that's the assumption I'm running on.

(€52 is with my local VAT. Yours will differ; compare the pre-tax number.)

You do not need a legal entity. I submitted as an individual author, and the ownership question in the form is about your API relationships, not your corporate structure.

Timeline

July 10 — submitted through the admin portal.
July 30 — approved as a Community connector.
July 30, minutes later — published. Publishing after approval is self-serve: a Publish button, and the listing is live.

20 days, zero pings from my side. There is no published SLA; the official guidance is "expect weeks".

What the submission form actually checks

The form is 11 steps, and parts of it are enforced by machine before a human ever looks:

It connects to your server live. Mid-form, it hits your endpoint, counts your tools and resources, and verifies auth support. My submission showed "Tools: 6, Resources: 3, authless supported" — read back to me from my own live server. So your server must be up and correct while you fill in the form.

Missing annotations.title gets flagged immediately. I hadn't set titles on my tools. The form flagged it, I added them, redeployed, and re-ran the check inside the same session — it passed. Fix-and-retry works; you don't have to start over.

A public privacy policy and a landing page are required. Not optional, not "coming soon". Both get checked.

The API-ownership question is stricter than it looks. The options distinguish first-party APIs from APIs you legitimately proxy. My connector makes live calls to a partner's API under an affiliate agreement, so the honest answer was "we proxy a partner's API with permission" — and that was accepted without friction. Do not claim ownership you don't have; this is exactly the kind of thing a reviewer can check in a minute.

Reviewer instructions are your highest-leverage field. I supplied the exact prompts that trigger each tool, plus three negative prompts where the tools must stay silent. That turns an ambiguous review into a 10-minute checklist. I can't prove it sped anything up, but it costs nothing and it demonstrates that you know your own trigger surface.

The caching rule that will burn you

The one I most wish I'd known on day one, because it silently constrains your roadmap.

I found it the annoying way. I shipped a new tool, confirmed it in tools/list against my own production server, opened a fresh chat — and the client could not see it. Nothing was broken. The client was serving me a tool list it had cached when I first connected, days earlier.

A client caches your tool SET at connect time, and holds it until the user manually opens connector settings and hits "Refresh tools list". Not minutes. Indefinitely.

I mapped the boundary with five experiments over three days:

What changed	Reaches existing users without Refresh?
New tool added	No
Tool description edited	Yes — live
Widget UI metadata (`_meta.ui`) added to a tool	No
Widget HTML itself edited	No
Tool response content / logic	Yes — live

The mental model that survives all five: the interface is frozen at connect time; the behavior behind it is live.

All of that is observed client behaviour, tested in late July 2026. It isn't a documented contract, and it can change in any release — if it moves, I'll update this post.

Practical consequences:

Finalize your toolset before you distribute. Users who connected yesterday will not see the tool you ship tomorrow. Ever, unless they take a manual action they have no reason to take.
Polish your widgets before you distribute too. I assumed widget HTML was a live resource and could be improved after launch. It can't — I proved myself wrong with a padding fix that didn't arrive until Refresh.
Descriptions stay editable forever. That's a real escape hatch: tool descriptions are your trigger surface and your search index, and you can keep tuning them after launch.
If you ever need to restrict a tool's behavior, do it in the handler, not in metadata. Metadata is frozen per user; handler code runs on every call. Annotations declare; handlers enforce.

So when do you stop building and submit?

This is the question the cache rule forces on you, and it took me longer to answer than it should have. Two separate things get confused here, so let me split them.

Your server can change whenever you like. The listing points at a URL. Nobody re-approves your code. Ship fixes, swap data sources, rewrite handlers — none of it involves the directory.

Your interface effectively can't. Not because it's forbidden, but because of the cache: a tool added after distribution reaches only new connections. Everyone already connected keeps the surface they got on day one until they take a manual action they have no reason to take. So the practical answer isn't "freeze forever", it's: anything you add later serves only future users, never your existing base.

That reframes the stop-building decision. It isn't "is my product finished?" It's "is this surface wide enough that I'm happy serving it to whoever connects this month?" I ended up shipping all six verticals before submitting for exactly this reason — not because six was the right product, but because tools I added afterwards would have been invisible to the people who arrived first.

Your listing is a separate copy, and it never updates itself

I only found this by reading my own publisher settings carefully, weeks after the fact.

Your listing carries its own copy of your tool names. At submission the wizard probes your live server and records the tool names it finds. That list then sits in the listing as an editable field — and it does not follow your server. Ship a seventh tool and the listing still advertises six until you go and edit it, and that edit is reviewed before it goes live.

Why that matters more than it sounds: the settings page states plainly that those advertised names power connector suggestions. So the discovery surface reads your listing, not your server. A tool your listing doesn't advertise is invisible to suggestions even while your server serves it perfectly. Between the client-side cache and this, "add it later" is a considerably weaker option than it looks.

The rest of the edit rules, since they're inconsistent enough to be worth memorising:

Listing metadata (tagline, description, categories, links, icon): editable, reviewed before going live. I submitted a batch of these on a published listing and watched what happened: the state stays Published with a "pending changes in review" note beside it. Editing does not take you off the shelf.
Advertised tool and prompt names: editable, reviewed.
Testing instructions for reviewers: saved immediately, no review.
Use cases, data handling, compliance answers: locked permanently once published. Changing them means emailing the review team.
Display name: editable, but forces a full re-review and is flagged as affecting existing users. The slug never changes.

So the fields you should think hardest about before you submit aren't the ones you'd expect. Nobody warns you that the compliance answers are one-way.

The one thing on that page you can neither edit nor apply for is the Verified tier — more on that below.

Widgets do render — including on mobile

There was no clear answer anywhere on whether MCP Apps widgets from a third-party connector actually render in claude.ai, or whether that's reserved for first-party integrations. They render. Web and the mobile app both, with images loaded from an external domain declared via csp.resourceDomains, and a native "open external link" confirmation on button clicks.

" width="800" height="509">
One caveat: tools that render widgets get classified as interactive, which comes with an opt-in gate in the tool registry. For a user who already connected your server, this doesn't block the call — but it's an extra consideration if you're counting on discovery.

After approval: the two tiers

The directory is two-tier and this matters more than the badge suggests:

Community — passed automated checks. This is the default outcome.
Verified — manually reviewed by Anthropic, gets a checkmark.

There is no published process for going from Community to Verified — no criteria, no trigger, nothing to apply to. I asked support directly and was told the criteria aren't in their knowledge base either; I've since put the question to the review team and haven't heard back. If your plan depends on Verified arriving on a schedule, there is currently no schedule to depend on. If you know how it actually works, I'd genuinely like to hear it.

What I got wrong at first: I assumed the in-chat "Connectors that could help" suggestion panel was gated on Verified, because in my tests a Community-tier connector was ignored while three Verified ones were suggested. The documentation says otherwise — every directory entry is eligible, and ranking is usage-based. So it isn't a badge gate, it's a rank gate: a connector with near-zero usage sinks below the fold, verified or not. Same practical outcome on day one, completely different strategy: usage is the lever, not the badge.

The permission surprise

This is the single best argument for submitting that I have found nowhere in the docs.

When you connect a custom connector by URL, every tool defaults to "ask" — the user gets a permission prompt in every new chat until they manually flip it.

When you connect the same server from the directory listing, every tool arrives with "always allow" by default. Zero permission prompts. The UI groups tools by their annotations — "Read-only tools" and "Interactive tools" — each with its own three-way toggle.

Same code, same endpoint, same tools. The only difference is provenance. Directory approval is read by the client as trust in the server, and it removes the entire first-use friction step.

If you're weighing €52/month against "I can just give people a URL" — this is the thing that isn't in the spreadsheet.

The publisher dashboard, and what its fields actually mean

Published connectors get a metrics dashboard in the admin settings. It updates once a day, with up to 24h of lag, and it hides any window with fewer than 5 calls.

Four fields, and the first one is the trap:

Directory Rank. The tooltip is explicit: ranked by accounts that attempted to connect over the last 30 days. It measures connection attempts, not usage. Your rank moves when people click Connect, whether or not they ever call a tool.
Tool Call Users (30d). Distinct accounts that called something. This is your real user count, and it will be much smaller than you expect.
Tool Calls (30d) and Error Rate (30d). Self-explanatory.

Rank and health are computed on Anthropic's proxy, so only traffic flowing through Claude counts — which, as it turns out, is the opposite of the problem you have on your own server. More on that below.

I'm not quoting my own numbers yet. Five days after publishing is a point, not a curve, and a point tells you nothing except how impatient the author is.

What "visible" actually means

The dashboard shows you connections. It does not show you views, and those are very different quantities.

The submission form lets you supply a custom icon URL, and mine points at my own domain. Which means every time the directory renders my card, my own access log sees it happen.

I won't attach a figure, and I won't claim those are all humans looking at my card — a client prefetching the whole shelf produces the same log line, and I can't yet tell the two apart. But even if only a fraction of them are people, the count still sits orders of magnitude above anything in my connection numbers.

That's enough for the only conclusion I need from it: whatever is scarce for a new listing, it isn't exposure. The directory puts new entries in front of a lot of traffic. The scarce step is converting that into a Connect click — which means your icon, your name and your one-line tagline are doing more work on day one than every tool description combined. I spent days on the tools and about an hour on the tagline. Wrong ratio.

Go back and read your own listing settings

Publication feels like a finish line. It isn't, and here's the trap I walked into.

The publisher settings page has a block of optional fields marked as previously set only by the review team — author details, a plain-English permissions summary, integration snippets for API and Code users, a screenshot carousel where each image is paired with the prompt it demonstrates, and a checkbox declaring that your connector ships a visual UI.

Mine sat empty for three days after publishing and I never scrolled down to them. I only looked because I went hunting for an answer to a different question.

Two of those fields are pure copy-paste and took ten minutes. Here is exactly what went into mine, if it saves you the drafting.

Claude API — added to a Messages API request via the mcp_servers parameter (the MCP connector beta header is required):

{
  "type": "url",
  "url": "https://api.triplogistics.app/mcp",
  "name": "trip-logistics-assistant"
}

Claude Code — one line, no API key, since the server is public and read-only:

claude mcp add --transport http trip-logistics https://api.triplogistics.app/mcp

There's a related field just above them, "Works with", which drives the directory's own filters. If your listing claims the API and Claude Code as surfaces and these two boxes are empty, you've made the claim without shipping the instructions to act on it.

That last checkbox is the one worth checking today. Browse the directory and you'll see some cards carry an Interactive badge. Mine doesn't — despite the fact that every other surface recognises the server as interactive. The submission wizard's live probe counted my widgets ("Resources: 3"). The connector's own permission screen sorts my six tools into "Interactive tools (3)" and "Read-only tools (3)", read straight off the annotations my server serves. The client knows. The shelf doesn't.

So the badge is not derived from what your server declares. The obvious candidate is that unticked checkbox. I've ticked it; at the time of writing the change is still queued for review, so take it as a strong hypothesis rather than a proven mechanism. Either way it is not a verified-tier perk: community listings carry it too.

So: after you publish, go read every field in your own settings, including the ones below the fold. The directory keeps opening up controls that used to belong to the review team, and nobody sends you a note when it happens.

Four operational things nobody warns you about

Remember the proxy point from the dashboard section — this is its other half. Anthropic counts only what flows through Claude; your own server counts everything, and most of it isn't human.

Publish to the MCP Registry and a crawler swarm arrives. Within days I was taking roughly 2,000 requests/day to /mcp from scanners, scoring engines and indexers, hitting every few minutes and calling my tools with synthetic arguments across all six verticals at once. They create no load, but they poison your database: I had 861 recorded tool calls, almost all of them robots. Classify traffic by user-agent and source IP from day one, or your own usage numbers are a lie you tell yourself. After I added a classifier I could finally see that my first real external call was one request for an eSIM in Armenia.

All clients come from a shared pool of egress IPs. Every claude.ai user reaches you from the same handful of addresses, so an aggressive per-IP rate limit throttles real users rather than attackers. Set it generously and watch your 429 log for those ranges specifically. It also means an authless server cannot tell its users apart at all. That's a floor of the design, not a gap in your logging.

Implement a drain on SIGTERM. My first deploy during live traffic killed a tool call mid-flight. Now the server finishes in-flight requests before exiting. Every deploy would otherwise be a small outage for whoever is mid-conversation.

The slug is locked forever, and edits to a published listing go through re-review. Metadata edits (tagline, description, links, icon) queue as pending changes while your listing stays live; a name change forces a full re-review. Choose the slug like it's a domain.

What I'd do differently

Freeze the toolset earlier. I added two verticals late and had to re-verify everything under time pressure, purely because of the cache rule.
Build the bot filter before publishing, not after. Two weeks of metrics are unusable.
Not treat the badge as the goal. Usage drives rank, rank drives suggestions. Everything else is downstream.
Write the reviewer instructions first. Forcing yourself to list the exact prompts that must trigger each tool — and the ones that must not — is the best design review of your tool descriptions you'll get. Two of my descriptions changed as a result.

One limit on all of the above

I was approved on the first attempt, so everything here is the happy path. I don't know what a rejection looks like: how it's communicated, how specific the feedback is, or how much of a resubmission you'd have to redo. If you've been through that side of it, I'd rather link to your write-up than guess.

Why it's still worth doing

A few hundred connectors are listed, against thousands of MCP servers in the wild. The review queue is the bottleneck, and that asymmetry works for anyone willing to sit in it. When I checked my own categories before submitting, several returned no results at all.

I'll post the follow-up at the end of August: the curve instead of the point, including what happens when a listing falls off the "New" shelf, which nobody has written about.

The connector, if you want to see what got approved: search "trip logistics" in the Claude directory, or triplogistics.app. Disclosure: booking links in the connector are affiliate links — stated on the listing and on the site.

I'm also thinking about doing this for other people — not the knowledge, that's all above and it's free, but the hands: reviewing your server and your submission before you send it so you pass on the first attempt. If that would be useful, say so in the comments; I'm gauging whether it's worth building.

And if you're going through submission and hit something I didn't cover — ask. I'll answer, and fold the corrections back into this post.

DEV Community: Petr Kushnir