Skip to main content

Server Catalog

The catalog (CATALOG.md in the registry repo) is the full table of every manifest the registry tracks: 221 entries, mirroring Composio's toolkit list as a curated, lint-enforced set of MCP-server manifests.

:::warning All entries are planned Every catalog entry currently has status planned: its manifest is hand-curated and passes registryctl lint (schema, tier, credential-injection, and egress-denylist checks), but the server implementation is pending and the image digest is a placeholder. Placeholder digests are not installable. See the registry overview for how an entry becomes installable. :::

Table structure​

Each catalog row has five columns:

ColumnMeaning
NameThe server's unique name — also its tool-namespace prefix and its directory under manifests/
AuthCredential type the service requires: oauth2, api_key, basic, or none
Tiersealed or entrusted — where the real credential lives (see below)
EgressThe exact hosts the server may reach, e.g. api.linear.app or *.zendesk.com
StatusCurrently planned for all 221 entries

Catalog stats​

Counted from the current CATALOG.md:

DimensionBreakdown
Total entries221 (all planned)
Auth type111 api_key · 102 oauth2 · 7 basic · 1 none (Hacker News, public API)
Tier207 sealed · 14 entrusted

Auth types​

The auth column reflects the manifest's credentials[].type:

  • oauth2 — the user authorizes via the provider's OAuth flow; the gateway holds the token.
  • api_key — a static API key, stored in the gateway vault.
  • basic — HTTP Basic credentials.
  • none — public API; the manifest declares no credentials (e.g. hackernews).

Sealed vs. entrusted​

The tier determines whether the sandboxed server ever sees the real secret:

  • sealed (the default posture, 207 entries): the server receives only a placeholder token. The gateway's egress proxy injects the real credential into the configured header, and only on HTTPS requests to the manifest's allowlisted hosts. The server cannot exfiltrate a secret it never has.
  • entrusted (14 entries): the real secret is delivered to the sandbox via an environment variable. This tier exists only for services where header injection cannot work — for example, Alchemy embeds the API key in the request URL path (/v2/{apiKey}), so the proxy has nothing to rewrite. Entrusted servers still run inside the full sandbox and remain restricted to their egress allowlist.

The schema enforces the split mechanically: sealed manifests must declare header injection and no env injection; entrusted manifests must declare env injection only. See the manifest reference.

Egress allowlists​

Each entry lists the precise hosts the server may reach — typically one or two API hosts, sometimes an additional auth host (accounts.zoho.com, identity.xero.com). Wildcards are restricted to *.suffix entries whose suffix keeps at least two labels (*.atlassian.net is fine; *.net is rejected). Raw IPs, ports, paths, and entries matching the exfiltration denylist are rejected by lint. The semantics match the egress proxy's matcher exactly: case-insensitive exact host, or *.suffix matching true subdomains only.

Browsing the catalog​

The table is plain GitHub-flavored Markdown, so the simplest views are:

  • On GitHub: CATALOG.md — searchable in-page.
  • Locally:
# all entrusted-tier entries
grep '| entrusted |' CATALOG.md

# everything touching a given host
grep 'atlassian' CATALOG.md

For any entry, the authoritative details live in manifests/<name>/<version>.yaml — the catalog is a summary view of those files. To add an entry, see submitting a server.