Skip to main content

MCP Discovery for Trust Verification

This document describes the planned MCP discovery design for trust verification. The current spec uses a direct HTTP link tag (<link rel="trstd-protocol">) — no MCP infrastructure is involved. MCP discovery extends reach to agents that do not know the #trstd <protocol> by exposing trust verification as a generic MCP tool.

This document is non-normative. For requirements, see the specification documents in architecture/.

Motivation​

MCP-native agents discover capabilities through list_tools. They connect to MCP servers, enumerate available tools, and invoke them — without fetching .well-known files or parsing HTML. Trust verification fits this paradigm naturally: a check_trust tool with a clear description tells the LLM agent when to invoke it ("before making a purchase" or "before connecting to an unfamiliar service").

The current spec uses a simpler approach: a <link rel="trstd-protocol"> tag pointing directly to the HTTP verify endpoint. This works for trstd-aware agents but is invisible to agents that do not know the protocol. Adding MCP discovery closes this gap by exposing trust verification as a tool that any MCP-compliant agent can discover and invoke without trstd-specific knowledge.

Who Operates the MCP Server?​

The trust authority operates the MCP server. Service providers advertise it through a <link> tag in their HTML or a capability entry in their /.well-known/trstd.json manifest.

This keeps the central authority model (ADR-005): the authority controls the server, the tool schema, and the response integrity. Providers opt in with a single tag or manifest entry — no proxy layer, no provider-side MCP implementation. Response signing works unchanged because the same authority that signs responses also operates the MCP server.

An alternative where each service provider runs their own MCP server (proxying to the authority) would let providers bundle trust verification with other tools. However, it adds implementation burden, latency, and attack surface — providers could tamper with unsigned portions of the response. Centralizing the MCP server at the authority avoids these risks.

Deployment Considerations​

The verify endpoint and MCP endpoint share a single domain — for example, trust-authority.example.org/v1/entities/{entityId}/trust-signals (HTTP) and trust-authority.example.org/v1/mcp (MCP). A single domain means agents need one allowlist entry, one trust boundary, and the Ed25519 signing key stays in one place.

Whether the authority runs both endpoints as one process or as separate services behind the domain is an implementation detail. The protocol defines URLs, not infrastructure topology. An authority that needs independent scaling for MCP connections (persistent) versus HTTP verify requests (stateless) can route the paths to different backends. From the agent's perspective, it is one domain.

Separate domains (e.g., trust-authority.example.org and mcp.example.org) would force agents to maintain multiple allowlist entries and require the authority to distribute signing keys across systems — added complexity with no protocol-level benefit.

Why the HTML Meta Tag Fallback Was Dropped​

The protocol used <meta name="trstd-protocol"> as a fallback for constrained hosting where providers cannot serve /.well-known/trstd.json. With MCP discovery, this fallback is redundant.

The meta tag was a degraded experience. It carried only an endpoint URL and an entityId. No provider metadata, no extension parameters, no entity matching, no additional capabilities. Agents that relied on it got less than agents that used the manifest.

The constrained-hosting argument was thin. If a provider can modify their HTML <head> to add a meta tag, they can serve a static JSON file. Providers that truly cannot control .well-known face larger barriers to protocol participation than a missing meta tag solves.

MCP replaces the same niche. The meta tag and the MCP <link> tag both target agents parsing HTML <head>. Both carry a pre-computed entityId and point to the authority. The <link> tag serves MCP-native agents with full tool discovery; the meta tag served HTTP agents with a bare endpoint URL. Since the manifest already serves HTTP agents, the meta tag's audience shrank to zero.

Fewer paths, fewer edge cases. Three discovery mechanisms meant three sets of security rules, three priority orderings, and three integration paths for agent developers. Two paths — manifest and MCP — serve distinct agent populations with no overlap.

Discovery Model​

The current spec uses a <link rel="trstd-protocol"> tag pointing directly to the HTTP verify endpoint:

<link
  rel="trstd-protocol"
  href="https://trust-authority.example.org/v1/entities/09b765de-08ed-4b95-bd38-35d6d9ed9c19/trust-signals"
  type="application/json"
  title="Trust Verification"
>

The agent scans HTML, extracts the href, appends ?url=...&context=..., and makes a single HTTP GET. One tag, one call, no MCP infrastructure. This works because the current spec targets trstd-aware agents that already know the API contract.

Planned: MCP and WebMCP​

Adding MCP discovery reaches agents that do not know the #trstd <protocol>. The trust authority operates an MCP server exposing a check_trust tool. Agents discover the tool via list_tools and invoke it.

Two paths are under consideration:

  • MCP server with standard discovery — contingent on a finalized MCP discovery standard (SEP-1649, SEP-1960, or IETF mcp: URI scheme)
  • WebMCP — service providers register check_trust via the W3C WebMCP imperative API (navigator.modelContext.registerTool) or declarative <form> elements. Any WebMCP-compliant agent discovers the tool without trstd-specific knowledge.

The planned /.well-known/trstd.json manifest adds an McpServer capability entry for MCP-native agents alongside the VerifyEndpoint for HTTP agents.

See the roadmap and the discovery specification for details.

MCP Tool Definition​

The trust authority's MCP server exposes a check_trust tool. This is what agents see when they call list_tools:

