Skip to main content
Glama
Sign In

TunnelMind Data API

by ai.tunnelmind
OverviewDiscussionsAdmin

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

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. Writing to an AIT requires `Authorization: Bearer <holder_secret>` (issued once at AIT registration); without it the call is 401, with a wrong one 403, and nothing is appended. Because the bearer carries the holder secret, a `tm_live_` API key cannot be sent in the same call (it is checked as the holder secret and fails 403), and the call is rate-limited and audited as anonymous tier.
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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / ait / description
      Previous value: -"Optional ATAP AIT id (`AIT-<uuidv7>`). When present, the\nverdict is wrapped in a witness-tier `cross_lens:verified`\nevent chained onto the AIT and signed by Sigil\n(witness OAI-2026-0000201). Independent of the AIT, a\nshort-lived signed `sigil_token` is always issued on a\nsuccessful verify, and a durable TunnelMind `receipt`\n(v1.0) commits to the verdict for long-term audit.\n"New value: +"Optional ATAP AIT id (`AIT-<uuidv7>`). When present, the\nverdict is wrapped in a witness-tier `cross_lens:verified`\nevent chained onto the AIT and signed by Sigil\n(witness OAI-2026-0000201). Independent of the AIT, a\nshort-lived signed `sigil_token` is always issued on a\nsuccessful verify, and a durable TunnelMind `receipt`\n(v1.0) commits to the verdict for long-term audit.\nWriting to an AIT requires `Authorization: Bearer\n<holder_secret>` (issued once at AIT registration);\nwithout it the call is 401, with a wrong one 403, and\nnothing is appended.\nBecause the bearer carries the holder secret, a `tm_live_`\nAPI key cannot be sent in the same call (it is checked as the\nholder secret and fails 403), and the call is rate-limited\nand audited as anonymous tier.\n"
  2. Changed1 schema field changed
    • addedInput schema / properties / claimed_zone
      Added value: +{
+  "description": "Caller-asserted sovereign zone for the subject (e.g. `EU`) —\n\"the vendor's contract says EU-only; score the routing\nagainst that claim.\" Validated against the sovereign-zone\nreference; an unknown code is ignored with caveat\n`claimed_zone_unrecognised_ignored` (garbage input never\ncreates penalties). Takes precedence over the corpus's\npublic claim; the response and signed receipt record who\nasserted it in `ghostroute.claimed_sovereign_zone_source`\n(`caller` | `corpus`). Claim-bearing calls bypass the\nshared lens cache and are never written back to the\ncorpus (ADR-012).\n",
+  "example": "EU",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / node / description
      Previous value: -"The node to verify. Type is auto-detected: IPv4 address, domain,\nASN with optional `AS` prefix, or entity_slug.\n"New value: +"The node to verify. Type is auto-detected: IPv4/IPv6 address, domain,\nASN with optional `AS` prefix, or entity_slug.\n"
  4. Changed1 schema field changed
    • changedInput schema / properties / ait / description
      Previous value: -"Optional ATAP AIT id (`AIT-<uuidv7>`). When present, the\nverdict is wrapped in a witness-tier `cross_lens:verified`\nevent chained onto the AIT and signed by Sigil\n(witness OAI-2026-0000201). Independent of the AIT, a\nshort-lived signed `sigil_token` is always issued on a\nsuccessful verify so the caller has a portable proof.\n"New value: +"Optional ATAP AIT id (`AIT-<uuidv7>`). When present, the\nverdict is wrapped in a witness-tier `cross_lens:verified`\nevent chained onto the AIT and signed by Sigil\n(witness OAI-2026-0000201). Independent of the AIT, a\nshort-lived signed `sigil_token` is always issued on a\nsuccessful verify, and a durable TunnelMind `receipt`\n(v1.0) commits to the verdict for long-term audit.\n"
  5. First observed

TDQS

A3.7/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 does so richly: it discloses 401/403 auth outcomes for AIT writes, rate-limiting and anonymous-tier auditing, 503 only when all lenses fail, in-band degraded-confidence tiers (0.55/0.80/0.94), hard safety floors (RPKI-INVALID caps 0.15, sanctions zeroes), and that claim-bearing calls bypass the shared cache. These are exactly the traits an agent cannot infer from structured fields.

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

Conciseness2/5

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

The body is extremely long and dense with internal codenames and references (A2, P56, ADR-012, docs/IP-INTEL-RECORD.md, witness OAI-2026-0000201) that add noise rather than selection value. It leads with a cryptic 'A2 — the cross-lens join' instead of a plain purpose statement, and the response-shape inventory dominates before any guidance on usage.

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

Completeness4/5

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

For a genuinely complex fusion tool with no output schema, the description covers the important surface: response block structure (ip_intel base plus lens blocks), streaming NDJSON mode, per-lens failure semantics, degradation math, and node-type coverage. The main omission is guidance on choosing this tool over its siblings rather than anything about invocation correctness.

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?

Schema description coverage is 100%, so the schema already documents node, ait, claimed_zone, weights and thresholds, making 3 the baseline. The description adds only marginal parameter-level meaning — that weights and thresholds are 'per-request overridable' and that thresholds are pass/fail cutoffs — which the schema largely already states.

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

Purpose4/5

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

The description states a concrete verb and resource — it fuses Scry, Sigil and GhostRoute lens views into a single verdict on one node key — which is specific enough to distinguish it from single-lens siblings like sigil_verify_domain or ghostroute_verify. However, it never names the closest sibling, cross_lens_lookup, or explains how the 'verify' variant differs, so sibling differentiation is left implicit.

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 v1 coverage matrix implicitly tells the agent which node types yield data (IP/domain/ASN/entity_slug), which is useful contextual guidance. But there is no explicit when-to-use vs when-not-to-use statement, no mention of when to prefer the cheaper cross_lens_lookup or a single-lens verify call, and no prerequisite section beyond the AIT bearer note buried in the schema.

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