Skip to main content
Glama

TunnelMind Data API

by ai.tunnelmind

cross_lens_verify

A2 — the cross-lens join. TunnelMind owns multiple halves of the open-web graph: Scry sees who is on every IP (attacker intelligence, actor class, Augur threat-intel overlap); Sigil sees the supply graph (publishers, SSPs, DSPs, ads.txt + sellers.json + SupplyChain Object); GhostRoute sees routing integrity & sovereignty (RPKI origin validity, BGP prefix, claimed sovereign zone, sanctions, AI-infrastructure ownership, certificate CA). This endpoint fuses them into one verdict on a single node key.

Streaming mode (P56): send Accept: application/x-ndjson and the same verdict computation streams as one JSON object per line — a {"t":"lens",...,"state":"start"} line when each lens query is dispatched, a "state":"result" line as each lens actually resolves (real completion order, never reordered or paced), then the final {"t":"verdict",...} line with the fused verdict, trust score, and attestation tier. The default single-JSON response is unchanged and the two modes return the identical verdict for the same node.

The response leads with a base record, then the lens views:

  • ip_intel — the BASE: the commodity IP-intelligence + WHOIS record (geo/ASN/company/WHOIS/routing/cert), every field provenance-tagged {value, tier, source} (verified/derived/trusted) with a behaviour axis from Scry. The lens blocks below are augmentation beside it. Committed in the receipt payload. See docs/IP-INTEL-RECORD.md.

  • scry — the single-lens Scry view (transparency).

  • sigil — the single-lens Sigil view (transparency).

  • ghostroute — the single-lens GhostRoute view (transparency).

  • cross_lens — the fused verdict (the moat).

Fusion math: weighted-mean over evaluated components plus a co_observation_bonus when both lenses independently flag the node. GhostRoute adds a routing-integrity component with two hard safety floors that cannot be averaged away: an RPKI-INVALID origin (a BGP hijack signal) caps its trust at 0.15, and a sanctions match zeroes it. Weights and thresholds are per-request overridable.

Lens unavailability is reported in-band: each lens fails independently and the cross_lens block reflects degraded confidence when fewer lenses have data (0.55 one lens / 0.80 two / 0.94 three). GhostRoute has no routing surface for a bare entity_slug, so it drops out and the remaining weights re-normalise. Returns 503 only when ALL lenses are unavailable.

v1 lens coverage matrix:

  • IP node — Scry: full; Sigil: not_indexed (v2 will reverse-DNS); GhostRoute: full.

  • Domain node — Scry: deferred; Sigil: full (publisher/ssp/dsp + entity); GhostRoute: full (resolves to IP).

  • entity_slug node — Scry: n/a; Sigil: full (entity + sell/buy presence); GhostRoute: n/a (no routing surface).

  • ASN node — Scry: deferred (v2); Sigil: not_indexed; GhostRoute: origin-AS lookup.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aitNoOptional ATAP AIT id (`AIT-<uuidv7>`). When present, the verdict is wrapped in a witness-tier `cross_lens:verified` event chained onto the AIT and signed by Sigil (witness OAI-2026-0000201). Independent of the AIT, a short-lived signed `sigil_token` is always issued on a successful verify, and a durable TunnelMind `receipt` (v1.0) commits to the verdict for long-term audit.
nodeYesThe node to verify. Type is auto-detected: IPv4/IPv6 address, domain, ASN with optional `AS` prefix, or entity_slug.
weightsNoPer-component weight overrides
thresholdsNo{ pass, fail } verdict cutoffs (defaults 0.7 / 0.3)
claimed_zoneNoCaller-asserted sovereign zone for the subject (e.g. `EU`) — "the vendor's contract says EU-only; score the routing against that claim." Validated against the sovereign-zone reference; an unknown code is ignored with caveat `claimed_zone_unrecognised_ignored` (garbage input never creates penalties). Takes precedence over the corpus's public claim; the response and signed receipt record who asserted it in `ghostroute.claimed_sovereign_zone_source` (`caller` | `corpus`). Claim-bearing calls bypass the shared lens cache and are never written back to the corpus (ADR-012).

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behavior: streaming mode with Accept header, response structure with base record and lens views, fusion math with hard safety floors, in-band lens unavailability reporting, and 503 only when all lenses are down. It also covers claim-bearing calls bypassing cache and ADR-012, providing deep transparency.

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

Conciseness3/5

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

The description is structured with clear sections but is extremely verbose, covering streaming mode, fusion math, response layout, and a coverage matrix. While each section adds useful information, the sheer length may overwhelm an agent; the opening is not front-loaded with a succinct purpose statement, starting instead with 'A2 — the cross-lens join.'

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 the tool's complexity (5 parameters, nested objects, no output schema), the description thoroughly covers output structure, edge cases, and behavior under various node types. It explains the response shape (base record, lens views, cross_lens) and failure modes (in-band lens degradation, 503 conditions), making it complete for agent use.

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 input schema already provides 100% parameter coverage with detailed descriptions for node, ait, and claimed_zone. The description adds minimal parameter-specific value beyond noting that weights and thresholds are per-request overridable, which is already implied by the schema. Therefore, it meets the baseline of 3 without exceeding.

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 the tool 'fuses them into one verdict on a single node key', combining Scry, Sigil, and GhostRoute lenses. This is a specific verb+resource (verify a node via cross-lens fusion) and distinguishes it from sibling tools like cross_lens_lookup by emphasizing the verdict generation and verification aspect.

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

Usage Guidelines3/5

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

The description provides extensive context on when the tool is applicable, including a coverage matrix for different node types and behavior under lens unavailability. However, it does not explicitly name alternative tools or give 'use this instead of X' guidance, leaving when-to-use vs alternatives implied rather than stated.

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