Methodology

Evidence tiers

Every claim is labelled with where it came from, and the labels are visible on the page — a fact we read off a registry field is not the same kind of fact as one we observed on the wire.

Where a vendor’s documentation and our observation disagree, we show both rather than picking a winner.

Terminology

MCP server

A service exposing tools, resources or prompts over the Model Context Protocol, so an AI client can call them.

Vendor-published

The publisher proved control of the domain in the server's registry namespace, and we independently confirmed the server's endpoint or website is on that same domain.

Community

Published under a namespace that requires only a free account, with no domain control demonstrated.

Supported

A named source positively asserts this. The source and date are shown.

Unsupported

A named source positively asserts the absence — for example a scope that is not in an enumerated scopes_supported list. This is never inferred from silence.

Unknown

We found no source either way. This says nothing about the product; it is a gap in what is published.

The curation gate

Most of the registry is not evaluable. We exclude by measurable shape rather than by a hand-maintained blocklist, so the rules keep working as publishers change names:

• Namespace density — many servers from one publisher who has not proved domain control.
• Templated descriptions — near-identical descriptions clustered across the whole corpus, not just within one publisher. This is the rule that still works when someone spreads servers across fresh accounts.
• Name templating — mechanically generated names within a publisher.
• Repository concentration — many servers sharing one repository, or having none.
• Publish bursts — large numbers of servers registered within 24 hours.

Density is only applied to publishers who have not proved domain control, so a large vendor publishing many servers is exempt by construction rather than by us adding an exception.

One limit worth stating: registry domain verification happens at publication and is not re-checked afterwards. So we re-check it ourselves, and we describe a server as verified at the date shown, never in the present tense.

Which servers we profile

Passing the gate makes a server trackable. We profile the ones an IT team at a food & beverage, CPG or foodservice company would plausibly evaluate. That is an editorial judgement, so here is the actual list it is made from — 52 enterprise publisher domains and 15 food-specific ones. Disagree with a row? Tell us.

How we check a server

For each hosted server we make one unauthenticated initialize request to its published endpoint — exactly what any MCP client does on connect — and fetch the two OAuth discovery documents. Where a server answers without credentials, we also list its tool names. We never call a tool, never supply a credential, and never download, install or execute any package. Package information comes from the npm and PyPI metadata APIs only.

Our crawler identifies itself, respects robots.txt and Retry-After, limits itself to one request per host at a time, and backs off on failure. Every profile shows the exact request headers used, because endpoint behaviour can depend on them and any finding we publish should be reproducible by the vendor.

If you publish a server and would rather we did not check it, email probe@mcpcompare.aiand we will stop. Existing observations become “vendor opted out” rather than being deleted.

What we evaluate

The same 18 criteria for every server, whether or not we find answers. A row with no answer still appears, marked as undocumented.

• Authentication required
• OAuth 2.1 authorization
• Dynamic client registration
• Documented scopes
• Read and write are separate scopes
• Streamable HTTP transport
• SSE transport
• Vendor-hosted endpoint
• Self-hostable package
• Public source repository
• Open-source license
• Repository actively maintained
• Package deprecated
• Secret inputs marked as secret
• Audit logging documented
• Access controls documented
• Data residency documented
• Data retention documented

Collection membership rules

Servers with documented OAuth support (23 of 34)

The server published OAuth discovery metadata when we connected without credentials.

Servers where read-only access can be granted (8 of 34)

The server's protected-resource metadata enumerates separate read and write scopes, so an administrator can grant read without granting write.

Self-hostable servers (6 of 34)

The publisher declares an installable package you can run inside your own perimeter.

Servers that answered without credentials (5 of 34)

The hosted endpoint accepted a connection and returned its capabilities with no credentials supplied.

Limitations

• Being listed in the registry is not a security certification, and nothing here is a security assessment.
• We report what is documented. A vendor may have excellent controls and poor documentation; this site cannot tell those apart.
• Controls held by a company are not attributed to a specific server. A vendor’s SOC 2 report is not that server documenting audit logging.
• We check from one network. A server we could not reach may be perfectly healthy for you.
• Coverage is skewed toward servers with public endpoints. A package-only server can be evaluated less deeply.