{
  "name": "check_trust",
  "description": "Check the trustworthiness of a website or service. Returns verified trust signals including identity, reputation, compliance, and recourse data. Use before making purchase decisions or connecting to unfamiliar services.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "url": {
        "type": "string",
        "description": "The full URL to verify (e.g., https://www.example.org/products/123)"
      },
      "entityId": {
        "type": "string",
        "description": "Entity ID from discovery. If omitted, the server resolves it from the URL via the service provider's manifest."
      },
      "context": {
        "type": "string",
        "enum": ["purchase", "inquiry", "high-value"],
        "description": "The intent for this verification — determines what assessment the authority returns"
      }
    },
    "required": ["url"]
  }
}

Design decisions:

  • entityId is optional. When agents discover the MCP server via a link tag with an embedded entityId, they pass it through. When they discover via the manifest, they already have the entityId from entity matching. When they have neither, the MCP server resolves it by fetching the service provider's manifest and running entity matching itself.

  • Response format matches the HTTP endpoint. The tool returns the same VerifyResponse JSON defined in the API specification and OpenAPI contract, including the kid and signature fields for verification. The MCP transport wraps it in the standard tool result envelope. Signatures and all security properties carry through unchanged.

  • Tool description is LLM-facing. The description guides the LLM agent on when to invoke the tool. The authority controls this text since it operates the MCP server.

Agent Flow (MCP)​

Step 1–2: The agent loads a service provider's page and discovers the MCP server through the manifest's McpServer capability, WebMCP tool registration, or a standard MCP discovery mechanism.

Step 3–5: The agent connects to the trust authority's MCP endpoint and calls list_tools to discover available tools.

Step 6–8: The agent invokes check_trust. The authority runs the same verification logic as /v1/entities/{entityId}/trust-signals and returns the signed response as a tool result.

Step 9: The agent evaluates the trust signals against its policies and decides whether to proceed.

Relationship to Existing Discovery​

StatusDiscovery PathTargetMechanism
Today<link rel="trstd-protocol"> tagtrstd-aware agentsScan HTML, extract verify URL, HTTP GET
PlannedMCP server / WebMCPAll MCP-compliant agentsDiscover check_trust tool, invoke it
Planned.well-known/trstd.json manifestAll agentsFetch JSON, match entity, call /v1/entities/{entityId}/trust-signals or connect to McpServer
Planned<link rel="trstd-protocol"> tag (fallback)trstd-aware agentsSame as today, used when manifest is unavailable

The same /v1/entities/{entityId}/trust-signals endpoint powers all paths. The MCP server is a transport adapter — it translates MCP tool calls into the same verification logic as the verify endpoint. All trust signals, signatures, and security properties remain identical regardless of which discovery path the agent uses. The response includes the same kid and base64url-encoded raw Ed25519 signature fields; agents verify against the authority's published JWKS.

Security Considerations​

Response signing passes through MCP. The MCP server returns the authority's signed VerifyResponse as the tool result, including the kid and raw Ed25519 signature fields. Agents verify the signature against the authority's published JWKS exactly as they would for a direct HTTP response. The MCP transport does not alter the signed payload.

Authority domain allowlist applies. Agents must validate that the MCP server URL belongs to a known trust authority domain — the same allowlist check described in the discovery specification. A malicious service provider could embed a <link> tag pointing to a rogue MCP server. The allowlist defense is identical: check the MCP server's hostname against the allowlist before connecting.

Rogue MCP servers cannot forge signatures. A rogue MCP server lacks the authority's Ed25519 private key. It cannot produce valid signatures. The agent verifies the signature on every response, so impersonation fails at the cryptographic layer.

Tool description injection. The MCP server's list_tools response includes tool descriptions that LLM agents incorporate into their reasoning. A compromised MCP server could craft a malicious description. The authority domain allowlist mitigates this: agents only connect to allowlisted MCP servers. Since the trust authority operates the MCP server, the authority controls all tool descriptions.

URL parameter integrity. Agents must build the url parameter from the actual page URL, not from any value in the link tag. This prevents a crafted link tag from redirecting verification to a different resource.

Open Questions​

These questions require working group input before MCP discovery moves into the normative specification:

  • MCP resources vs. tools. Should the MCP server expose trust signals as MCP resources (for cached, subscription-style access) in addition to the check_trust tool? Resources suit data that changes infrequently; trust verification is a point-in-time query.

  • Agent identification over MCP. Agent identification is optional per-request in the current spec (ADR-006). When an agent chooses to identify itself, the did:web JWT travels in an HTTP Authorization header on direct HTTP requests. MCP sessions have their own connection lifecycle. How does the MCP server accept an agent's identity — as a tool parameter, during session initialization, or through MCP's own auth layer?

  • Manifest schema update. McpServer needs to become a formally recognized capability type in the manifest JSON schema. The schema currently enforces GET for the verify capability via a conditional rule; a similar rule for McpServer (requiring POST) should be added.

  • MCP transport. Which MCP transport should the trust authority support? Streamable HTTP fits the stateless request/response pattern of trust verification. SSE enables server-pushed updates (e.g., trust signal changes) but adds operational complexity.

  • Entity ID resolution. When an agent discovers the MCP server without a pre-computed entityId (e.g., another agent recommended the URL), should the MCP server resolve the entity by fetching the provider's manifest? This adds a dependency and latency to the MCP server.

References​