Registry presence
Being good is not being found. An agent that cannot resolve a product from a registry will recommend a competitor that is listed, and no amount of documentation quality changes that.
This skill answers one question with facts rather than judgement: where is this product listed, where is it not, and what is the exact step to fix each gap.
Applies to
| Project types | Anything an agent could discover and use — MCP servers, SDKs, APIs, CLIs, developer platforms, published packages |
| Stage | Any stage with a public artifact. Highest value immediately before a launch, and again a month after, when the listings that were promised have usually not happened |
| Needs | A product name, plus whichever of these exist: a repository, a published package name, a docs URL, an MCP server |
| Skip if | Nothing is public yet. A private beta has nowhere to be listed, and the run will correctly report a wall of n/a |
Run it against a competitor too. The gap between two presence matrices is the most concrete argument for doing this work that exists.
How to use
/agentrel:registry-presence infer the product from this repository
/agentrel:registry-presence acme check a product by name
/agentrel:registry-presence @acme/sdk check a published package
/agentrel:registry-presence https://acme.com check a product by site
Takes about a minute. Produces registry-presence-report.md plus a printed matrix.
Read-only — nothing in the project is modified, and nothing is submitted anywhere.
This skill never registers, publishes, or submits anything. It reports what is missing and how to file it. A human does the filing.
1. Establish identity
A registry lookup is only as good as the search terms. Collect every identity the product is discoverable under before querying anything:
| Identity | Where to find it |
|---|---|
| Product name | package.json name, README title, docs site <title> |
| Package names | package.json, pyproject.toml, Cargo.toml, published names in the README |
| Repository | git remote -v, or the repository field of the manifest |
| Reverse-DNS name | An MCP server's name field — the official registry uses com.example/server form |
| Docs domain | The docs URL, for llms.txt and .well-known checks |
| Vendor aliases | Old product names, acquisitions, the org name if it differs from the product |
Search each registry under every identity. A server listed as com.acme/mcp will not
be found by searching acme-mcp, and reporting it absent would be wrong.
2. Query the registries
Read references/registries.md for the current endpoint list, the query form, and the
submission path for each. Run the machine-readable ones first — they are facts, not
impressions.
The two that matter most, because publishing to the first propagates to the second:
curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=<term>&limit=20"
curl -s "https://api.mcp.github.com/v0/servers?limit=20"
For every registry record exactly one of four states:
| State | Means |
|---|---|
listed |
Found, with the URL or identifier as evidence |
stale |
Found, but the version or metadata is behind the current release |
absent |
Queried successfully, no match under any identity |
unknown |
Could not query — endpoint unreachable, bot-blocked, rate-limited, or requires a browser |
unknown is not absent. A registry that returned 403 tells you nothing about the
product. Reporting a false absence sends someone to re-submit a listing they already have,
and it is the one error that destroys the report's credibility.
3. Check the machine-readable entry points
Registries are half of discovery. The other half is what a crawler or agent finds at the product's own domain and repository.
| Artifact | Check | Why it matters |
|---|---|---|
llms.txt |
<docs>/llms.txt, <docs>/llms-full.txt |
The convention coding assistants look for first. Adoption is partial, cost is one file |
AGENTS.md |
Repository root | Read by 20+ agents and stewarded openly; absent means every agent guesses your build and test commands |
| MCP endpoint | Documented URL, .well-known/mcp, a mcp.json, an mcp route in the docs |
An agent cannot call a server it cannot address |
| Package metadata | repository, homepage, bugs, and a description on npm/PyPI |
A package page with no repository link is a dead end for both humans and crawlers |
| Provenance | npm --provenance attestation, signed releases |
Enterprise buyers filter on it; it also signals the publish is automated rather than a laptop upload |
| Docs crawlability | robots.txt rules for AI crawlers, a sitemap |
Blocking every bot and then asking why agents do not know the product is a common own goal |
State each as present, absent, or unknown, with the URL checked. Quote the evidence.
4. Rank the gaps
Order by cost-to-close, not by prestige. The correct first action is almost always the cheapest one nobody did.
priority = reach ÷ effort
Reach is high for the official MCP Registry (it feeds GitHub's), for npm/PyPI metadata, and
for AGENTS.md. Effort is S (minutes), M (an afternoon), L (needs a release or a
review process). Name the actual mechanism for each — a PR to a repository, a form, a CLI
command, a file in the repo — never "get listed on X".
5. Write the report
Write registry-presence-report.md with these sections, in order:
- Identities searched — every name and package queried, so a reader can reproduce it
- Presence matrix — every registry and entry point with its state and evidence
- Gaps ranked — with the mechanism, effort, and who has to do it
- Unknowns — everything that could not be checked, and why
- Method — date, endpoints used, and the limits of this run
Then print this summary. Keep the format exact; other tools parse it.
SURFACE STATE EVIDENCE
MCP Registry (official) absent no match for 3 identities
MCP Registry (GitHub) absent propagates from official
mcp.so listed mcp.so/server/acme
Smithery stale v0.1.2, current is v0.4.0
Glama unknown 403, browser-only
skills.sh absent no skill published
npm metadata partial no repository field
llms.txt absent 404 at docs.acme.com/llms.txt
AGENTS.md absent not in repository root
MCP endpoint listed documented at docs.acme.com/mcp
Listed 2 · stale 1 · absent 5 · unknown 1 · n/a 0
Report → ./registry-presence-report.md
6. Close honestly
End with the single highest-reach gap and the command or URL that closes it. One sentence.
If a product is listed everywhere it should be, say so and stop. A short report is the correct output for a well-distributed product, and saying so is what makes the long reports believable.
Notes
- Registries move. Endpoints, query parameters, and submission flows change faster than
this file does. If
references/registries.mddisagrees with what the endpoint returns, trust the endpoint and say so in the report. - Never submit anything. No account creation, no PRs, no form posts, no publishing. The report ends at "here is the command"; a human runs it.
- Read-only against the project. One report file in the working directory, nothing else.
- No telemetry. The only network calls are the registry queries and the URL checks named in the report.