Skip to main content
Glama
Sign In

TunnelMind Data API

by ai.tunnelmind
OverviewDiscussionsAdmin

preflight_should_i_act

The single call an agent makes before transacting with a destination on the open web. Composes the cross-lens verdict with a bounded Tracker-presence bonus, maps the adjusted trust score to a tri-state decision (allow / caution / deny), and returns a 5-minute signed consultation receipt (sigil_token with sub: preflight:consulted).

The receipt is the load-bearing artifact: the agent attaches it to its action log as cryptographic proof that the destination was consulted before action. The decision itself is commodity-shaped; the receipt of having asked is what accountability requires.

When ait is supplied, the consultation additionally chains a witness-tier preflight:consulted event onto the ATAP AIT, signed by OAI-2026-0000201 — turning the consultation into a hash-chained, replayable artifact.

Tracker presence applies a bounded +0.05 trust bonus before decision mapping (capped at 1.0). Absence is never a penalty — most of the open web is not in the tracker corpus and that's expected.

Defaults: allow >= 0.70, caution >= 0.40, else deny. Thresholds are overridable per request; weights are inherited from cross_lens_verify.

Input Schema

NameRequiredDescriptionDefault
aitNoOptional ATAP AIT id. When present, chains a witness-tier `preflight:consulted` event onto the AIT. Requires `Authorization: Bearer <holder_secret>` (issued once at AIT registration); nothing is appended without it. 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.
nodeYesIPv4/IPv6 address, domain, ASN with optional `AS` prefix, or entity_slug.
intentNoFree-form context — recorded in the receipt, never affects the decision. Validated against /^[A-Za-z0-9._:-]{1,64}$/.
agent_idNoCaller's stable agent identifier, recorded in the receipt. Validated against /^[A-Za-z0-9._:-]{1,128}$/.
thresholdsNoOptional overrides; must satisfy 0 <= caution < allow <= 1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / ait / description
      Previous value: -"Optional ATAP AIT id. When present, chains a witness-tier\n`preflight:consulted` event onto the AIT.\n"New value: +"Optional ATAP AIT id. When present, chains a witness-tier\n`preflight:consulted` event onto the AIT. Requires\n`Authorization: Bearer <holder_secret>` (issued once at\nAIT registration); nothing is appended without it.\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
    • changedInput schema / properties / node / description
      Previous value: -"IPv4 address, domain, ASN with optional `AS` prefix, or entity_slug."New value: +"IPv4/IPv6 address, domain, ASN with optional `AS` prefix, or entity_slug."
  3. Added

TDQS

A4.5/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 the full burden and does so richly: the bounded +0.05 tracker bonus (and that absence is never a penalty), the tri-state mapping, the signed 5-minute receipt with `sub: preflight:consulted`, and the witness-tier event chaining when `ait` is present. Auth consequences (bearer required, tm_live_ key 403, anonymous-tier rate limiting) are surfaced.

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 the core purpose and information-dense about mechanics. Some editorializing ('commodity-shaped', 'load-bearing artifact') is rhetoric rather than operational content, but it is brief and the mechanics sections earn their place.

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 complex, high-stakes tool with no output schema and no annotations, the description covers decision mapping, thresholds, defaults, the receipt token, and AIT chaining. It stops short of describing the full response shape (score fields, other receipt claims), which the agent would need to interpret the return.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3. The description adds semantics beyond the schema: the default threshold values (0.70/0.40) that the schema only shows as examples, that `intent` is recorded but never affects the decision, and the bonus mechanics behind the score. It does not, however, elaborate on `node` formats, which the schema already handles.

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 (consult/preflight) and the exact moment it applies: 'The single call an agent makes before transacting with a destination on the open web.' It also names the adjacent sibling it depends on ('weights are inherited from cross_lens_verify'), so an agent can separate this pre-action consultation from verify/lookup/explain 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?

The opening sentence gives a strong when-to-use condition (before transacting), and the `ait` paragraph explains the conditional chain behavior. It does not explicitly state when NOT to use it or name the alternative consult paths, so it stops short of the top band.

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