Skip to main content
Glama

TunnelMind Data API

by ai.tunnelmind

sigil_verify_ads_txt

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_chain: true and the matched entry is RESELLER — then it carries the sellers.json cross-check for the seller.

  • warnings: actionable flags, e.g. publisher_not_in_corpus, publisher_has_no_ads_txt, seller_type_mismatch, ads_txt_cache_stale.

Cost:

  • Counts as one request against the daily rate limit.

Latency:

  • Typical: <50ms (single cache lookup, no outbound fetch). p99: <120ms.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
receiptNoWhen 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).
seller_idYesPublisher's seller/account ID at the exchange
seller_typeNoOptional — checked against the ads.txt entry
resolve_chainNoWhen true, a matched RESELLER entry is cross-checked against the exchange's sellers.json
exchange_domainYesExchange/SSP domain as listed in ads.txt
publisher_domainYesPublisher domain (www. prefix and scheme stripped)

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries full burden and delivers richly. It discloses that this is a cached lookup (not live fetch), fast, adds no latency, and explains behavior for edge cases (null when ads.txt unavailable), seller_type mismatch warnings, resolve_chain cross-checking, and stale cache provenance. It even adds cost and latency expectations.

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

Conciseness5/5

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

The description is long but perfectly structured with clear sections (Purpose, Use/Don't use, Inputs, Returns, Cost, Latency). Every sentence adds necessary information—no filler. The front-loading of the purpose ensures immediate comprehension, and the bullet-style formatting aids scanning.

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?

Without an output schema, the description fully explains all return fields (verified, confidence, seller_entry, provenance, reseller_chain, warnings) with semantics. It also covers failure modes, actionable warnings, cost, and latency, making it complete for a tool with this complexity (6 params, nuanced behavior).

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

Parameters5/5

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

Despite 100% schema coverage, the description adds substantial semantic value beyond the schema. It explains that www. prefix and scheme/path are stripped, seller_id is 'matched exactly', seller_type mismatch is 'reported as a warning', and resolve_chain does 'one authoritative hop' against sellers.json. These clarifications are not present in the schema and are crucial for correct invocation.

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 opens with a specific, unambiguous statement: 'Confirms whether an SSP/exchange is authorized to sell a publisher's inventory according to that publisher's ads.txt.' The verb+resource structure clearly identifies the tool's function, and the scope (cache lookup, pre-bid verification) distinguishes it from sibling tools like sigil_verify_ads_txt_batch and sigil_verify_supply_chain.

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

Usage Guidelines5/5

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

Explicit 'Use this tool when' and 'Do NOT use this tool when' sections provide clear context for invocation versus alternatives. It names Sigil P31 for supply-path trust scores and get_domain for tracker data, giving concrete exclusions and alternatives. This is above-and-beyond guidance.

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