The Save button did nothing. We opened the network panel. The request had returned HTTP 200.
Inside the response: a validation error on a field the form did not show.
By then we had spent several days trying to get the same remote MCP server listed across directories. Another directory had published us in about ten minutes. A GitHub list had tested our endpoint and accepted its 401. Elsewhere, our submission was waiting for a human.
"Get the server listed" had turned into a collection of different jobs.
One line of context so you know where I stand: I run engineering at GoodBarber, an app platform, and our MCP server lets assistants manage the apps through an authenticated connection. It is hosted, it requires OAuth, and there is no public server code for a directory to scan: our public repository holds skills and client configuration. That distinction decided which submission paths worked.
After getting the server into ChatGPT's plugin directory, we widened the search. What follows happened between September 7 and 14, and every public state was checked again on September 14. The delays are the ones our submissions went through, not a promise from anyone.
The official MCP Registry: publish the identity first
The official MCP Registry accepts metadata for hosted servers, closed-source implementations included, as long as the server is publicly reachable. It authenticates the publisher's namespace and validates the metadata. Beyond that, its metadata is deliberately unopinionated, and curation is left to the aggregators downstream.
Our entry, dev.goodbarber/goodbarber-public-mcp, has been there since April 28 (version 1.0.0). On September 7 we published version 1.2.1, with DNS authentication: it declares streamable-http, the remote endpoint and the product page. On September 14 the registry API still marked it active and latest.
We would do this first again. It gives importers a stable identity and a record to consume, instead of asking each directory to rebuild the product from a README.
Glama had already imported a connector entry from that record. We claimed it, and on September 8 it displayed "Ownership verified" and "Healthy". Both were still there on September 14.
Upstream publication does not tell you when the downstream pages will exist. MCP.Directory says it auto-discovers servers from the official registry, where our entry has been since April. Its submission form promises a review within 24 hours, and its first, required field is a GitHub repository, from which it detects the tools by analyzing the server's implementation. The Knights Who Say Ni wanted a shrubbery; a hosted server with no public code has no repository to give. On September 14, MCP.Directory's sitemap still had no GoodBarber URL, six days after a server listing request and five skill submissions. Where those submissions sit, we do not know.
awesome-remote-mcp-servers: the CI that accepts a 401
awesome-remote-mcp-servers is built for our shape of product. It only lists servers the provider hosts: reachable at a public URL, usable by anyone who can sign up, speaking Streamable HTTP or SSE. Each entry's name links to the product's homepage, not to a GitHub repository, because the endpoint is the thing being listed. The list was created on September 8, and our PR went in the same morning.
It also gave us something we could test. Its submission workflow at the merge commit probes each endpoint with a real initialize handshake and sends no credentials. We replayed the check before submitting. Our endpoint answered with an authentication challenge, structurally like this (generic domain):
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"
The workflow takes a 401 or a 403 as a live endpoint that requires authentication, and reads the WWW-Authenticate header to choose between the OAuth and API-key markers. Our 401 passed with the OAuth marker. The probe never completes OAuth and never calls a tool: a green check here means the door exists.
Two more rules matter before you open the PR. Every entry needs a Glama connector badge, and CI checks that the connector exists. And the contribution rules document a fast track for automated agents: three robot emoji at the end of the PR title. Our PR was prepared by an agent, so we used it. PR #4 was opened at 07:23 UTC, labeled endpoint-ok and has-connector by CI nine seconds later, and merged at 13:50 UTC, on September 8.
Then the bot ran again on the merged PR. It added duplicate and missing-connector, removed has-connector, and asked us to remove the duplicate entry. The duplicate was ours: the check was now reading the list it had just merged. The README on the main branch settled what the labels could not.
Gemini CLI and GitHub: a crawler versus a review queue
The Gemini CLI gallery instructions describe a daily crawl of public GitHub repositories carrying the gemini-cli-extension topic. A gemini-extension.json manifest at the root of the repository supplies the metadata, and an extension appears in the gallery only if it passes validation. The instructions say there is no issue to file and no email to send.
We added the topic on September 9. On September 14 the topic and the manifest were in place, and the gallery page had no GoodBarber entry. A daily crawl gives no per-repository result, so we cannot tell whether we failed validation or were never picked up.
GitHub's MCP gallery has another gate. In discussion #1257, a GitHub answer explains that onboarding a new server is a manual curation process, and that new registry versions sync once a server has been onboarded. We asked to be included on September 8; on September 14 the expected gallery URL still returned 404. Republishing the registry record would change nothing there.
Our Claude Code plugin sits in a similar waiting room. Plugins are submitted through a form, and the public community marketplace catalogue is a read-only mirror, synced nightly from Anthropic's review pipeline, of the plugins that passed automated security scanning and were approved. Ours was submitted on September 7, shown as awaiting review on September 8, and still absent from that catalogue on September 14.
Claude connectors: ten minutes, then an inventory problem
The Claude connectors directory is a different destination from the Claude Code plugin marketplace. Remote servers are submitted from an organization's admin settings, through a portal that connects to the server. Our connector listing appeared about ten minutes after we submitted it on September 8, while the plugin was still waiting. Its tier is community, and that is the word we use.
Then we read the published inventory and found our own mistake. The directory's public record listed 120 tool names and left out an entire tool family, the one behind push notifications and analytics, while the description we wrote advertised both. The portal syncs the tool list from the server through the connection made at submission, and our connection did not expose that family. The description is ours to edit from the dashboard; the tool list is not an editable field, and changing it goes through the review team. Either way, the fix is ours.
For someone following the Claude connection guide, the only question that matters is whether the tools they get cover the task they came for. A directory listing does not change the tools a connection exposes, so the check we owe that reader goes beyond the listing: the published inventory against the description, then a real connection.
mcp.so: HTTP 200, application-level failure
The Save button from the opening was on mcp.so. We were updating an existing listing whose transport and overview had gone stale.
On September 8 the edit request returned HTTP 200, and its body carried application code -1, an "Invalid submission" message and a validation error under fieldErrors.tagline. The old tagline was too long. The form had no field to fix it and showed no error.
We sent the edit again with a shorter tagline, then read the public page, because a save response is a claim, not a result. On September 14 the listing showed Streamable HTTP, OAuth and the updated overview.
If that sounds familiar, it is the write-safety piece in miniature, with a web form in place of an agent. The green request in the network panel meant an HTTP exchange had completed, nothing more. Read the body, then read the page.
MCP Market: fast, paid, and one button to check
On September 8 we paid $69 for the remote-server "Official" listing option, which is a different product from the GitHub-repository submission. The listing was live the next morning, inside the advertised 24 hours, with the badge and the categories we asked for.
Search MCP Market for GoodBarber and a second card shows up next to ours: GoodBarber Skills, filed under Marketing Automation.
Then we clicked Try Now.
We had submitted our MCP product page as the destination. The published button led to our app-creation page, with MCP Market campaign parameters added, and still did on September 14. Both pages are ours, and it matters anyway: someone looking for connection instructions lands on a different step of the product journey.
Paying got the listing published fast. Checking where it sends people stayed our job.
Smithery and skills.sh: read what the signal measures
On Smithery, verification happens in the server's settings, through what its publishing guide calls an automatic official-vendor verification checklist. Our domain and backlink proofs passed their recheck on September 8. The public data embedded in the listing page said verified: false afterwards, and still did on September 14. The guide names the checklist without listing its items, and nothing we could see explains the step between two passed proofs and a false flag. We write down both states rather than calling the whole thing verified.
skills.sh showed our 44 skills on September 14, with installation counts. There is nothing to submit there: skills appear through the anonymous install telemetry of its CLI, when people run npx skills add. Those skills are instruction packages for using the server, and the counter measures installs: not a completed workflow, and not an OAuth flow that works in every client.
The September 14 snapshot
Every state below was checked on September 14, 2026; submission and publication dates are the real ones. Read "pending" as pending, and "absent" as unexplained.
| Directory or catalogue | Admission mechanism | Observed delay | State on September 14 | Pitfall |
|---|---|---|---|---|
| Official MCP Registry | Namespace authentication, metadata validation | Entry since April 28; 1.2.1 on September 7 | Version 1.2.1 active and latest | Curation is left to aggregators |
| Glama | Registry import, ownership claim, health checks | Initial import not timed | Ownership verified; Healthy | Ownership and health are separate signals |
| awesome-remote-mcp-servers | Endpoint CI without credentials, Glama connector badge, PR | Same day, September 8 | PR #4 merged | The probe stops at the 401 |
| MCP.Directory | Registry auto-discovery; GitHub-based form with a 24-hour review promise | September 8 to 14, unresolved | No GoodBarber URL in sitemap | The form expects a GitHub repository |
| Gemini CLI gallery | Topic crawl, root manifest, validation | September 9 to 14, unresolved | No entry on the gallery page | A daily crawl gives no per-repo result |
| GitHub MCP gallery | Manual curation, then version sync | September 8 to 14, unresolved | Expected URL returns 404 | Registry publication does not grant admission |
| Claude Code community marketplace | Submission form, security scan, approval, nightly mirror | September 7 to 14, unpublished | Absent from public catalogue | Separate from the connectors directory |
| Claude connectors directory | Admin portal; tools synced from the connected server | About 10 minutes, September 8 | Community listing; 120 declared tools, no push or analytics | The synced tools did not match our description |
| mcp.so | Authenticated form and API validation | Update completed September 8 | Corrected transport and overview live | HTTP 200 carried a validation failure |
| MCP Market | Paid remote-server submission | Live the next morning, September 9 | Official listing live; a GoodBarber Skills card also listed | Try Now destination changed |
| Smithery | Official-vendor verification checklist | Proofs passed September 8 | Public data still says verified: false
|
Passed proofs did not flip the public flag |
| skills.sh | No submission; CLI install telemetry | First install not timed | 44 skills listed | Installs are not workflow success |
| Docker MCP Catalog | Remote-server PR, Docker team review, test credentials by form | Open since September 8 | PR #4968 open; 0 comments | Review outcome unknown |
| VoltAgent skills list | Skills-list PR; rules require real community usage | September 8 to 14 | PR #1031 closed without merge or comment | Adoption comes before the listing |
| BehiSecc skills list | Skills-list PR | Open since September 8 | PR #689 open; 0 comments | Skills listings have their own review |
| Cline marketplace | Submission issue; review of adoption, credibility, maturity, security | Open since September 9 | Issue #2492 open; 0 comments | Review weighs community adoption |
The order we would follow next time
Start with the official registry, and with one description, one endpoint, one product page and one documentation URL, the same everywhere. Separate the hosted server from the skills package before choosing routes: some submission forms start with a GitHub repository, and a hosted server has nothing to put in that field.
Then read each gate before you submit. Replay public CI checks. If an agent prepares the PR, use the documented agent fast track. For a crawler, check the topic and the manifest. For a curated catalogue, read the acceptance criteria first, since some weigh community adoption, then keep the submission reference and wait for evidence of admission.
After publication, read what went live: the tool inventory, the authentication metadata, every destination link. Keep dates next to results and recheck weekly. The merged PR, the badge and the live page can tell three different stories.
All of it points to one page, the connection guide. If you are connecting GoodBarber to an assistant, start there.
One more thing: that was a dense week, and these procedures move fast. What you read above comes from each directory's own documentation where it has one, and from what we saw on the forms otherwise, checked on September 14. If you run one of these directories and something here is wrong, or already out of date, tell us in the comments.
Which check caught a mismatch in your own listing: the response body, the tool inventory, or the link after publication? Genuinely curious.
Top comments (0)