Skip to main content
Glama

TunnelMind Data API

by ai.tunnelmind

explain_verdict

Call this when you need to ACT ON a verdict and prove why. It returns the exact verdict /v1/verify/{node} computes (same fusion, same weights) PLUS a traced evidence chain: every claim is attributed to where it came from — the attested sensor fleet (with attestation tier), a named Augur threat feed, sellers.json/ads.txt supply-graph presence, the cross-lens co-observation join, the DDG/IAB tracker corpus — and how much each item moved the verdict (weight; null = supplementary, not scored).

The response is committed to by a P38 signed receipt via evidence_digest (a hash of the exact evidence array), so an agent can act on the verdict and leave behind a cryptographically verifiable trail of the reasoning in the same request. Empty/none evidence is the honest "no corpus presence", never a fabricated reason.

node is an IPv4/IPv6, ASN, domain, or entity_slug — the same key space as /v1/verify.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeYesIPv4/IPv6, ASN (AS####), domain, or entity_slug.

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and excels. It discloses the exact verdict computation, evidence attribution details, weight semantics (null = supplementary), P38 signed receipt commitment via evidence_digest, and explicitly addresses empty evidence as honest 'no corpus presence'. This provides comprehensive behavioral insight.

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

Conciseness5/5

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

The description is well-structured and front-loaded with the core use case. Three paragraphs pack substantial detail without redundancy: purpose, evidence chain mechanics, receipt and edge-case behavior, and node key space. Every sentence contributes meaning.

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 no output schema and no annotations, the description explains key output aspects: exact verdict, evidence chain attributes, weight interpretation, and cryptographic receipt via evidence_digest. It also clarifies the node key space and empty-evidence semantics, making the tool fully understandable for an agent.

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

Parameters3/5

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

The schema already fully describes the single parameter with 100% coverage. The description adds only that 'node' uses the same key space as `/v1/verify`, which is minor contextual reinforcement. No new semantic meaning is introduced beyond the schema.

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 starts with a clear directive: 'Call this when you need to ACT ON a verdict and prove why.' It specifies that the tool returns the exact verdict and a traced evidence chain, distinguishing it from siblings like verdict_lookup by emphasizing the evidence and cryptographic receipt.

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?

The description states when to use the tool ('when you need to ACT ON a verdict and prove why') and notes that 'node' uses the same key space as `/v1/verify`. It doesn't explicitly name alternative sibling tools, but the usage context is clear and actionable.

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