Skip to main content
Glama

TunnelMind Data API

by ai.tunnelmind
OverviewDiscussionsAdmin

verify_agent_signature

Neutral third-party Web Bot Auth verification. An origin — or the PDP deciding for it — received a request from a claimed agent carrying the Web Bot Auth headers (Signature, Signature-Input, Signature-Agent). Relay those headers here, plus the authority the request was addressed to, and TunnelMind verifies the Ed25519 signature against the agent's own published key directory (https:///.well-known/http-message-signatures-directory).

Facts, not a verdict: state: verified means "this signature cryptographically verifies against that directory" — whether to trust the agent behind it is your policy engine's call.

Use this tool when:

  • A request claims a cryptographic agent identity (Signature-Agent header present) and you must check the claim before serving it.

  • You want signature verification independent of your CDN — or you are not behind a CDN that implements Web Bot Auth at all.

Inputs (JSON body):

  • signature (required): the received Signature header value.

  • signature_input (required): the received Signature-Input header value.

  • signature_agent (required): the received Signature-Agent header value (quoted https origin).

  • authority (required): the host the request was addressed to.

  • method, path, scheme (optional): only needed if the signature's covered components include them.

Returns:

  • state: one of

    • verified — Ed25519 signature verifies against a key in the agent's published directory.

    • invalid_signature — key found, signature does not verify (tampered or forged).

    • unknown_key — directory reachable but contains no key with the claimed thumbprint.

    • directory_unreachable — the claimed key directory did not answer; an honest degraded state, not evidence of forgery.

    • expired — the signature's expires timestamp has passed.

    • malformed — headers do not parse as a Web Bot Auth signature.

  • key_id: the claimed RFC 7638 JWK thumbprint.

  • directory_url: the resolved well-known directory URL.

  • params: created/expires/alg/tag as sent.

  • checks[]: per-check {name, pass, detail} facts a PDP can gate on.

Cost:

  • Counts as one request against the daily rate limit.

Latency:

  • Typical: <100ms when the agent's directory is KV-cached (1h TTL); up to ~5s on first sight of a new directory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
methodNo
schemeNo
authorityYes
signatureYes
signature_agentYes
signature_inputYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses cost (counts as one request against rate limit), latency (cached <100ms, up to ~5s on first sight), and behavior (verification states, directory resolution, checks array). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with headings and bullet points, but slightly verbose. Every sentence adds value, but could be tightened around return values. Front-loaded purpose and usage effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 params, no output schema, and no annotations, the description covers inputs, outputs, states, cost, latency, and behavioral nuances. Completely sufficient for an agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description explains each parameter in detail: required headers (signature, signature_input, signature_agent, authority) and optional ones (method, path, scheme) with context on when needed. Compensates fully for missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is for 'neutral third-party Web Bot Auth verification'. It specifies the verb 'verify' and the resource 'agent signature' with cryptographic detail. Distinguishes from sibling 'verify_agent' by focusing on Web Bot Auth headers and signature verification against a key directory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides use cases: when a request claims cryptographic identity and must check the claim, or when signature verification is needed independent of CDN. Also clarifies what the tool does not do ('Facts, not a verdict'), guiding the agent on when to use versus its own policy enforcement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All TunnelMind Data API toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources