TunnelMind Data API

Retrieves the target domain's `robots.txt` file and parses it for AI crawler disallow rules. Specifically detects policies for known AI crawlers (GPTBot, ClaudeBot, CCBot, Bytespider, etc.) and returns a structured summary of the crawling policy. Use this tool when: - You need to know whether a domain has opted out of AI training data collection. - You want to check if a specific AI crawler is blocked before citing the domain. - You are building a dataset of AI-accessible vs AI-blocked domains. Do NOT use this tool when: - You want training opt-out signals beyond robots.txt (TDM reservation, noai meta) — use `intel_optout` instead. - You want the full technology stack — use `intel_stack` instead. - You need tracker database data — use `get_domain` instead. Inputs: - `domain` (query, required): Domain to probe. Returns: - `robots_txt_found`: false if the domain returned 404 or the file is empty. - `ai_crawlers_blocked`: list of AI crawler user-agent names that are disallowed. - `all_blocked`: true if `User-agent: *` with `Disallow: /` is present. - `raw`: first 4096 characters of the robots.txt file. Cost: - Free. No API key required. Latency: - Typical: 1-2s, p99: 6s.

Fetches up to 32KB of the domain's HTML and response headers from the edge, then fingerprints the content for known CMS platforms, JavaScript frameworks, CDN providers, and analytics tools. Detection is based on meta generator tags, script src patterns, response headers, and cookie names. Use this tool when: - You need to know what CMS (WordPress, Drupal, Shopify) a site runs. - You are assessing a domain's infrastructure before a security review. - You want to identify analytics or marketing tools a site embeds. Do NOT use this tool when: - You want HTTP headers and security posture — use `intel_http` instead. - You want tracker database classification — use `get_domain` instead. - You need robots.txt AI policy — use `intel_robots` instead. Inputs: - `domain` (query, required): Domain to fingerprint. Returns: - `cms`: detected content management system, or null. - `frameworks`: JavaScript/backend frameworks detected. - `cdn`: CDN provider detected, or null. - `analytics`: analytics and tracking tools detected. - `meta_generators`: raw meta generator tag values. Cost: - Free. No API key required. Latency: - Typical: 2-4s (HTML fetch), p99: 7s.

One public search over the receipt sources, newest first. Not `/v1/search` (that is the domain search). Use this tool when: - you want to find a TunnelMind change by ref, kind or summary. - you want one newest-first view of TunnelMind's changes and the attested tollbooth commons. - you want a past day's signed station-health rows (`source=weather-health`). Three public sources, and only these: - `changes` — the receipts ledger, lens `config` with `change:*` and `toolset:*` subjects (the same set as `GET /v1/changes`; a `kind` narrows it to one), mapped like `GET /v1/changes` so a row reads as a change, not a hash. - `commons` — tollbooth receipts from attested sites only. - `weather-health` — the signed station-health rows (lens `wx-health`), read from the public weather relay one CLOSED UTC day at a time. Every row is verified under the pinned weather key; a day that fails verification degrades the whole source. No row from the open (current) UTC day enters: the live 5-minute answer is `station_health` (`GET /v1/weather/station/{icao}/health`). The default view (no `source`) is `changes` + `commons` only and makes no relay call; weather-health rows appear only with `source=weather-health`. API-verdict receipts (cross_lens, preflight, scry, self, …) are NOT public: ADR-010 keeps them hashes-only, so they are not in this ledger. The weather-health rows are not API-verdict receipts: they are TunnelMind's own judgements over public NWS observations, already public on the relay. Searchable, NOT downloadable: `limit` is at most 100, there is no NDJSON, no `format=` and no day dump. Bulk goes through the tollbooth export. Changes rows carry public fields only — no receipt body, no `customer_id`. Commons rows carry the signed tollbooth document verbatim (`receipt`, or `receipt_unreadable: true` when the stored document does not parse). Weather-health rows carry the signed health receipt verbatim (`receipt`) with its `day`, `station`, `verdict`, `rules…

Returns a paginated list of domains from the tracker database. Results are ordered alphabetically by domain name and support cursor-based pagination for full traversal. Filtering by category and minimum score allows targeted data extraction. Use this tool when: - You want to enumerate all known ad-tech or analytics domains above a risk threshold. - You need a dataset of tracker domains for offline analysis. - You are paginating through a category to build a block list. Do NOT use this tool when: - You need data for a specific domain — use `get_domain` instead. - You are searching by keyword — use `search` instead. - You want domains belonging to a specific company — use `get_entity` instead. Inputs: - `category` (query, optional): Filter by surveillance category. One of: `ad_tech`, `analytics`, `social`, `fingerprinting`, `content`, `cdn`, `other`. - `min_score` (query, optional): Integer 0-100. Exclude domains scoring below this value. - `limit` (query, optional): Number of results per page. Max 100 (paid), 20 (free). Default 50. - `cursor` (query, optional): Pagination cursor from the previous response's `next_cursor` field. Returns: - Array of domain list items (domain, category, score, prevalence, entity summary). - `meta.has_more`: true if more pages exist. - `meta.next_cursor`: pass as `cursor` to get the next page. - `meta.count`: number of results in this page. Cost: - Free tier: up to 20 results/page. Anonymous (no key): 10/min, 100/day. Free key: 50/day. Pro/enterprise: up to 100 results/page, included in plan. Latency: - Typical: <200ms, p99: <500ms.

