The Problem

MCP has solved tool discovery and execution. But as MCP servers proliferate (200+ official integrations, thousands of community servers), a new problem emerges:

How does an AI agent decide which MCP server to trust?

Today, when an agent finds two MCP servers offering similar tools, it has no machine-readable way to evaluate:

• Trust: Is this server who it claims to be? Is it verified?
• Proof: Can this server cryptographically prove its responses are authentic?
• Reputation: Has this server reliably served other agents before?
• Pricing: What does it cost? Is there a free tier?
• Liveness: Is this server operational right now, or am I looking at stale metadata?

What We Observed

We built a signal scanner that measures how "agent-ready" a domain is across 11 layers. We scanned major platforms:

Every platform has Presence and basic Capability (they serve HTTP, they have APIs). But almost none provide machine-readable Trust, Proof, or Reputation signals.

The Layers We Think Are Missing from MCP

MCP currently covers:

• ✅ Capability Discovery: tools/list, resources/list
• ✅ Execution: tools/call
• ✅ Transport: StreamableHTTP, SSE, stdio

What's missing for autonomous agent-to-agent commerce:

1. Proof Layer: A standard way for MCP servers to cryptographically sign responses (e.g., ES256K signatures on tool results, content hashes)
2. Reputation Layer: A standard for agents to rate MCP servers after interactions (quality of response, uptime, accuracy)
3. Pricing/Offer Layer: Machine-readable pricing so agents can compare costs before choosing a server (related to x402 but broader)
4. Liveness Signal: Active heartbeat beyond just "server responds to HTTP" — when was the last successful tool call? What's the current load?

Why This Matters

As MCP moves toward autonomous agent workflows (agents calling agents calling tools), trust becomes critical. An agent executing a financial transaction needs to know:

• Is this compliance server actually checking real ESMA registers, or hallucinating?
• Can I prove to my regulator that I used a verified data source?
• Has this server been reliable for other agents?

Without these signals, agents have to trust blindly — which is exactly what we're trying to move away from.

What We Built (open for discussion)

We've been experimenting with what we call "signal layers" for MCP servers:

• ES256K signatures on every tool response
• SHA-256 evidence hashes for tamper detection
• On-chain anchoring of compliance decisions (Polygon, XRPL, Arbitrum)
• OracleNet manifest at /.well-known/oraclenet.json — machine-readable trust profile

Live example: Our compliance MCP server at mcp.tooloracle.io/compliance/mcp/ signs every compliance_preflight response and anchors evidence on Arbitrum One (example tx).

Questions for the Community

1. Should MCP define a standard extension for signed responses? Something like signature field in tool results with algorithm, key ID, and hash.

2. Should there be a standard .well-known/mcp-trust.json for MCP servers to declare their trust properties (signing keys, audit trail, uptime, pricing)?

3. Is response signing something that belongs in the MCP spec, or should it be a community convention?

4. How do others handle the "which MCP server do I trust?" problem in production?

We'd love to hear how others are thinking about this. The tools layer is solved — the trust layer is the next frontier.

Built by ToolOracle — 98+ MCP servers, 1000+ tools. Scanner: tooloracle.io/scan