MCP Registry to Glama: How a Remote MCP Server Gets Listed

What happens after you publish a server.json to the MCP Registry, what Glama, PulseMCP and Smithery each read and test, and a measured look at EveryInfra's own Registry entry and Glama listing, with a publishing checklist and claim steps.

Co-branded card: EveryInfra × MCP Registry, Now in the MCP Registry

A remote MCP server gets into directories through one file: you publish a server.json to the MCP Registry (registry.modelcontextprotocol.io) with mcp-publisher, after proving you own its namespace. Directories such as Glama and PulseMCP pull from the Registry on a schedule, then connect to your server and test it themselves. We checked our own entry, io.github.xiaoxihexiaoyu/everyinfra, on October 21, 2026 (18:45–18:55 UTC) and several times on October 24, Singapore time. The latest Registry version is 1.1.1, published October 24 at 05:20 UTC, and 1.0.0 is marked deprecated. Glama built a connector page on its own. We claimed it on October 24 with a DNS record, and the page now shows "Ownership verified". On October 25 it read Healthy, 99.2% uptime over 48 days, and a tool definition quality score of A (3.9/5.0).

EveryInfra is a pay-per-call data API. One key covers 91 platforms, 426 data capabilities, 17 search tools and 52 CAPTCHA types, from $0.56 per 1,000 calls; failed and empty calls are not charged. This post covers publishing and listing only. For checking that a connected server really works, see remote MCP server setup for Claude, ChatGPT, and Cursor.

How an entry travels from server.json to directories

The Registry holds metadata, not code. It records a server's name, location and connection details and verifies that the publisher owns the namespace. Security scanning is left to package registries such as npm and PyPI and to downstream directories (Registry overview). Remote servers go under remotes, must be publicly reachable, and should use Streamable HTTP (remote servers).
The namespace decides how you prove ownership. io.github.username/server requires signing in as that GitHub user. com.example/server requires a DNS or HTTP challenge for example.com (Registry repository). A pull request to the registry repository publishes nothing; only mcp-publisher does.
Directories pull on their own schedule. The docs ask aggregators to pull "on a regular but infrequent basis (e.g., once per hour)" and store the data themselves. The Registry gives no uptime or durability guarantee (aggregator guide).
Published versions are immutable. Each version string must be unique, and neither it nor the other metadata can change after publishing. Only the status field can move to deprecated or deleted (versioning).

Screenshot of the MCP Registry docs page "Versioning Published MCP Servers": a sample server.json with version 1.0.0, followed by the sentence in the teal box: the version string must be unique for each publication, and once published, the version string and other metadata cannot be changed. — The MCP Registry versioning rule. The teal box: version strings must be unique, and nothing can be changed after publishing. MCP Registry docs: Versioning

EveryInfra's entry on October 24

Name: io.github.xiaoxihexiaoyu/everyinfra, title EveryInfra.
Versions: 1.1.1 (October 24, 05:20 UTC, active and marked latest), 1.1.0 (October 16, 01:49 UTC, active) and 1.0.0 (September 8, marked deprecated on October 24 with the note "Superseded by 1.1.1"). At the first check on October 22, the latest was still 1.1.0 and both published versions were active.
Description: 97 characters, naming 90 platforms plus RedNote, Douyin, TikTok and Amazon. The schema caps description at 100 characters (server.json schema), so only a few platform names fit.
Connection: one streamable-http remote at https://api.everyinfra.com/mcp, header Authorization: Bearer {api_key}, with api_key marked required and secret.
What 1.1.1 changed: only the website link, which now points to our MCP server page (the source file is the server.json in our plugin repository). The description is unchanged at 97 characters. We published it with mcp-publisher on October 24 and read it back from the Registry.
Glama: the connector page was generated from the Registry. We claimed it on October 24, and the page shows "Ownership verified". After claiming we added a description, a thumbnail and categories on Glama and turned on "Use Glama listing details as the source of truth". The Glama page therefore shows our longer Glama description (platforms, search tools, CAPTCHA types and starting price), not the 97-character Registry text. The publisher profile names EveryInfra as a first-party operator with website and docs links, plus a support email that only the Glama team sees.

Screenshot of the Server Details card on EveryInfra's Glama connector page. At the top is the longer description we wrote on Glama. One teal box holds the Ownership verified, Status Healthy, Uptime and Last Tested rows; a second teal box holds the TDQS grade A. — EveryInfra's Glama connector page, captured on October 25. The teal boxes mark the claim status, health check and tool definition quality score; these update daily; the screenshot shows the October 25 readings used in the text. Glama: EveryInfra connector page

Test log: the Registry, Glama and our own server

None of these checks cost anything. Unless marked as an October 24 recheck, they were run on October 22, Singapore time.

