MCP registry
Input: provider-published server metadata, package or remote endpoint information, versions, and a verified namespace. Output: records that clients and downstream aggregators can discover.
Architecture comparison
MCP registry versus capability router
A registry is a publication and distribution layer. A capability router is a runtime selection layer. They are complementary: routing can ingest registry metadata, but publication alone cannot answer which connection should satisfy a particular agent intent now.
Comparison
Publication metadata versus runtime decision evidence
The distinction is easiest to see by asking what enters each system, what question it answers, and what the consumer may safely infer from the result.
Capability router
Input: a bounded runtime intent plus eligible definitions, policy, health, behavior evidence, and outcomes. Output: a ranked connection or an unresolved result.
Registry time horizon
A record represents what a namespace owner published at a version. Aggregators decide how often to refresh and what additional curation to apply.
Router time horizon
A decision uses current eligibility and observed evidence for this request. Stale, unhealthy, drifted, or disallowed candidates must disappear from the result set.
Composition
Use the registry as a lead, not a verdict
ResolveMesh can consume public Registry metadata as one source layer. Provider consent and each later evidence gate remain separate, recorded decisions.
Discover publication
Read the current Registry record and attribute it to the verified namespace without changing or endorsing the provider claim.
Obtain consent
Keep monitoring disabled until an authorized provider contact opts into the credential-free evidence pilot.
Build evidence
Separate definition digest, provider attestation, independent behavior review, health observations, and drift state.
Resolve at runtime
Rank only manually approved read-only connections that satisfy the current intent; otherwise return unresolved.
Inference limits
What a registry record does not establish
These properties may be added by a downstream service only when that service has its own evidence and states the basis for the claim.
No behavior proof
A valid record does not prove that the server performs each described operation correctly or within a particular risk boundary.
No availability promise
Publication does not establish current reachability, latency, response validity, or stable behavior across time.
No universal permission
A public server can still require credentials, user consent, tenant policy, paid access, or execution-specific approval.
Decision guide
Which layer do you need?
Most production systems need both. Start with the unanswered question rather than choosing a product category by name.
Use a registry when
Providers need a standardized way to publish server identity, installation or endpoint metadata, and versions for broad discovery.
Use a router when
An agent must choose among eligible connections for a specific intent using constraints, current evidence, and outcome history.
Use a gateway when
The system must enforce identity, credentials, invocation policy, traffic controls, or proxy execution after selection. ResolveMesh V0 is not that execution gateway.
Primary sources
References
Registry scope, attribution, and protocol behavior come from the current official MCP project documentation and terms.
The Official MCP Registry
Primary reference for standardized server metadata, verified namespaces, and the Registry's downstream-aggregator model.
Read the primary sourceMCP architecture overview
Primary protocol reference for how a configured client discovers server primitives and invokes tools.
Read the primary sourceOfficial MCP Registry terms
Current terms for attribution and permissible use of Registry data by downstream services.
Read the primary source