Official MCP Registry
Publisher-submitted server metadata, packages and remote declarations. Membership is not proof that a server is maintained by the product it integrates.
OUR METHOD · BY THE APIDECK TEAM
How we build the MCP directory.
Where our listings come from, how we identify official servers, and what verification and testing actually cover.
Methodology updated . Individual records carry their own observation and review dates.
Where the listings come from
MCP Connect normalizes source metadata for the cloud catalog. API Tracker presents that catalog alongside reviewed publisher records. The directory credits the sources included in its current response; an SDK adapter does not mean a source is active here.
Glama
Remote connector listings and the source-code catalog are separate inputs. A repository listing need not declare a remote endpoint. Author claims and quality scores are preserved as source signals, not our verification.
Claude connector directory
MCP components from the public directory. Source tiers do not establish publisher affiliation or availability in other MCP clients.
Reviewed publisher records
Implementation-specific documentation, profile associations and setup requirements maintained in our cloud catalog. These can supplement registry coverage.
What “Official” means
Official identifies a publisher-maintained implementation supported by linked evidence and a review date. Evidence is bound to the specific implementation or connection, not every listing with the same product name.
- A publisher can operate several GitHub organizations. Organization ownership is useful evidence, but does not make every integration in those organizations official for the third-party product.
- Names, descriptions, stars, registry membership and upstream author flags are discovery signals, not approval.
- An official endpoint and a third-party wrapper can appear in the same candidate group. The wrapper does not inherit the official badge.
Automated repository checks prioritize review. They can miss packages in monorepos, nonstandard filenames and hosted successors. “Needs review” means evidence is incomplete, not that a server is unofficial or unsupported.
What we group, and what we count
Candidate grouping uses exact public endpoints, exact package sets or explicit reviewed identity bindings. Shared names or repositories alone do not merge implementations. Source credits and individual connection options remain inspectable.
- Source listings: records from included sources, with possible overlap.
- Candidate groups: grouped observations, not a census of unique products.
- Setup-eligible endpoints: connections that pass URL, transport and host-policy checks, not proven successful connections.
- Official implementations: reviewed implementation records. Multiple API profiles or endpoints do not automatically multiply this total.
Current directory coverage and dated growth observations show their units and sources. Listing growth does not measure users, revenue or adoption.
Documentation is not a live test
These evidence stages answer different questions. We do not claim every listing has passed them.
Source reviewed
Publisher documentation describes this implementation. This does not establish a working connection.
Setup available
A command or endpoint and setup requirements are recorded. Compatibility depends on the client and authentication.
Connection tested
A dated check completed MCP initialization for a specific connection. An HTTP response alone is not enough.
Tools discovered
A tools/list response was received. Discovery does not prove that any tool can execute successfully.
Tool execution tested
A specified tool ran with particular credentials and inputs. Other tools, permissions and accounts remain untested.
Security assessed
A named assessment has a scope, date and findings. Official status and successful connections are not security assessments.
What about Glama’s tests?
Glama describes sandbox builds, protocol discovery and behavioral analysis, plus scheduled checks of hosted connectors. Those are Glama’s reported processes. Ingesting a listing is not proof that we received a current, version-specific test result for it.
Security assessments are planned
Research into source coverage, API access and assessment reuse is on our roadmap. We do not currently turn source quality scores into security ratings. Future findings need a named source, scope, date and exact implementation binding. Missing evidence stays “Not assessed”; no findings does not certify safety.
Freshness, gaps and corrections
Source observation dates, publisher review dates and runtime check dates are distinct. A page refresh does not refresh its underlying evidence. Catalog updates require ingestion, validation and publication; we do not promise that every source updates at the same cadence.
Unknown authentication, missing endpoints and absent profile mappings remain unknown. Partial source fetches must not silently replace a complete snapshot. Historical research editions keep their original dates and counting methods.
API Tracker is built by the Apideck team. Spot a mismatch? Send a correction with the listing URL and publisher documentation. Evidence is reviewed before updating affiliation.