Description:
Per the MCP spec (tools/list), a tool definition is just name/description/inputSchema/outputSchema/annotations — no hash, signature, or content-addressing of the actual implementation. The spec's own guidance is that clients "must consider tool data untrusted unless it comes from a trusted server" — i.e. the only integrity story today is "trust the server," with no way for a caller to independently verify that what it's about to invoke is exactly what was published.
For a gateway sitting in front of multiple MCP backends, this seems like a natural place to add an opt-in integrity check: if a backend's tool definitions carry a content digest (e.g. a manifest with a sha256 of the tool's payload/definition), Agent Router could verify that digest before forwarding tools/list or before allowing tools/call, rather than only proxying traffic through.
I've been building a small reference implementation of this specific pattern — Skillward (Python, Apache-2.0) — where every skill manifest carries a sha256 digest that the consuming client verifies right before executing anything fetched, rather than trusting the proxy layer alone. Not proposing a code port (different language/architecture — a standalone registry behind an ext_authz-gated Envoy instance, not a Kubernetes CRD control plane) — just flagging the gap in case digest verification for MCP backends is something worth adding here.
Does this match anything already planned, or is it a real gap for Agent Router's MCP support?
Relevant Links:
Description:
Per the MCP spec (tools/list), a tool definition is just name/description/inputSchema/outputSchema/annotations — no hash, signature, or content-addressing of the actual implementation. The spec's own guidance is that clients "must consider tool data untrusted unless it comes from a trusted server" — i.e. the only integrity story today is "trust the server," with no way for a caller to independently verify that what it's about to invoke is exactly what was published.
For a gateway sitting in front of multiple MCP backends, this seems like a natural place to add an opt-in integrity check: if a backend's tool definitions carry a content digest (e.g. a manifest with a sha256 of the tool's payload/definition), Agent Router could verify that digest before forwarding tools/list or before allowing tools/call, rather than only proxying traffic through.
I've been building a small reference implementation of this specific pattern — Skillward (Python, Apache-2.0) — where every skill manifest carries a sha256 digest that the consuming client verifies right before executing anything fetched, rather than trusting the proxy layer alone. Not proposing a code port (different language/architecture — a standalone registry behind an ext_authz-gated Envoy instance, not a Kubernetes CRD control plane) — just flagging the gap in case digest verification for MCP backends is something worth adding here.
Does this match anything already planned, or is it a real gap for Agent Router's MCP support?
Relevant Links: