DABYTE DATA DESK · standards

Two Glama listings, two schemas, one badge

Answer. A hosted MCP endpoint gets a Glama Connector listing, and a Connector has no score badge: on 2026-08-09 every badge path I tried under /mcp/connectors returned 404 — twenty probes across four of our own listings and four third-party ones — while the same path under /mcp/servers returned an SVG for every repository I tried. The badge exists only for a Server listing, which Glama builds from a public GitHub repository. That single asymmetry decides whether you can get into the awesome-mcp-servers README, because its gatekeeping workflow tests added lines for the literal string glama.ai/mcp/servers/ together with /badges/score.svg — a requirement that appears nowhere in that repository's CONTRIBUTING.md. And the two listing types read two different files, both named glama.json, whose maintainers fields are incompatible in both directions.

Published

Who reported it, and when we saw it

15 sources in our monitored set. First seen by us at 2026-08-09 14:59 UTC; our polling resolution is one hour, so this is when we observed it, not when it was published.
SourceLink
https://glama.ai/mcp/schemas/connector.json
https://glama.ai/mcp/schemas/server.json
https://github.com/punkpeye/awesome-mcp-servers/blob/main/CONTRIBUTING
https://github.com/punkpeye/awesome-mcp-servers/blob/main/.github/work
https://github.com/punkpeye/awesome-mcp-servers/pull/11577
https://glama.ai/mcp/methodology
https://glama.ai/mcp/attributes
https://glama.ai/mcp/connectors
https://github.com/glama-ai/tool-definition-quality-score
https://glama.ai/mcp/servers/creanlab/ai-visibility-index/score
https://glama.ai/mcp/connectors/ai.dabyte/visibility-index
https://glama.ai/mcp/connectors/ai.dabyte/dabyteai
https://registry.modelcontextprotocol.io/v0/servers?search=dabyte
https://modelcontextprotocol.io/registry/authentication
https://github.com/modelcontextprotocol/registry/discussions/11

Key facts

Two listing types, two URL shapes

Glama indexes MCP implementations twice over, in ways that look similar from the outside and behave differently. A Server listing is built from a public GitHub repository and lives at /mcp/servers/OWNER/REPO. Glama's methodology page states that each server is built from a Dockerfile, either authored by the maintainer and checked into the repository, or inferred by Glama's build system from the project structure. A Connector listing is a hosted endpoint that someone else already runs; the same page states that rather than building from source, Glama connects to the connector as an MCP client. It lives at /mcp/connectors/NAMESPACE/SLUG. The namespace in a connector URL tracks the official MCP registry rather than being freely chosen. The registry's authentication page states the rule in MUST terms: GitHub-based authentication requires a server name of the form io.github.username/*, and domain-based authentication requires the reverse-DNS form of your domain. So the authentication method you pick at first publish determines the namespace you get. The connectors index describes itself the same way in its own page metadata, as browsing MCP Connectors from the official MCP Registry. On 2026-08-09 the query https://registry.modelcontextprotocol.io/v0/servers?search=dabyte returned two records under ai.dabyte/visibility-index, version 1.0.1 marked active and isLatest, with a streamable-http remote pointing at https://dabyte.ai/mcp. The mapping is not uniform, and our own account is the counter-example. We have two connector listings per endpoint, not one. Both /mcp/connectors/ai.dabyte/visibility-index and /mcp/connectors/ai.dabyte/dabyteai return 200, both point at the same endpoint https://dabyte.ai/mcp, both read Ownership verified, and both showed a Tool Definition Quality Score of A at 4.9 out of 5.0 on 2026-08-09. The same duplication exists on our other domain, at ai.dablock/visibility-index and ai.dablock/dablockai. Only one of each pair matches a registry name: searching the registry for dabyteai and for dablockai returned zero records on 2026-08-09. Four live listings, two endpoints. One correction to something we assumed before checking: the two listing types do cross-reference each other. The raw HTML of the server page is 108,592 bytes and contains a Resources entry labelled Remote Server linking to /mcp/connectors/ai.dabyte/visibility-index — the registry-named connector, not the other one. What neither page says is that the Server listing is the thing the awesome-mcp-servers workflow requires. That is the gap that costs time, and it survives the grep.

The badge belongs to the listing type, not to the measured quality

