Skip to main content
Glama

TunnelMind Data API

by ai.tunnelmind

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

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.3/5.0
Disambiguation2/5

Many tools overlap in purpose, such as cross_lens_verify, cross_lens_lookup, profile_entity, and preflight_should_i_act, which all return node verdicts with subtle differences. Sigil verification tools and receipt-related tools also have similar names and require deep reading to distinguish.

Naming Consistency3/5

The tool names are mostly readable, but the pattern is mixed: some use verb_noun (get_domain, create_subscription) while others use domain prefixes (sigil_*, ghostroute_*, intel_*). Within each domain, naming is consistent, but the overall style lacks uniformity.

Tool Count1/5

With 90 tools, this server is extremely overloaded. Even for a multi-purpose data API, the sheer number overwhelms and makes navigation difficult, far exceeding the typical well-scoped MCP server. The count is an extreme mismatch for the apparent scope.

Completeness4/5

The tool surface is very comprehensive, covering tracker lookup, cross-lens verification, receipts, compliance, subscriptions, tasks, intel probes, and more. Minor gaps exist, such as no batch cross-lens verification, but core workflows are well covered.

Resources