TunnelMind Data API

sigil_verify_supply_path

The core Sigil pre-bid call. Submit a supply path; Sigil composes its individual checks into one trust verdict and returns a signed sigil_token the agent can attach to its bid as proof of verification.

Checks composed:

ads_txt — exchange authorized in the publisher's ads.txt.
datacenter_ip — is the IP a datacenter posing as a real user.
fraud_signals — is the IP in Scry's attacker-intelligence corpus.
bundle_verified — does the app bundle exist in its store.
domain_authenticity / entity_reputation — reserved, not evaluated in v1.

Each evaluated check yields pass/warn/fail; trust_score is their weighted mean (override weights per request); verdict is pass/warn/fail/unknown (override thresholds).

PRIVACY: ip_address is used for lookup only — never logged, never stored, never placed in the sigil_token. geo is accepted but unused.

Returns: trust_score (0-1 or null), verdict, checks, recommendations, sigil_token (signed, 5-minute lifetime). Overriding weights or thresholds still returns the score and verdict, but no token: sigil_token is null and token_withheld is custom_scoring.

Input Schema

Name	Required	Description
`ait`	No	Optional ATAP AIT id (`AIT-<uuidv7>`). When present, the `sigil_token` is bound to the AIT and a witness-tier `supply:verified` / `supply:rejected` event is chained onto it (when publisher_domain, exchange and seller_id are all given). Requires `Authorization: Bearer <holder_secret>` (issued once at AIT registration); nothing is appended without it. With an AIT, a present publisher_domain / exchange must be a bare domain and seller_id 1-128 characters, else 400. 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.
`buyer`	No	Optional. When present and the verdict is not `fail`, Sigil opportunistically records a `buys_through` edge linking the buyer entity to the resolved DSP. Side-effect persistence only — never affects the verdict or response shape, silent on every failure path. Requires `entity_slug` plus one of `dsp_domain` / `dsp_id`.
`receipt`	No	When true, attach a signed Receipt v1.0 committed to the transparency log. Additive — the response shape is otherwise unchanged, and a signing failure never costs you the verdict (ADR-014).
`weights`	No	Per-check weight overrides
`thresholds`	No	{ pass, fail } verdict cutoffs
`supply_path`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

addedInput schema / properties / ait

Added value: +{
+  "description": "Optional ATAP AIT id (`AIT-<uuidv7>`). When present, the\n`sigil_token` is bound to the AIT and a witness-tier\n`supply:verified` / `supply:rejected` event is chained onto\nit (when publisher_domain, exchange and seller_id are all\ngiven). Requires `Authorization: Bearer <holder_secret>`\n(issued once at AIT registration); nothing is appended\nwithout it. With an AIT, a present publisher_domain /\nexchange must be a bare domain and seller_id 1-128\ncharacters, else 400.\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",
+  "example": "AIT-0192f5d3-2c1e-7af6-bd84-9c4a3e8b7d12",
+  "type": "string"
+}

Changed1 schema field changedAug 6, 2026

addedInput schema / properties / receipt

Added value: +{
+  "default": false,
+  "description": "When true, attach a signed Receipt v1.0 committed to the transparency log. Additive — the response shape is otherwise unchanged, and a signing failure never costs you the verdict (ADR-014).",
+  "type": "boolean"
+}

First observedMay 25, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations to lean on, the description carries the full burden and does so richly: it discloses the privacy contract (ip_address never logged/stored/not in the token; geo accepted but unused), the 5-minute token lifetime, that overriding weights/thresholds withholds the token (token_withheld=custom_scoring), the opportunistic buyer side-effect that never alters the verdict, and the additive receipt behavior. This is exactly the extra behavioral context an agent needs and cannot get 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.

Conciseness4/5

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

Front-loaded with the core purpose, then organized into checks, scoring semantics, privacy, and returns. Length is justified by the number of distinct behaviors (AIT auth, custom scoring, receipts, side effects), though the AIT paragraph is dense and the bulleting of reserved checks adds minor bulk.

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?

With no output schema, the description explicitly enumerates the return fields (trust_score, verdict, checks, recommendations, sigil_token) and their null/withheld conditions. Combined with auth requirements, rate-limit tier, and error codes for AIT misuse, nothing material is missing for a 6-parameter nested tool.

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 high (83%), so the baseline is 3, but the description adds real semantics beyond the schema: it explains that weights/thresholds overrides still yield a score and verdict but suppress the token, that buyer persistence is silent-on-failure, and that receipt is purely additive. It does not restate schema field syntax, which is appropriate.

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?

States a specific verb (submit a supply path) and a precise resource outcome: composing individual checks into one trust verdict plus a signed sigil_token. It implicitly distinguishes itself from the single-check siblings (sigil_verify_ads_txt, sigil_verify_ip_type, sigil_verify_app_bundle) by framing itself as the composed 'core pre-bid call', but it never names the nearest sibling sigil_verify_supply_chain explicitly, so sibling routing relies on inference.

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 phrase 'core Sigil pre-bid call' implies the usage context (verification before bidding), and the composition list hints at when to prefer this over individual checks, but no alternative is named and no when-not guidance is given. Usage is 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 tools Inspect

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

Need Help?