One command to verify MCP trust
curl -s https://marketnow.site/api/atc?action=verify&card_id=ATC-2026-7777670 | jq
Returns:
{
"valid": true,
"sentinel_review_score": 10,
"decision_authority": "consumer",
"risk_level": "low"
}
What is this?
Agent Trust Cards (ATC) — Ed25519-signed identity cards for MCP servers. RFC 8032 + RFC 8785 JCS. Schema v1.1.0.
The ATC answers 4 questions:
- Identity (Ed25519 public key)
- Issuer (which CA vouches)
- Validity (valid/revoked)
- Review evidence (Sentinel score 0-10)
It does NOT answer should you trust it? — that is YOUR decision.
Also: verify Vibe receipts (mutual hop)
curl -s https://marketnow.site/api/atc?action=verify-vibe-receipt | jq .valid
# -> true (bidirectional Ed25519 verification)
Submit your MCP server for free audit
curl -X POST https://marketnow.site/api/submit-skill -H "Content-Type: application/json" -d x27{"repo_url": "https://github.com/you/your-mcp-server"}x27
10-layer audit. Ed25519 ATC. Catalog listing. All free.
Links: https://marketnow.site/submit | https://github.com/edgarfloresguerra2011-a11y/marketnow
Top comments (3)
I found the use of Ed25519 signatures for Agent Trust Cards (ATC) to be particularly interesting, as it provides a robust and compact way to verify the identity and validity of MCP servers. The fact that the
curlcommand can verify the trust in a single step is quite convenient, and the JSON output provides a clear and machine-readable format for the verification results. I'm curious to know more about the Sentinel review score and how it's calculated, as it seems to play a key role in determining the risk level of an MCP server. Does the Sentinel score take into account any external factors, such as the server's reputation or user feedback?The idea of separating cryptographic verification from the actual trust decision is an important distinction, especially as MCP servers become part of increasingly autonomous agent workflows.
I particularly like that the ATC gives agents machine-readable evidence around identity, issuer, validity, and review history rather than reducing “trust” to a single score. The next challenge I see is how this could work dynamically in production — for example, an agent evaluating a server’s capabilities, permissions, provenance, and recent security history before allowing tool execution.
I work mainly on production LLM/agent systems, tool-calling workflows, and RAG/automation infrastructure, so MCP security is an area I’d be interested in exploring further. If you're looking for contributors, collaborators, or have related paid engineering work around MCP/agent security, I’d be happy to connect and see if there’s a good fit.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.