TunnelMind Data API

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, or the signature does not cover @authority and signature-agent, lacks created/expires, has a validity window over 300 s, or has a created more than 60 s in the future.
- replayed — the signature verifies but was already seen (same keyid + nonce, or same signature) within its validity window.
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

Name	Required	Description	Default
`path`	No
`method`	No
`scheme`	No
`authority`	Yes
`signature`	Yes
`signature_agent`	Yes
`signature_input`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

changedInput schema / properties / signature_input / example

Previous value: -"sig2=(\"@authority\" \"signature-agent\");created=1735689600;keyid=\"poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U\";alg=\"ed25519\";expires=1735693200;tag=\"web-bot-auth\""New value: +"sig2=(\"@authority\" \"signature-agent\");created=1735689600;keyid=\"poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U\";alg=\"ed25519\";expires=1735689900;tag=\"web-bot-auth\""

AddedJul 30, 2026

TDQS

A4.7/5.0

Behavior5/5

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

No annotations are provided, so the description carries full behavioral burden and does so richly: it enumerates all six result states with their semantics, flags 'directory_unreachable' as an honest degraded state rather than forgery, and discloses rate-limit cost and latency/caching behavior. That is well beyond what any annotation would supply.

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?

Front-loaded with purpose, then a critical framing note ('facts, not a verdict'), followed by clearly labeled Usage/Inputs/Returns/Cost/Latency sections. It is long, but each block carries distinct, non-redundant information for a genuinely complex tool; only minor trimming is possible.

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?

With no output schema and a complex multi-state operation, the description fully documents the return shape (state, key_id, directory_url, params, checks[]) and even the malformed/expired validation rules. Nothing an agent needs to invoke and interpret the tool is missing.

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?

Schema description coverage is 0%, so the description must compensate, and it does: it documents all four required body params plus method/path/scheme, and explains the conditional need for the three optional ones ('only needed if the signature's covered components include them').

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?

States a specific verb and resource: verifies an Ed25519 Web Bot Auth signature against the agent's own published key directory. It also distinguishes itself from CDN-implemented Web Bot Auth, so an agent can tell what this does versus generic 'verify_agent'-style siblings.

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

Usage Guidelines4/5

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

Provides an explicit 'Use this tool when:' block with two concrete conditions (a request claims a cryptographic agent identity; you want verification independent of your CDN). Clear context, but it never names a specific sibling tool to prefer instead, nor states an explicit when-not for the named alternatives.

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 tools Inspect

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

Need Help?