Returns a paginated list of corporate entities in the TunnelMind surveillance database. Includes data categories, estimated data value, and industry classification. Useful for enumerating the surveillance ecosystem by sector. Use this tool when: - You want to enumerate all entities in a specific industry (e.g., all ad-tech companies). - You need a dataset of surveillance entities for analysis or reporting. - You are building a comprehensive surveillance landscape map. Do NOT use this tool when: - You need the full profile of a specific entity — use `get_entity` instead. - You are searching by entity name — use `search` instead. - You need domain-level data — use `list_domains` instead. Inputs: - `industry` (query, optional): Filter by industry classification. Examples: `ad_tech`, `analytics`, `data_broker`, `social`, `crm`. - `limit` (query, optional): Results per page. Max 100 (paid), 20 (free). Default 50. - `cursor` (query, optional): Pagination cursor from previous response's `next_cursor`. Returns: - Array of entity list items (slug, name, parent_company, industry, data_categories, data_cost_usd). - `meta.has_more` and `meta.next_cursor` for pagination. Cost: - Free tier: up to 20 results/page. Anonymous (no key): 10/min, 100/day. Free key: 50/day. Pro/enterprise: up to 100 results/page, included in plan. Latency: - Typical: <150ms, p99: <400ms.

Returns the caller's active and inactive subscriptions (signing_key redacted). Requires an API key.

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.

At least one of `ip`, `domain` or `entity` is required. Call this before routing traffic, bidding on inventory, or trusting a counterparty. It fuses ALL THREE TunnelMind lenses for one subject — Scry (attacker intelligence + threat feeds + open ports), Sigil (ad-supply-chain position + trust score + ATAP witness count), and Tracker (DDG/IAB catalog + prevalence + categories) — into a single confidence-scored profile plus a signed P38 receipt. The `cross_lens.hits` field tells you if the same infrastructure appears in attack data AND supply-chain data — that's your highest-confidence signal, and the one no siloed competitor can give you. `cross_lens.flags` surfaces the actionable highlights (`cross_lens_overlap:scry+sigil`, `in_threat_intel:...`, `high_prevalence_tracker`, `corroborated_by_N_lenses`). Confidence weighting: each lens contributes a base score; a 1.5× multiplier applies when ≥2 lenses corroborate the same subject; and the Scry contribution is weighted by the attestation tier of the sensors that observed it (silicon_root 1.0 → self_asserted 0.5). Bounded [0,1] and carried into the receipt. Unlike `cross_lens_verify` (one node → one verdict) and `cross_lens_lookup` (one node → raw three-lens view), profile_entity takes the SUBJECT as any combination of ip / domain / entity and returns the richest fused detail for a pre-transaction decision. At least one of ip / domain / entity is required.

Proves the log at size `second` is an append-only extension of the log at size `first` — history was never rewritten. Returns both roots and the proof path. Verify offline with `scripts/verify-log.mjs consistency <proof.json>`.

