MCP Server & Agent-Skill Registry API
The MCP Server & Agent-Skill Registry API helps you discover and vet MCP servers and agent skills as clean JSON.
🤖 Using an AI assistant? Copy this link into ChatGPT / Claude / Cursor — it reads every endpoint and parameter instantly and tells you if this API fits your use case.
The primary search endpoint returns servers and skills with id, name, type, description, GitHub URL, license, version, transport, status and cross-registry sources, and you can pull a server or skill detail, security_signals, trending entries and the list of sources. It is built for AI-agent platforms and developer tools that need a searchable, security-aware index of the MCP ecosystem. One ReefAPI key, one shared credit pool, the standard envelope.
Where a row came from, and what that source can tell you
Rows from different registries are normalized into one shape but they are not equally complete, and the id prefix tells you which one you are looking at before you read anything else. Every row below was measured on 2026-08-27.
| id shape | Source | What it carries, and what it does not |
|---|---|---|
| github.com/owner/repo | Any source, once a GitHub repo is known | The canonical join key. This is the most reliable value to pass to server_detail |
| smithery:<qualifiedName> | Smithery | use_count, verified and score. github_url, license, version and status were all null on 8 of 8 rows |
| official:<io.github.Owner/name> | Official MCP Registry | version and status 'active', transport stdio or sse. metrics came back as an empty object |
| github.com/owner/repo, type skill | GitHub | license (MIT on all four measured), stars and forks, transport ['skill'] |
| transport values seen | Across all sources | http (Smithery), stdio and sse (Official), skill (GitHub skills) |
| source_health | Returned inside every search | official ok, smithery ok, glama http_401 on every call made |
| completeness_pct | Drops when a source is unreachable | 66.67 with source=all, 100.0 with source=official |
| license vs license_raw | repo_health separates the parsed value from the raw one | license null while license_raw read NOASSERTION on a repo with a non-standard license |
| cross_registry_count | How many registries list the same server, a corroboration signal | 1 on every search row measured, and 0 on a server_detail lookup |
| security_signals | Heuristics plus a disclaimer, never a certification | 2 signals, both severity 'info': no_clear_license and single_registry |
Six sources are declared by list_sources but only three were answering: Official, Smithery and the GitHub API. Glama returned http_401 on every call, PulseMCP is key-gated with its old endpoint retired, and MCP.so is listed as deferred. Read source_health on every response rather than assuming a quiet source means a small result.
Real request and response JSON
Captured from the indexed primary action, search, on .
{
"method": "POST",
"url": "https://api.reefapi.com/mcp-registry/v1/search",
"headers": {
"x-api-key": "$REEF_KEY",
"content-type": "application/json"
},
"body": {
"query": "filesystem",
"limit": 10
}
}{
"ok": true,
"meta": {
"api": "mcp-registry",
"endpoint": "search",
"mode": "live",
"latency_ms": 1953.6,
"record_count": 10,
"bytes": 0,
"cache_hit": false,
"completeness_pct": 100
},
"data": {
"query": "filesystem",
"type": "mcp",
"results": [
{
"id": "smithery:googledrive",
"name": "[redacted-name]",
"title": "Google Drive",
"type": "mcp",
"description": "Upload, organize, and share files in the cloud. Manage folders, set permissions, and search across stored documents.",
"github_url": null,
"license": null,
"version": null,
"transport": [
"http"
],
"status": null,
"updated_at": "[redacted-phone]T07:26:50.147Z",
"sources": [
"smithery"
],
"cross_registry_count": 1,
"source_urls": {
"smithery": "https://smithery.ai/servers/googledrive"
},
"metrics": {
"use_count": 15651,
"verified": true,
"score": 0.02857142857142857
}
},
{
"id": "smithery:one_drive",
"name": "[redacted-name]",
"title": "One drive",
"type": "mcp",
"description": "OneDrive is Microsoft’s cloud storage solution enabling users to store, sync, and share files across devices, offering offline access, real-time collaboration, and enterprise-grade security",
"github_url": null,
"license": null,
"version": null,
"transport": [
"http"
],
"status": null,
"updated_at": "[redacted-phone]T12:47:26.816Z",
"sources": [
"smithery"
],
"cross_registry_count": 1,
"source_urls": {
"smithery": "https://smithery.ai/servers/one_drive"
},
"metrics": {
"use_count": 1082,
"verified": true,
"score": 0.02564102564102564
}
},
{
"id": "smithery:dropbox",
"name": "Dropbox",
"title": "Dropbox",
"type": "mcp",
"description": "Store, sync, and share files across devices. Manage folders, control access permissions, and collaborate on documents.",
"github_url": null,
"license": null,
"version": null,
"transport": [
"http"
],
"status": null,
"updated_at": "[redacted-phone]T12:48:17.645Z",
"sources": [
"smithery"
],
"cross_registry_count": 1,
"source_urls": {
"smithery": "https://smithery.ai/servers/dropbox"
},
"metrics": {
"use_count": 274,
"verified": true,
"score": 0.027777777777777776
}
}
],
"total": 10,
"source_health": {
"official": "ok",
"glama": "ok",
"smithery": "ok"
}
}
}What the MCP Server & Agent-Skill Registry API does
| Action | Description | Concrete use case | Key params |
|---|---|---|---|
| search | Normalized cross-registry search over the Official MCP Registry, Glama and Smithery (and skills via GitHub). Dedups the same server across registries by canonical GitHub repo and returns cross-registry presence. | Platform and DevOps teams call search to get normalized cross-registry search over the Official MCP Registry, Glama and Smithery (and skil…. | query, type, source, sort, limit |
| server_detail | Full merged profile for one MCP server across every registry it appears in: manifest (tools/capabilities/transport), install paths (packages/remotes/connections), license, GitHub repo health, and cross-registry presence (how many registries list it = trust signal). | Security and supply-chain teams call server_detail to get full merged profile for one MCP server across every registry it appears in. | id, repo_health |
| skill_detail | Metadata for one agent-skill repo (GitHub-backed). Fetches the repo + its SKILL.md frontmatter (name/description/license) + repo health. | Developer-tool builders call skill_detail to get metadata for one agent-skill repo (GitHub-backed). | id |
| security_signals | HEURISTIC risk signals for an MCP server (NOT a safe/unsafe certification). Flags permission breadth (fs/network/exec), credential/env-var requests, repo health (archived/low-adoption), prompt-injection patterns in description/manifest, and corroboration (cross-registry presence). Always returns a disclaimer. | AI-agent developers call security_signals to get hEURISTIC risk signals for an MCP server (NOT a safe/unsafe certification). | id |
| trending | New / rising entries. MCP: most-used servers on Smithery + latest on the Official registry. Skills: recently-created GitHub skill repos. | Platform and DevOps teams call trending to get new / rising entries. | type, limit |
| list_sources | The registries this engine aggregates, their roles, auth status and live reachability. Free. | Security and supply-chain teams call list_sources to get the registries this engine aggregates, their roles, auth status and live reachability. | none |
Call search from your stack
curl -X POST https://api.reefapi.com/mcp-registry/v1/search \
-H "x-api-key: $REEF_KEY" \
-H "content-type: application/json" \
-d '{"query":"filesystem","limit":10}'import requests
r = requests.post(
"https://api.reefapi.com/mcp-registry/v1/search",
headers={"x-api-key": REEF_KEY},
json={
"query": "filesystem",
"limit": 10
},
)
print(r.json()["data"])const res = await fetch("https://api.reefapi.com/mcp-registry/v1/search", {
method: "POST",
headers: {
"x-api-key": process.env.REEF_KEY,
"content-type": "application/json",
},
body: JSON.stringify({
"query": "filesystem",
"limit": 10
}),
});
const { ok, data, meta, error } = await res.json();Ask your MCP-connected assistant: call reefapi.mcp-registry.search with {"query":"filesystem","limit":10}.Who uses this API and why
- AI-agent platforms call search to let users discover MCP servers by capability and transport.
- Security-conscious teams use security_signals to vet an MCP server before connecting it.
- Developer tools use trending and server_detail to surface and compare popular MCP servers.
Questions developers ask before integrating
Which registries are actually live right now?
Check source_health, which ships inside every search response rather than being something you have to ask for. On 2026-08-27 it read official ok, smithery ok, glama http_401, and completeness_pct fell to 66.67 as a result. list_sources reports the full roster with a reachable flag, including two that are declared but not serving: PulseMCP (its open endpoint retired, the current one key-gated) and MCP.so (deferred). A search that looks thin is often a source outage, not a thin ecosystem.
Why does searching for 'filesystem' return Google Drive and Cloudinary?
Because Smithery ranks semantically rather than by substring, and its rows dominate a default search by use_count. A query of 'filesystem' returned Google Drive (use_count 8,569), OneDrive (2,146) and Cloudinary (3), none of which contain the word. Set source to 'official' for a literal match: the same query against the Official registry alone returned com.pulsemcp/remote-filesystem, io.github.Digital-Defiance/mcp-filesystem and a chroot filesystem jail server, at completeness_pct 100.
Why is github_url null on so many rows?
Because Smithery does not publish a repository URL in its listing, and github_url is the key the deduplication uses to recognize the same server across registries. No repo URL means no join, which is why those rows come back with cross_registry_count 1 and sources ['smithery'] even for servers that plainly exist elsewhere. A null github_url is a limit of the upstream listing, not evidence that a server has no repository.
What does cross_registry_count mean, and why was it 0 on a lookup?
It counts how many of the aggregated registries list the same server, and it is meant as a corroboration signal: a server listed in three places has been through three sets of eyes. A server_detail lookup on github.com/modelcontextprotocol/servers returned sources [] and cross_registry_count 0 while repo_health filled in normally (89,889 stars, 549 open issues, not archived). That combination means the GitHub enrichment succeeded and no registry currently carries a matching entry under that repo URL, so read it as 'uncorroborated', not 'nonexistent'.
Is security_signals a safety check?
No, and it says so in a disclaimer returned with every call. It is a heuristic pass over public metadata and the tool manifest, flagging permission breadth, credential requests, repo health and cross-registry corroboration. Scanning the reference server repo produced exactly two signals, both severity 'info': no_clear_license and single_registry, with highest_severity 'info'. Zero signals is not a clean bill of health, and an info-level signal is not an accusation. Read the source before you hand any server your credentials or your filesystem.
Why is license null on a repo that clearly has one?
The parsed field and the raw field are kept apart on purpose. repo_health returns license null alongside license_raw NOASSERTION for the reference server repo, which is what GitHub reports when a repository's licensing does not resolve to a single recognized SPDX identifier, often because the license sits per-subdirectory. Skill rows behave differently: all four measured returned a clean MIT in `license`. Use license for filtering and license_raw when you need to know why the filter came up empty.
What does skill_detail add over a plain repo lookup?
It reads the SKILL.md frontmatter as well as the repo. On anthropics/skills it returned skill_md.found false with an empty frontmatter object, alongside a fully populated repo_health (171,816 stars, topics ['agent-skills'], default_branch main). found false means there is no SKILL.md at the repository root, which is normal for a monorepo holding many skills in subdirectories, and it is a signal about layout rather than a failure.
How does trending differ from search sorted by popularity?
trending states its own basis in the response: 'Smithery useCount + Official-registry active/latest'. It blends the most-used Smithery servers with the newest Official-registry entries rather than ranking one result set, so it surfaces both established servers (a search server at 87,579 uses, Gmail at 57,738, Google Sheets at 56,138) and freshly published ones with no usage history yet. Set type to 'skill' and it switches to recently created GitHub skill repositories instead.
What is the MCP Server & Agent-Skill Registry API?
MCP Server & Agent-Skill Registry API is a ReefAPI endpoint group for mcp server & agent-skill registry It returns live JSON through POST requests under /mcp-registry/v1.
Is the MCP Server & Agent-Skill Registry API free to try?
Yes. ReefAPI starts with 1,000 free credits, no card required. MCP Server & Agent-Skill Registry calls use the same shared credit balance as every other ReefAPI engine.
Do I need a MCP Server & Agent-Skill Registry login or account?
No login to MCP Server & Agent-Skill Registry is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.
How fresh is the MCP Server & Agent-Skill Registry data?
The page example is captured from a live search call, and production requests fetch live data through ReefAPI rather than a static sample.
How many credits does the MCP Server & Agent-Skill Registry API use?
MCP Server & Agent-Skill Registry actions currently cost 1-2 credits per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.
Can I call MCP Server & Agent-Skill Registry from an AI assistant or MCP client?
Yes. Connect ReefAPI once through MCP and your assistant can call mcp-registry actions with the same key, credit pool and JSON envelope used by normal REST requests.