Registry keyword search for everyinfra took 14.16 s on one API version and 14.62 s on the other, and returned 2 version records.
Registry lookup by name with /v0.1/servers/{serverName}/versions/latest took 0.93 s and returned the full 1.1.0 server.json. If you integrate against one known server, look it up by name: it was about 15 times faster than search. Rechecking the same path on October 24 took 0.68 s, 0.93 s and 0.91 s over three requests, and it now returns the full 1.1.1 server.json.
Glama connector page. The description matches Registry 1.1.0 word for word. Uptime reads 99.1% over 44 days, and the last test reads 2026-10-21 16:38. Forty-four days back is September 8, the day 1.0.0 went into the Registry, so Glama started testing on publication day. October 24 recheck at 18:30 Singapore time: status Healthy, uptime 99.2% over 47 days, last test 2026-10-24 10:17 (the page gives no time zone). In the October 25 screenshot below: Healthy, uptime 99.2% over 48 days, last test 2026-10-25 19:50.
Glama's Tool Definition Quality Score (TDQS): A, 3.8/5.0 across 25 tools, scored 2026-10-21 12:30. The server-level grade covers disambiguation, naming consistency, tool count and completeness; each tool also gets its own grades, such as how well the description discloses behavior. October 24 recheck: still A. The score was 3.6/5.0 on 2026-10-23 10:55 and 3.7/5.0 after a new scoring run on 2026-10-24 08:45, then 3.9/5.0 on 2026-10-25 16:15 (screenshot below), still across 25 tools. The score moves over time, so date it when you quote it.
Glama's tool schema changelog lists 9 entries from October 9 to October 21. Each names the tool added or removed and the parameter text that changed. On October 24 at 18:30 it listed 11 entries. The 2 new ones are both from October 24: that day we changed the parameters and text of everyinfra_settings_update, and Glama logged it within hours. Glama compares the tool list on every successful inspection, so an edited description shows up there.
Our own server. Three tools/list requests without a key took 0.18–0.25 s and returned 25 tools. A data call without a key returned unauthorized in 0.18 s. Glama's FAQ calls this "open discovery with authenticated calls" and describes it as a common shape.
Directory sizes. On October 24 at 18:30, Glama's page titles showed 36,433 remote connectors and 109,495 open-source servers (Glama connectors), up from 35,071 and 108,270 on October 22. The LobeHub marketplace showed 112,261 MCP servers on October 22. The same server appears in many directories, so these numbers do not add up to a total.

Request	Time	Result
Registry keyword search for everyinfra (October 22)	14.16 s and 14.62 s on the two API versions	2 version records
Registry lookup by name, latest version (October 22)	0.93 s	Full 1.1.0 server.json
Same path, 3 requests on October 24	0.68 s, 0.93 s, 0.91 s	Full 1.1.1 server.json
Our server: 3 tools/list requests without a key	0.18–0.25 s	25 tools
Our server: a data call without a key	0.18 s	unauthorized

Publishing checklist

Write server.json. Use a reverse-DNS name with exactly one slash. Keep description and title at 100 characters or fewer. Put remote servers under remotes with type set to streamable-http. If calls need a key, declare the header name and a variable under headers, mark the variable isSecret: true, and set a placeholder that matches your own key format.
Install mcp-publisher and sign in. Follow the publishing quickstart, run mcp-publisher login github, and enter the code from your terminal in the browser. For a domain namespace, use the DNS or HTTP method instead.
Publish with mcp-publisher publish. A remote server needs no npm package first.
Check by name. Fetch the latest version as in test 2 and compare the version, description and headers with what you wrote.
Ship changes as new versions. Version strings cannot be reused. For metadata-only updates the docs recommend a prerelease version such as 1.1.0-1. Mark an outdated version as deprecated if needed. We did this on October 24, right after publishing 1.1.1: mcp-publisher status --status deprecated --message "Superseded by 1.1.1" io.github.xiaoxihexiaoyu/everyinfra 1.0.0. Read back from the Registry, 1.0.0 shows status deprecated with the message "Superseded by 1.1.1", 1.1.0 is still active, and 1.1.1 is latest. The command changes the status only; the version string and the other metadata stay as they were.
Claim the listing in each directory. Glama is below.

Claim a connector on Glama

From the Glama FAQ:

