Skip to main content
Glama

TunnelMind Data API

intel_optout

Checks a domain for all known AI training data opt-out mechanisms beyond robots.txt: TDM (Text and Data Mining) reservation headers, <meta name="ai"> tags, Creative Commons NonCommercial licenses, and other machine-readable opt-out signals.

Use this tool when:

  • You need to determine whether a domain has opted out of AI training data collection.

  • You are checking compliance before using a domain's content in a training dataset.

  • You want a comprehensive opt-out status (robots.txt + TDM + meta tags combined).

Do NOT use this tool when:

  • You only need robots.txt crawler policy — use intel_robots instead (faster).

  • You need tracker data — use get_domain instead.

  • You want injection risk assessment — use intel_inject instead.

Inputs:

  • domain (query, required): Domain to probe.

Returns:

  • tdm_reservation: true if the domain sends a TDM-Reservation: 1 header.

  • noai_meta: true if the HTML contains <meta name="robots" content="noai">.

  • license_detected: string if a CC NonCommercial or similar license is detected, otherwise null.

  • opted_out: true if any opt-out signal is present.

Cost:

  • Free. No API key required.

Latency:

  • Typical: 2-4s, p99: 7s.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asyncNoWhen true, return a task handle immediately instead of blocking. Poll get_task for the result.
domainYes
receiptNoWhen true, attach a signed Receipt v1.0 committed to the transparency log. Additive — a signing failure never costs you the observation (ADR-014).

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided, so the description carries the full burden. It discloses cost, latency (typical and p99), and the exact output fields. It implies a read-only check (no mutation implied). Missing minor details like rate limits or error behavior, but for a simple probe tool this is strong transparency.

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?

Well-structured with clear sections (purpose, when to use, when not, inputs, returns, cost, latency). The text is longer than a bare-bones description but every line earns its place, and the format makes it easy to scan. Slightly verbose for a simple lookup, but justified by the need to explain the different opt-out signals.

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?

No output schema is present, so the description fully compensates by listing and explaining each return field (tdm_reservation, noai_meta, license_detected, opted_out). It also covers cost, latency, and alternatives. For a tool of this complexity, the description is complete enough for an agent to invoke and interpret results without further context.

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 already describes async and receipt parameters (67% coverage); description only repeats 'domain: Domain to probe' without adding semantic detail beyond the example in the schema. The description does clarify the domain is the probe target, but this is minimal added value given schema coverage is already moderate.

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 states a specific verb+resource ('Checks a domain for all known AI training data opt-out mechanisms') and clearly enumerates the signal types (TDM headers, meta tags, CC licenses). It explicitly distinguishes from sibling tools like intel_robots and intel_inject, making the purpose unmistakable.

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?

Provides explicit 'Use this tool when' and 'Do NOT use this tool when' sections with named alternatives (intel_robots, get_domain, intel_inject). This is the gold standard for usage guidance, telling the agent not just when but when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

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