Routing pattern · Relying-party referral
Share resolver guidance with an MCP operator
How to refer an MCP server operator into TrustOps when you do not operate the target yourself. Share guidance. Do not promise checkout. Do not promise proof.
When to share guidance
- You observed NO_PUBLIC_RESOLVER_PROOF_FOUND, SETUP_REQUIRED, MISMATCH, EXPIRED, or REVOKED for an MCP server.
- You do not operate the MCP server yourself.
- You want the operator to improve resolver posture so future calls can be verified.
What to share
- A link to /mcp/assurance or /mcp/assurance-plus depending on tool risk.
- The TrustOps handoff URL (commercial setup happens in TrustOps, not on Developer Gateway).
- The ResultState and ReasonCodes you observed, framed as guidance, not as a safety claim.
- A reminder that local policy decides and that the operator should re-check before reliance.
What not to share
- Do not claim the MCP server is unsafe.
- Do not claim ECZ-ID blocks the server.
- Do not promise certification, approval, or insurance.
- Do not send a checkout link from Developer Gateway. Route to TrustOps for commercial setup.
No overclaim posture
- No public resolver proof found yet does not mean unsafe.
- Re-check before reliance.
- Local policy decides.
- The verifier does not create or change verification state.
ECZ-ID separates setup, verification state, and public proof so operators can prepare evidence and relying parties can re-check before they act. TrustOps handles setup. Resolver remains the public proof surface. The verifier does not create or change verification state. Start setup in TrustOps when you operate the target. Share resolver guidance when you do not. Local policy decides. Re-check before reliance.