Proves a specific receipt (by unified `receipt_id`, lens alias, or raw `leaf_index`) is included in the tree at `tree_size` (default: the latest STH's). Returns `leaf_hash`, the `audit_path`, the recomputed `root_hash`, and the matching STH. What this proves: the receipt in your hand is byte-identical to the one sequenced into the log — not that the observation inside it was correct (ADR-010). Verify offline with `scripts/verify-log.mjs inclusion <proof.json>`.

P72 RFC 6962 transparency log over the unified receipt ledger (ADR-010). The STH commits to the entire log: `tree_size`, `root_hash` (`0x` + SHA-256), `timestamp`, and an Ed25519 signature (with `key_id` and embedded public key) over the RFC 8785 canonicalization of the body. Hashes only — receipt bodies are never on this surface. Verify offline with `scripts/verify-log.mjs sth` (zero TunnelMind library code) against the published receipt-signing key.

P72 unified receipt ledger (ADR-010): every receipt-issuing surface (cross-lens verify, tracker verify, verdict, profile, explain, GhostRoute, Sigil/ATAP, compliance export) records the exact signed document it returned, keyed by one ID space. Use this tool when: - An agent holds a receipt and wants to confirm TunnelMind logged it (existence + canonical hash) before trusting it in an audit trail. - The owning customer wants to re-fetch a receipt body by id. Inputs: - `id` (path, required): the unified `receipt_id` (UUIDv7, `GR-YYYY-NNNNNNN`, or `ATAP-RCPT-…`) or a lens-native alias. Returns: - Always: `receipt_id`, `lens`, `payload_hash` (`0x` + SHA-256 of the RFC 8785 canonicalization of the stored document), `key_id`, `attestation_strength`, `issued_at`, and `leaf_index` (null until the transparency-log sequencer enrolls the row). - Owner only (authenticated caller matching the receipt's customer): `subject` and the full stored `receipt` document. Receipt bodies are never public. Cost: - Counts as one request against the daily rate limit. Latency: - Typical: <300ms (one Supabase read).

Permanently deactivates the API key used to make this request. This action is irreversible. After revocation, the key will return 401 on all subsequent calls. Use this tool when: - You want to rotate your API key (revoke old, then provision a new one). - You believe your key has been compromised. Do NOT use this tool when: - You want to check quota — use `get_api_key` instead. - You intend to keep using the API — this is permanent. Inputs: - No body or query parameters. Auth is from the `Authorization: Bearer` header. Returns: - `revoked`: true. - `note`: confirmation that the key is permanently revoked. Cost: - Free. Does not count against the daily request limit. Latency: - Typical: <150ms, p99: <400ms.

Runs a curated signature corpus over a piece of untrusted text — content an agent is about to consume, a retrieved document, a tool result, an email body — and returns the matched injection patterns plus a bounded 0..1 risk score. This is a signal, never a policy decision: the caller decides what to do with a flagged input. Detected classes: instruction_override (ignore/override previous rules), role_reassignment (you are now DAN / developer mode), exfiltration (leak the system prompt or a secret to a URL), tool_smuggling (covertly invoke a tool, delete/destroy data), boundary_spoof (fake system/assistant turn delimiters). Input is normalized first to blunt cheap evasions (zero-width characters, smart quotes, whitespace padding). Use this tool when: - You are an agent about to feed retrieved or third-party text into a model and want to check it for embedded instructions first. - You are triaging why a tool description or web page looks suspicious. Do NOT use this tool when: - You want a trust verdict on a domain or entity — use `cross_lens_verify`. - You want to scan a whole MCP server's tools — use `scan_mcp`. Inputs: - `text` (body, required): the untrusted text to scan. Max 200,000 chars. Returns: - `flagged`: true if any signature matched. - `score`: bounded 0..1 risk score (saturating — one high-severity hit is already strongly flagged; many hits approach but never exceed 1). - `severity_max`: highest severity among matches (`high`/`medium`/`low`) or null. - `classes`: distinct injection classes matched. - `matches`: each matched signature `{ id, class, severity, excerpt }`. Cost: - Free. No API key required. Pure edge computation, no external calls. Latency: - Typical <20ms.

Connect to a caller-supplied MCP server (Streamable-HTTP transport), read its advertised tools, and run the injection corpus over every tool name / description / input schema — plus a capability heuristic that flags broad, dangerous powers (shell execution, filesystem write, credential access, arbitrary network, destructive DB ops). Returns a per-tool safety report. A caution to review, never a verdict. This is a single-target, caller-initiated scan. It is NOT a crawler and does not follow links or enumerate other servers. The target must be https on port 443 or 8443 at a public hostname: IP literals (in any encoding), loopback / private / internal / special-use names, and credentials in the URL are rejected, and every redirect hop is checked against the same rules. Replies are read for at most 5 s and 1 MB. Use this tool when: - You are about to connect an agent to a third-party MCP server and want to inspect its tools for embedded instructions or excessive powers first. Do NOT use this tool when: - You only have a blob of text — use `scan_injection`. - You want a trust verdict on a domain or entity — use `cross_lens_verify`. Inputs: - `url` (body, required): the MCP server endpoint (https, port 443 or 8443). Returns: - `server`: `{ name, version }` reported by the server, if any. - `tools_scanned`: number of tools inspected. - `flagged_count`: tools with an injection hit or a flagged capability. - `risk`: worst per-tool risk across the server (`high`/`medium`/`low`/`none`). - `score`: max injection score across tools (0..1). - `tools`: per tool `{ name, risk, injection{...}, capabilities[] }`. Cost: - Free. No API key required. Rate-limited like every anonymous route (10/min, 100/day per IP; more with a key). Latency: - Bounded by the target server's handshake; typically <2s.

Searches both the domains table and the entities table simultaneously. Returns matching domains (by domain name) and entities (by name or slug) in a single response. Minimum 2 characters, maximum 100 characters. Use this tool when: - You have a partial name and need to identify what tracker or entity it belongs to. - You want to find all TunnelMind records related to a company name like "Google" or "Oracle". - You are resolving an ambiguous domain (e.g., does `criteo.com` appear in the tracker DB?). Do NOT use this tool when: - You know the exact domain — use `get_domain` instead (faster, more complete). - You know the exact entity slug — use `get_entity` instead. - You want to browse by category or industry — use `list_domains` or `list_entities`. Inputs: - `q` (query, required): Search string, 2-100 characters. Matched against domain names and entity names/slugs. Returns: - `domains`: array of matching domain records (list item format). - `entities`: array of matching entity records (list item format). - Both arrays may be empty if no matches found. No pagination — results are capped at 20 per type. Cost: - Anonymous (no key): 10/min, 100/day. Free key: 50/day. Pro/enterprise: included in plan. Latency: - Typical: <200ms, p99: <500ms.

Returns a publisher's ads.txt change log — one entry per crawl in which its authorized-seller set changed. A publisher quietly adding a reseller line is a real fraud signal; this is how a buyer audits supply over time. Inputs: - `domain` (path, required): publisher domain. - `since` (query, optional): ISO date / date-time lower bound on `observed_at`. - `limit` (query, optional): max entries — default 50, max 200. Returns `changes[]`, newest first — each with `observed_at`, `added_count`, `removed_count`, `additions`, `removals`, `directive_changes`.

Returns an AIT's status, chain head hash, event count, pending-event count, per-tier event counts, and the anchored-bid coverage ratio.

Registers an ATAP v0.1 AIT for a media-buying agent under the `sigil:media_buyer:v1` profile. Sigil validates the capability set and constraints against the published profile, signs the AIT as the witness (`OAI-2026-0000201`), stores it, and returns the signed token. Sigil is the ATAP witness — there is no kernel observer. See https://github.com/TunnelMind/atap-profiles. The response carries `holder_secret` **once** (32 random bytes, base64url; only its SHA-256 is stored). It is what every later write to this AIT — `sigil_atap_witness`, `sigil_atap_roll_block`, `sigil_receipt_generate` — must present as `Authorization: Bearer`. Lose it and the AIT is frozen; register a new one. `operator_status` is `asserted`: Sigil signs the AIT but does not verify that the holder controls the operator OAI it names.

Rolls every not-yet-blocked Witness Event for an AIT into one signed ATAP Attestation Block with a profile `period_summary`, chained onto the prior block. **Holder authentication (2026-10-16).** Writes to an AIT's chain require `Authorization: Bearer <holder_secret>`, the secret `sigil_atap_register_ait` returns once. 401 without it, 403 if it does not match. AITs registered before holder authentication have no secret and are frozen for writes (403): register a new AIT to continue.

Ingests one agent-reported event (`bid:submitted`, `bid:won`, `bid:lost`, `budget:decremented`) into an AIT's hash-chained attestation log. Sigil validates the payload (rejecting any PII per ATAP §7.6), classifies the evidence tier — `anchored` if a `bid:submitted` cites a valid Sigil token issued for this AIT and matching the bid's supply path, otherwise `asserted` — derives any `constraint:violated` events, then chains and signs each event. `supply:verified` / `supply:rejected` are witness-emitted by `sigil_verify_supply_path`, never accepted here — that is what makes the `witnessed` tier non-bypassable. **Holder authentication (2026-10-16).** Writes to an AIT's chain require `Authorization: Bearer <holder_secret>`, the secret `sigil_atap_register_ait` returns once. 401 without it, 403 if it does not match. AITs registered before holder authentication have no secret and are frozen for writes (403): register a new AIT to continue.

Assembles the ATAP v0.1 §7.5 Receipt ZIP for an AIT — the signed Receipt (`manifest.json`), the AIT, the Attestation Block chain, the witness public key, a tier-graded `summary.json`, the bundled `verify.sh` reference verifier, and the witness events + sigil_tokens as profile artifacts. Any pending events are rolled into a final block first. The ZIP verifies offline — unpack it and run `verify.sh`; keys are at https://tunnelmind.ai/atap/keys. The summary grades every event as `witnessed`, `anchored`, or `asserted` and reports the anchored-bid coverage ratio. **Holder authentication (2026-10-16).** Writes to an AIT's chain require `Authorization: Bearer <holder_secret>`, the secret `sigil_atap_register_ait` returns once. 401 without it, 403 if it does not match. AITs registered before holder authentication have no secret and are frozen for writes (403): register a new AIT to continue.

Scores up to 200 entities in one round-trip — built for agents evaluating many supply sources during campaign setup. Per-item parse failures (e.g. a bad domain) are returned inline, with one exception: a malformed `app_bundle` id rejects the whole batch with 400. An optional `weights` object re-weights every entity in the call. Cost: - Each entity costs one rate-limit unit (the first is the request itself). A batch larger than the remaining budget is refused whole with 429 and charges nothing beyond that first unit, so the effective maximum per call is min(200, remaining + 1): anonymous 10/min, free 50/day, supporter 500/day, pro 5,000/day, enterprise unlimited.

Returns the pre-computed 0.0–1.0 trust score for one entity, its component breakdown, and the 14-day trend. Scores are refreshed daily by a database job — this endpoint never recomputes from raw data, so it is fast and deterministic. `entity_id` is `{entity_type}:{key}` — e.g. `publisher:nytimes.com` or `ssp:pubmatic.com`. Entity types: `publisher`, `ssp`, `dsp`, `app_bundle` (publishers and SSPs are scored today). v1 evaluates structural components only (`ads_txt_health`, `supply_chain_directness`, `historical_stability` for publishers; `supply_reach`, `directness` for SSPs). The `not_evaluated` list names spec components without an enrichment path yet. Optional `weights` query param (URL-encoded JSON) re-weights the stored components for this call.

Returns the active, versioned default weights used to combine an entity's trust-score components, plus the list of spec components that are not yet evaluated. Pass a custom `weights` object to `sigil_score_batch` to re-weight without changing the defaults.

Reconstructs the supply paths for a publisher domain from Sigil's own crawl and returns them ITEMIZED — distinct from `sigil_verify_supply_chain` (which verifies a schain the caller brings) and from `signal_dark_pool_risk` (which returns only aggregate counts). Every SSP the publisher declares it sells through is joined to that SSP's identity and classified two-sided against the SSP's sellers.json: `corroborated` (seat present), `contradicted` (SSP crawled but seller_id absent — real risk), `unchecked` (SSP not yet crawled — not risk). Each returned path also carries `resells_to`, one level of downstream reseller expansion. The list is ordered riskiest-first (contradicted, then reseller) so a truncated page is still the most useful; the `supply_paths` counts are always over the FULL set. `in_supply_graph:false` when the domain is not a known publisher.

Confirms whether an SSP/exchange is authorized to sell a publisher's inventory according to that publisher's ads.txt. This is a cache lookup against ads.txt files crawled daily across the top 10,000 publisher domains — it does NOT fetch the publisher's ads.txt live, so it is fast and adds no latency to a real-time bidding decision. Use this tool when: - You are an ad-buying agent and want to confirm, pre-bid, that a supply path (publisher → exchange → seller_id) is legitimate. - You are detecting domain spoofing or unauthorized resale in a bid stream. - You want to check whether a seller is listed DIRECT or RESELLER. Do NOT use this tool when: - You want a full supply-path trust score — that endpoint is Sigil P31. - You want surveillance tracker data for the domain — use `get_domain`. Inputs: - `publisher_domain` (body, required): Publisher domain, e.g. `nytimes.com`. A `www.` prefix and scheme/path are stripped automatically. - `exchange_domain` (body, required): The exchange/SSP domain as it appears in ads.txt, e.g. `google.com`, `amazon-adsystem.com`. - `seller_id` (body, required): The publisher's seller/account ID at that exchange, e.g. `pub-4177862836555934`. Matched exactly. - `seller_type` (body, optional): `DIRECT` or `RESELLER`. When supplied it is checked against the ads.txt entry; a mismatch is reported as a warning. - `resolve_chain` (body, optional): When true, a matched RESELLER entry is cross-checked against the exchange's sellers.json (one authoritative hop). Returns: - `verified`: true (entry found), false (confidently not listed), or null (ads.txt could not be retrieved — indeterminate). - `confidence`: `high` | `degraded` | `low` | `unknown`. - `seller_entry`: the matched ads.txt line (line number, raw text, parsed fields) when `verified` is true; otherwise null. - `ads_txt_parse_status`, `ads_txt_last_parsed`, `stale`: provenance of the cached crawl this answer is derived from. - `reseller_chain`: empty unless `resolve_cha…

Runs up to 100 ads.txt verifications in a single call — the endpoint an ad-buying agent uses for pre-bid checks across a whole campaign's supply. Each item is the same shape as `sigil_verify_ads_txt`. Per-item validation failures are reported inline; the batch never fails as a whole. Publisher records are fetched once per unique domain. Use this tool when: - You are evaluating many supply paths at once (campaign setup, SPO sweep). - You want one round-trip instead of N calls to `sigil_verify_ads_txt`. Inputs: - `items` (body, required): Array of 1–100 verification requests, each `{ publisher_domain, exchange_domain, seller_id, seller_type? }`. - `resolve_chain` (body, optional): Applies to every item — when true, a matched RESELLER entry is cross-checked against the exchange's sellers.json. Returns: - `count`: number of result entries (matches `items` length, in order). - `verified_count`: how many resolved to `verified: true`. - `results`: array aligned to `items`. Each entry is either a verification result with `ok: true` and `input_index`, or `{ ok: false, input_index, error, message }` for an invalid item. Cost: - Each item costs one rate-limit unit (the first is the request itself). A batch larger than the remaining budget is refused whole with 429 and charges nothing beyond that first unit, so the effective maximum per call is min(100, remaining + 1): anonymous 10/min, free 50/day, supporter 500/day, pro 5,000/day, enterprise unlimited. Latency: - Typical: <150ms. With `resolve_chain: true`, add one sellers.json fetch per unique exchange (edge-cached 12h after the first fetch).

Reports whether a domain publishes ads.cert (IAB Tech Lab Authenticated Connections) DNS records — a readiness signal showing the domain supports cryptographically authenticated ad-tech connections. This is not signature verification: ads.cert is pairwise, so verifying a signed bid request requires Sigil to be a delegated participant (a future build). DNS-only and stateless. Inputs: - `domain` (query, required): Domain to check. Returns: - `adscert_ready`: true | false | null (DNS lookup failed). - `adscert_records`: TXT values at `_adscert.{domain}`. - `delegation_records`: TXT values at `_delegated._adscert.{domain}`.

Verifies that a mobile or CTV app bundle ID actually exists in the relevant app store — used to detect bundle spoofing in bid requests. Platform support (v1): - `ios`: verified live via Apple's iTunes Lookup API. - `android`: verified live via the Google Play store listing page. - `ctv_*` / `web`: no public store API — returns verified=null. Inputs: - `bundle_id` (body, required): e.g. `com.nytimes.NYTimes`. - `platform` (body, required): ios | android | ctv_roku | ctv_fire | ctv_samsung | ctv_lg | ctv_vizio | web. - `claimed_developer` (body, optional): checked against the store listing. Returns: - `verified`: true | false | null. null means one of two things: the platform has no store API (confidence `low`, warning `no_store_api_available`), or the store lookup failed (confidence `degraded`, warning `store_api_unavailable`, with `reason`). - `reason`: why the store lookup failed — http_<status> | timeout | network_<error name> | bad_response. Present only on the degraded path. When the relay was also tried and failed it is `<worker reason>+relay_<relay reason>`, e.g. `http_403+relay_timeout`. - `source` (iOS only): `worker` | `relay`. When the Worker's own iTunes lookup ends in http_403, http_429 or network_* and the relay is configured, the lookup is retried once through TunnelMind's relay; `relay` means the relay was consulted (success or failure). - `store_listing`: name, developer, developer_match, store_url.

Confirms a publisher controls a domain by checking for a DNS TXT record the owner publishes under `_tunnelmind.{domain}`. A DNS record can only be set by whoever controls the zone, so its presence proves control — a stronger signal than ads.txt, which is just a file anything in the request path can serve. Use this tool when: - You want proof a publisher actually owns the domain it claims. - You are distinguishing publishers who have opted into Sigil verification. Inputs: - `domain` (query, required): Publisher domain. `www.` and scheme stripped. Returns: - `verified`: true (record found), false (absent), or null (DNS lookup failed). - `expected`: the exact TXT record the owner must publish to verify. - `found_records`: TXT values currently present at `_tunnelmind.{domain}`. - `checked_at`: ISO 8601 timestamp of the live DNS lookup. Cost: - Counts as one request against the daily rate limit. Latency: - Typical: <300ms (one DNS-over-HTTPS lookup).

Classifies an IPv4 or IPv6 address by network type — the high-value ad-fraud signal being datacenter traffic posing as residential or living-room (CTV) devices. IP→ASN resolution uses Team Cymru's public service; the ASN is then classified by its registered organization name. It also cross-references the Scry attacker-observation corpus to detect anonymizing EGRESS — the thing a rotating-residential proxy provider is built to hide. A residential- or mobile-looking IP that Scry has observed acting as a hostile actor is a residential-proxy exit node (home devices don't scan honeypots); tor and vpn egress are named outright. It also identifies the proxy COMPANY by network: if the IP's ASN belongs to a known VPN/anonymizing-egress provider (X4BNet's curated list), the verdict is `vpn` and `scry_signals` carries `vpn_provider_asn` — even when Scry has never observed the IP acting. Datacenter and residential proxy verdicts still require observed conduct. PRIVACY: the IP is used for lookup only — never logged, never stored. The Scry cross-reference is likewise a read-only corpus lookup. Inputs: - `ip` (query, required): IPv4 or IPv6 address. Returns: - `ip_type`: datacenter | residential | mobile | unknown. - `confidence`: high | medium | low. - `asn`, `asn_name`: the resolved autonomous system. - `proxy_suspected`: boolean — the IP is an anonymizing egress. - `proxy_type`: tor | vpn | residential_proxy | datacenter_proxy | null. - `scry_signals`: evidence strings from the corpus (actor_class, threat feeds, observation counts); empty when the IP is unknown to Scry. Latency: - Typical: 100-250ms (DNS + a parallel corpus lookup).