The badge is an image endpoint under the listing URL. For a server it resolves: https://glama.ai/mcp/servers/creanlab/ai-visibility-index/badges/score.svg returned 200 with Content-Type image/svg+xml and cache-control max-age=300 on 2026-08-09, and so did the card variant at /badges/card.svg. This is not specific to our repository — three third-party controls returned 200 the same day: 21st-dev/magic-mcp, Metadrama/obscura-mcp and Pactlio-ai/pactlio-mcp. For a connector, nothing resolved. On 2026-08-09 I tried four paths — /badges/score.svg, /badges/card.svg, /badge and /score — against all four of our connector listings. All sixteen returned 404. To test whether that was something about our account, I ran /badges/score.svg against four third-party connectors: io.github.Creator-API/creator-api-mcp, com.pactlio/contracts, dev.jam.mcp/jam and ai.vortexiq/vortex-iq. All four returned 404 while their listing pages returned 200. Twenty probes, twenty 404s. The awesome-mcp-servers README is a larger sample of the same thing. Of its 3,375 entry lines, 1,993 carry a score badge, and every one of the 1,994 badge images on those lines resolves under /mcp/servers/. Not one points at /mcp/connectors/. Three entries mention a connector at all — Metadrama/obscura-mcp, Pactlio-ai/pactlio-mcp and joelgombin/andre-mcp — and each of them carries a servers-path badge image alongside. On the vendor side, https://glama.ai/mcp/attributes documents 102 attributes across categories, languages, capabilities, hosting, environment and author, and mentions no badge of any kind; the methodology page does not mention badges either. I found no Glama documentation stating the asymmetry in either direction. The part worth noticing is the inversion. The connector is the listing actually being exercised: on 2026-08-09 it showed a health line reading Healthy with a last-tested timestamp of 14:32, produced by calling the live endpoint. That endpoint answers a plain tools/list with five tools — get_visibility_index, get_brand_visibility, list_tracked_brands, get_history and get_methodology — each carrying an outputSchema and behavioural annotations. The badge, meanwhile, hangs off the repository-derived listing, whose score page describes the overall figure as Tool Definition Quality at 70 percent plus Server Coherence at 30 percent, graded A at 3.5 and above. A hosted endpoint can be measured continuously and still have no image to show for it.

The requirement is in CI, not in CONTRIBUTING

The awesome-mcp-servers contribution guide is 2,694 bytes. It asks for three things per entry: the server name linked to its repository, a brief description, and the right category in alphabetical order. It also documents an unusual rule — an automated agent can opt into a fast-tracked review by adding three robot emoji to the end of the pull request title. Checked on 2026-08-09, it contains the string badge zero times and the string glama zero times. There is no other document to have missed: the repository's .github directory contains nothing but a workflows folder. The actual gate is a single workflow file, .github/workflows/check-glama.yml, 15,798 bytes, triggered on pull_request_target. Line 112 reads: newAddedLines.some(line => line.includes('glama.ai/mcp/servers/') && line.includes('/badges/score.svg')). Only the first substring is specific to the servers path — /badges/score.svg would match any path — but the first is enough to make a connector URL fail. The workflow later extracts an owner and repository from the matched line with the regular expression /glama\.ai\/mcp\/servers\/([^/)\s]+\/[^/)\s]+)/, which is also servers-only. Note the .some(): the test runs across all newly added lines, not per line, so on a pull request adding several entries a single badge anywhere in the diff satisfies the gate. Two comments arrive in sequence, each tagged with an HTML marker so it posts only once. The first, marked glama-check, fires when no badge is found and asks you to list the server on Glama, noting that a Dockerfile is needed and that the check only requires the server to start and answer introspection. Its closing line suggests listing a hosted endpoint under /mcp/connectors as well — an addition, not a substitute. The second, marked glama-badge-check, fires once a badge string is present and asks you to confirm the server has an actual quality score. People who treat the first comment as the whole requirement stop one step early. The workflow contains no setFailed call. It adds and removes labels — has-glama or missing-glama, has-emoji or missing-emoji — and comments. Nothing turns red. The pull request simply does not move, which is a harder failure mode to diagnose than a failing check.

What our own pull request thread shows

We are the worked example here because the evidence is public and it is a failure of ours. Pull request 11577 against punkpeye/awesome-mcp-servers was created at 2026-08-05T17:13:12Z. The glama-check bot commented at 17:13:27Z, fifteen seconds later. At 18:08:40Z we replied that both of our endpoints were listed as connectors and that a hosted connector has no score badge, and asked whether that was acceptable. Being right about the mechanism did not advance anything: the bot state did not change on the strength of an explanation. What changed the state was building the other listing — publishing the repository with a Dockerfile in its root, getting the Server listing, and putting the resulting badge into the diff. The glama-badge-check comment posted at 22:01:39Z, just under five hours after the first bot comment, and the labels settled at has-glama, has-emoji and valid-name. The pull request was still open on 2026-08-09, four days after it was created. That is not evidence of anything wrong with it; the repository had about 92,000 stars and about 2,650 open pull requests that day. It is the reason not to attach a date to this kind of listing when someone asks you for one. The whole thread, both bot comments and both of our replies, is readable at github.com/punkpeye/awesome-mcp-servers/pull/11577.

Two files named glama.json, two incompatible schemas