Open the connector page, choose Claim ownership and sign in.
Verify once. For io.github.username/…, link the matching GitHub user and choose Claim with GitHub; a GitHub organization namespace also needs the Glama GitHub App installed on that organization. You can also verify a domain: add a TXT record at _glama-claim.<domain> or publish the token at https://<domain>/.well-known/glama.json. We used DNS: a _glama-claim TXT record under api.everyinfra.com, the host in our server URL. After we chose Check DNS record, the page showed "Ownership verified". Glama checks the record again from time to time, so keep it after the claim.
After claiming you get health checks, analytics, thumbnails and categories. Name, description and URL still follow the Registry by default and are overwritten on each Registry update. To keep edits made on Glama, turn on "Use Glama listing details as the source of truth" under Manage connector. We turned it on: the Registry caps the description at 100 characters, and Glama lets you write more.
Decide whether you need a test profile. Until a test profile declares a method, Glama shows the connector as auth:none, and for open-discovery servers it asks you to declare what the calls need. EveryInfra lists its tools without a key, so we gave Glama no key: it connects, lists 25 tools and showed Healthy on October 24. Add a key only if you want Glama to run a real data call on a schedule; the cost is in the next sections.

What each directory reads from server.json

Glama syncs name, description and URL from the Registry by default; after you claim, you can make the Glama listing details win instead. Tool lists, uptime and quality scores come from its own connections to your server.
PulseMCP has paused new submissions and edits since September 3 and asks developers to publish to the Registry; it will pull entries when it reopens (PulseMCP submit page).
Smithery stops relaying requests on October 31 and remains a public directory; a curated set of verified servers will show the vendor's direct URL (Smithery announcement).
Client install helpers. The Registry docs say the Registry is meant for downstream directories, not for host applications; clients should read a subregistry that implements the same OpenAPI spec.

Illustration with two platforms. On the left, a filing cabinet holds a stack of identical metadata cards with small padlocks, and a directory board next to it copies one card; a clock face without numerals above it stands for scheduled pulls. On the right, the same directory board sends teal probe lines to a running server, which answers with a row of small tool blocks and a steady heartbeat line, and the board shows a grade badge with a check mark. — Left: the metadata a directory copies from the Registry. Right: what the directory measures by connecting to the server itself.

Your description and websiteUrl get copied word for word into many places, so write them with care. Tool lists and scores, though, depend on the server itself: clear tools/list descriptions do more than any directory copy. How we keep the advertised catalog in line with what actually runs is in reduce API docs drift with a live capability catalog.

Screenshot of a real tools/list request to https://api.everyinfra.com/mcp without a key and its response: 200 in 0.21 s with 25 tools; the first two, everyinfra_list_capabilities and everyinfra_call_api, are shown with name, title and a shortened description. Below, a call to everyinfra_call_api without a key returns isError true with the error code unauthorized. — Raw responses from our server without a key on October 25 at 19:57 Singapore time: listing tools is open (2 of 25 shown, descriptions shortened), data calls need a key. Remote MCP server

What listing costs

Publishing to the Registry and claiming on Glama are free.
Directory checks that only list tools cost nothing on EveryInfra.
If a directory's test profile calls the cheapest data capability once an hour, such as TikTok video search, that is 720 calls × $0.000556 = $0.40 a month. Give directories their own key, limited to the data product line with a per-minute cap. The spend is then easy to spot in your bill; prices are on the pricing page.

What changed in September and October 2026

October 31: Smithery ends its proxy and accounts and stays a public directory run by Arcade.dev (see the announcement above). Directories are splitting from transport: they help people find a server, and the connection goes straight to the vendor.
October 19: a RedMonk analyst wrote that the MCP Registry verifies who published a server, not what the server does. Directories such as Glama, PulseMCP and Smithery add whatever curation they choose (RedMonk). For publishers, the Registry is the start; the directory test results are what users see.
October 21, our observation: Glama graded EveryInfra's 25 tools and logs each change to tools and parameter text (tests 4 and 5 above).
September 12: a census of the whole Registry found 21,643 servers and 72,606 version records in an August 2026 snapshot. Among multi-version servers, 51.1% changed the tools they advertise between versions, 40.6% did so silently, and 4.2% moved their remote endpoint to a different host under the same name (arXiv 2609.14119). This is why published versions are immutable and why directories track tool changes.
September 3: PulseMCP paused listings and pointed developers to the Registry (see the submit page above).
Background: the August 22 MCP roadmap says the Server Card Working Group is defining .well-known metadata so a directory can read a server's description without connecting to it (MCP blog). For protocol changes, see MCP 2026-07-28 spec: what to verify before upgrading.

FAQ

Do I open a pull request on the MCP Registry GitHub repository to publish? No. The repository README says that adding a server.json, a server folder or a seed entry in a pull request will not publish your server, even if it is merged. Publish with mcp-publisher from your own project.

Who created my Glama listing, and do I need to submit again? Glama pulls servers from the Registry and builds connector pages automatically, so there is nothing to resubmit. To manage the name, thumbnail or test profile, claim it as described above.

Can I fix a typo in a published version? No. Publish a new version; once it is marked latest, most directories show it. Mark the old one as deprecated if you want (the exact command we used is in checklist step 5).