Developer Gateway · MCP hub
MCP — Model Context Protocol trust on ECZ-ID
Resolve the server. Resolve the agent. Re-check before reliance. ECZ-ID gives MCP servers, tools, and the platforms that route to them a resolver-first way to check posture before high-risk use.
What MCP trust on ECZ-ID is
ECZ-ID lets an MCP server publish a resolver-identifiable identity and lets platforms, agents, and developers check that identity before they call any high-risk tool. 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.
Role split
- 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 acquisition, setup, payment, and lifecycle.
- Resolver remains the public proof surface for current state.
- Developer Gateway documents and routes.
- External subscription or commerce surfaces handle acquisition only — they cannot create or change verification state.
MCP pages on Developer Gateway
- ECZ-ID MCP Verifier™ — free resolver-posture checker for developers and platforms.
- ECZ-ID MCP Assurance™ — provider-side resolver posture setup guidance.
- ECZ-ID MCP Assurance Plus™ — stronger provider-side resolver posture for servers with high-risk tools.
- ECZ-ID MCP Policy™ — allow / warn / require policy-gate guidance for relying parties.
- Result States and Reason Codes — the canonical state vocabulary.
- Share resolver guidance — how to refer an MCP operator into TrustOps 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.