Both listing types are configured by a file called glama.json, and the two files are not the same file. The connector file goes at /.well-known/glama.json on your own domain and declares the schema https://glama.ai/mcp/schemas/connector.json, which requires a maintainers array whose items are objects with an email field described as an email address associated with a Glama account. The server file goes in the repository root and declares https://glama.ai/mcp/schemas/server.json, which requires a maintainers array of plain strings described as GitHub usernames with permission to maintain the server. Both schemas are small — 438 and 345 bytes when fetched on 2026-08-09 — and both require exactly one property, maintainers. That is what makes the mistake easy: the required field has the same name in both, and only the item type differs. Validating each document against the other schema under Draft-07 fails in both directions, with the messages 'octocat' is not of type 'object' and {'email': '[email protected]'} is not of type 'string'. There is a second, duller trap in the repository half. The server file must be on the repository's default branch, and the default branch is not always main. Ours is master, so https://raw.githubusercontent.com/creanlab/ai-visibility-index/main/glama.json returned 404 on 2026-08-09 while the master path returned the file. If you are checking someone else's repository, read the default branch from the API first rather than assuming.

How to check yours before you promise anything

The decision comes before the work, not after. If the source is closed and only the endpoint is public, the Connector listing is the only one available, which means no badge, which means the awesome-mcp-servers route is closed unless you also publish a repository with a Dockerfile. That sequence is worth establishing before anyone hears a plan that depends on the last step. The same goes for the namespace: since the authentication method fixes it at first publish, choose between GitHub-based and domain-based authentication deliberately rather than discovering the consequence in a URL. Three checks take under a minute each. Request your badge URL and read the status code, not the page — that is the reproduce command for this article. Fetch both schemas and diff them before writing either glama.json, because the file will parse as JSON and serve 200 whichever schema you had in mind. And confirm the file is actually reachable after a deploy: a hand-placed file under /.well-known can be removed by an atomic release that replaces the site tree wholesale, which is why both of ours are emitted by the build rather than copied in by hand. On 2026-08-09 https://dabyte.ai/.well-known/glama.json returned 200 with the connector-shaped document. On resubmitting, we can only give you our own log rather than something you can check, and we are not a clean example. Our working notes dated 2026-08-06 record the connector card reading Verification claimed but not yet verified while the well-known file was live and correct; on 2026-08-09 the same cards read Ownership verified, with no second submission from us in between. That part argues for waiting out the re-crawl. But we now hold four connector listings for two endpoints, and we have not established how the extra pair arrived — the slugs dabyteai and dablockai match no registry record, so they did not come from registry ingestion, and we cannot prove from the outside whether they came from an earlier manual submission. Treat this as the honest version: waiting is still the right instinct, and we have a duplicate to clean up before we can claim we followed it.

Questions this answers

Can I get a Glama score badge for a hosted endpoint without publishing the source?

Not by any path I could find on 2026-08-09. Twenty connector badge probes returned 404 — four path variants against our four listings, plus /badges/score.svg against four third-party connectors whose pages return 200 — while server badges returned 200 for every repository I tried. Across the awesome-mcp-servers README, all 1,994 badge images point at the servers path and none at connectors. The connector still receives a graded quality score on its listing page; what it lacks is an image endpoint to embed. Glama could add one at any time, and its documentation does not describe the asymmetry either way.

Does a missing badge make the awesome-mcp-servers check fail?

No. The workflow at .github/workflows/check-glama.yml never calls setFailed; it posts a comment and swaps a missing-glama label for a has-glama one. There is no red X to notice, so the practical symptom is a pull request that sits without any visible objection. Note also that two bot comments come in sequence — glama-check, then glama-badge-check — and the second one asks for something the first did not.

Which glama.json goes where, and what happens if I swap them?

The connector file goes at /.well-known/glama.json on your domain and lists maintainers as objects with an email matching a Glama account. The server file goes in the repository root on the default branch and lists maintainers as GitHub username strings. Swapped, each document is invalid against the other schema under Draft-07, but the file still parses as JSON and still serves 200. I did not deliberately deploy a swapped file to watch what happens, so treat the consequence as inferred: the signal you would expect is simply that ownership never becomes verified.

Do I need the official MCP registry entry before the Glama connector?

The registry namespace is worth settling first regardless. The registry's authentication page states in MUST terms that GitHub-based authentication requires io.github.username/* and domain-based authentication requires the reverse-DNS form of your domain, so the method you choose at first publish fixes the namespace you get. Whether a name can later be renamed I could not establish: the authentication page does not mention renaming, and registry discussion 11 only proposes a per-server UUID so that renaming without losing version history would become possible. As of 2026-08-09 I found no documented rename path, which is not the same as confirming there is none. On the mapping itself, our registry-named connectors match their registry entries exactly, but we also hold two listings — dabyteai and dablockai — that match no registry record at all.

Machine access