The bid-time contract. Pass the SupplyChain object from an OpenRTB bid request (`source.ext.schain`) verbatim, plus the originating site domain or app bundle. Sigil verifies, per node and in aggregate: - origin ads.txt — the publisher's ads.txt authorizes node[0] (asi + sid). - per node — the node's `asi` sellers.json declares the node's `sid`. - owner-domain — node[0]'s sellers.json seller `domain` matches the publisher's ads.txt OWNERDOMAIN / MANAGERDOMAIN (spec §3.5.1). - `schain.complete` — an incomplete chain caps the verdict at `warn`. OpenRTB field mapping: `site.domain` → `site_domain`; `app.bundle` → `app_bundle`; `source.ext.schain` → `schain`. An app_bundle origin's ads.txt check is `not_evaluated` pending app-ads.txt resolution. Returns a per-node result array, an aggregate `verdict` (pass/warn/fail/unknown), `recommendations`, and a signed `sigil_token`.

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`.

Verifies the authenticity and expiry of a `sigil_token` returned by `sigil_verify_supply_path`. Anyone can call this — no key needed; Sigil verifies the Ed25519 signature server-side. Tokens live 5 minutes. Returns `valid` (boolean), `reason` (when invalid: malformed / expired / bad_signature / unsigned), and the decoded `payload`.

Reconciles every sell path a publisher declares (`sells_through`) against each SSP's own sellers.json (`exchange_seat`) and keeps three classes strictly separate: `corroborated` (seat present), `contradicted` (SSP crawled but seller_id absent — real risk), and `unchecked` (SSP not yet crawled — excluded from risk, lowers confidence). Combined with publisher-side ads.txt opacity. Two-sided corroboration is the cross-lens moat — it catches unauthorized resale a one-sided ads.txt read cannot.

Scores an entity by the trust character of its neighbours — the SSPs its publishers sell through and the DSPs it buys through. Reports neighbour counts, mean/min neighbour trust, and how many neighbours are adversary-classified (P46). `derived.halo_score` (0–100, or null when no neighbour has a computed trust) is mean neighbour trust dragged down by adversary-neighbour share. Evidence about an entity's company, not a persisted verdict — no profile poisoning.

Surfaces other entities that operate as a coordinated team with this one: they share a NARROWLY-held direct seller account (2–8 entities — network house accounts shared by hundreds are separated into `house_accounts_excluded`, not counted) or co-own an exchange seat. `derived.team_signal` (0–100) is a coordination magnitude over teammate count, shared-account breadth, and co-owned seats.

Observed component counts first, a labelled derived roll-up second. The components — `data_categories`, supply-surface counts (ssp + publisher + dsp + owns_seat + buys_through), and corroborating `sources` — are facts. `derived.tracker_density` (0–100) is a weighted blend of those counts, not a measurement; `data_cost_usd` is deliberately excluded (non-zero only for a curated seed, so weighting by it would fabricate precision). Anchors the `surveillance_bigtech` adversary class for the cross-lens classifier.

The exact bytes the manifest's sha256 commits to. Content-Type `application/x-ndjson`; rows ordered by domain. Verify: `sha256(body) == manifest.sha256`.

JSONL diff vs the previous snapshot — apply +/~/- lines instead of re-pulling the corpus.

P4 corpus replication, the OPA "push data into the PDP" pattern. A daily snapshot of the domain corpus (domain, score, category, fingerprinting, entity) is published as deterministic JSONL with a manifest carrying row_count, sha256 over the exact bytes, a diff summary vs the previous day, and an Ed25519-signed Receipt v1.0 committed to the transparency log — a PDP that replicates the data can verify offline that it loaded exactly what was published. `date` is `YYYY-MM-DD` or `latest`. Retention: 14 days. Fetch the rows from `data_url`, apply increments from `diff_url` (`{"op":"+"|"~"|"-"}` per line), re-pull the full file when the manifest marks the diff truncated.

Signed station-health row for a settlement station; see /docs Live is paid, history is free. The live answer is a flat price via x402 when the answer is fresh. Every paid live answer is a signed row that also appears in the next UTC day's public file (`v1/health/<D>.jsonl` on the weather relay, searchable via `ledger_search` with `source=weather-health`), so anyone can check a paid answer for free the next day. A stale answer is always free (`verdict: stale` with a `reason`), including `live_token_missing` (the Worker has no live-relay token) and `relay_403` (the relay refused the live read).

One sample per 20-minute monitor sweep. `uptime_pct` is the share of sweeps in which every fail point was green (the strictest read); `per_monitor` lists only monitors that failed at least once in the window. History begins at feature deploy and is never extrapolated backwards — an empty window returns `uptime_pct: null`, not 100.

Opens a persistent SSE connection that emits events as the task progresses. The stream closes automatically when the task reaches a terminal state or after ~90 seconds (timeout). Heartbeat comments are sent every ~15 seconds to keep the connection alive through proxies. Event types: - `status` — emitted when status changes (pending → running → complete/failed) - `result` — emitted on `complete` with the full result payload - `error` — emitted on `failed`, `cancelled`, or `expired` with error info - SSE comment (`: heartbeat`) — keepalive, no data Use this tool when: - You want real-time progress without polling. - You are in an environment that supports SSE (EventSource API). Do NOT use this tool when: - You want a simple one-shot status check — use `get_task` instead. - Your HTTP client doesn't support streaming responses. Inputs: - `task_id` (path, required): 26-char ULID. Returns: - SSE stream (`text/event-stream`). Each event is `event: <type>\\ndata: <json>\\n\\n`. Cost: - Free. Counts as one request against rate limits when the stream opens. Latency: - First event: <200ms. Stream duration: up to 90s.

Close the loop: after you acted on a TunnelMind verdict, tell us how it went. Reports aggregate per node into an advisory second opinion that any caller can read back via `GET /v1/feedback/{node}`. Advisory only. In v0 a negative aggregate does NOT silently lower the fused trust score — it's a human-weighable signal beside the verdict, not an automatic reweight. Use this tool when: - You acted on a verdict and want to record the real-world outcome (honored, defrauded, no issue) to help future callers. Inputs: - `node` (body, required): the subject — ip, domain, asn, or entity slug. - `outcome` (body, required): one of `positive`, `negative`, `neutral`. - `receipt_id` (body, optional): the verdict receipt this outcome refers to. - `note` (body, optional): free-text context, max 500 chars. Returns the updated advisory aggregate `{ node, counts, total, score, signal }`. Cost: - Free. Requires an API key (authenticated callers only).

Free bulk read of the commons — the raw record is never paywalled. Every row is a tollbooth document exactly as its site signed it (Ed25519 over RFC 8785 JCS, key = the row's own `site`), wrapped in a `_commons` envelope naming the tier and vouching domain. Nothing in a row requires trusting TunnelMind. Use this tool when: - You want the raw record behind the stats, or to verify it yourself. - You are building your own exhibit or comparison over attested sites. Returns: - `rows[]`: `{_commons: {tier, domain, received_at}, receipt | snapshot}`. - `rows_returned`, `limit`, `capped` (true when the day has more than `limit`). Cost: - Counts as one request against the daily rate limit. Past days cached 1h. Latency: - Typical: <200ms cached; up to ~1s on a cache miss for a busy day.

Membership of the commons: every signing key that has reported, the domain that vouched for it (by serving the key in its /.well-known/tollbooth-site.json), and when it was last re-checked. Attested only by default; tier=all adds unattested keys with the domain they CLAIMED but that did not (yet) vouch for them. Use this tool when: - You want to know whose data is in the exhibit, or whether a given site reports. - You are verifying an export row's `site` key against a domain. Returns: - `sites[]`: site (public key), domain, status, attested_at, last_checked_at, first_seen_at. Cost: - Counts as one request against the daily rate limit. Latency: - Typical: <100ms.

The public read over the Conduct Log Commons: which agents knocked on attested tollbooth sites in the last 7 days, what they did when offered paid access, and what they would have paid. First-party monitors and credential-scanning recon are classified and EXCLUDED from the headline (reported separately, never conflated). Attested tier only — keys a domain has vouched for via /.well-known/tollbooth-site.json. Use this tool when: - You want to know how AI crawlers actually behave when a site asks them to pay. - You need the current commons membership (sites by tier) and the export pointers. Returns: - `headline`: agents, requests, would_have_paid_usd, robots_respecting_agents. - `named_ai` / `other` / `attack_recon`: per-agent rows with sampled paths. - `receipts`: identity-bearing conduct receipts by type. - `commons`: tier, sites {attested, unattested}, export + attest pointers. Cost: - Counts as one request against the daily rate limit. Not cached. Latency: - Typical: 300–1200ms (two D1 reads over the last 7 days).

The Tracker lens-owned verify surface: a per-node verdict over the normalized DDG Tracker Radar / IAB TCF / Disconnect.me corpus, with an optional signed TunnelMind Receipt v1.0. This is the single-lens ground truth the fused `POST /v1/verify` cites for its tracker block. Use this tool when: - You need to know whether a domain is tracking/surveillance infrastructure and which entity operates it, without the full cross-lens fusion. - You want a signed, offline-verifiable receipt for that single-lens answer. Inputs: - `node` (path, required): a domain (e.g. `doubleclick.net`) or an entity slug (e.g. `google`). IPs and ASNs are not indexable by this lens. - `receipt` (query, optional): `true` attaches a Receipt v1.0 envelope. Returns: - `tracking`: true (in the tracker corpus), false (queried, absent), or null (not answerable — ip/asn node or backend unavailable; see `reason`). - `tracker`: the lens record — domain {category, prevalence, score 0-100} plus operating entity {slug, name, parent_company, industry, sources}, or entity + top_domains when queried by slug. - `checked_at`: ISO 8601 timestamp of the corpus read. - `receipt`: TunnelMind Receipt v1.0 (Ed25519, JCS) when requested. Cost: - Counts as one request against the daily rate limit. Latency: - Typical: <100ms (one or two D1 reads at the edge).