# Registry Presence

> Check where a product is listed across the registries agents and coding tools actually resolve — the official MCP Registry, GitHub's MCP Registry, mcp.so, Smithery, Glama, skills.sh, npm, PyPI — and whether the machine-readable entry points a crawler expects are present: llms.txt, AGENTS.md, a documented MCP endpoint. Reports a presence matrix, the exact submission path for every gap, and never guesses: an unreachable registry is reported unknown, not absent. Use when asked whether a product is discoverable by AI agents or assistants, where to list an MCP server, why agents never recommend a product, or to audit agent-facing distribution before a launch.

- Skill: `agentrel/registry-presence` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add agentrel/registry-presence`
- Raw SKILL.md: https://api.skillmd.com/api/skills/agentrel/registry-presence/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: agentrel (https://skillmd.com/u/agentrel)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/agentrel/registry-presence

---


# 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:

```bash
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:

1. **Identities searched** — every name and package queried, so a reader can reproduce it
2. **Presence matrix** — every registry and entry point with its state and evidence
3. **Gaps ranked** — with the mechanism, effort, and who has to do it
4. **Unknowns** — everything that could not be checked, and why
5. **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.md` disagrees 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.