TunnelMind Data API

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

Details authentication-based filtering, hash-chaining for tamper detection, offline verification procedure, cost (one request), and latency. No annotations provided, so description fully compensates.

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

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

Well-structured with sections and bullet points, but slightly verbose. Could be trimmed without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, behavior, parameters, return format (NDJSON, headers), and verification method. No output schema exists, but description provides sufficient context.

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

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

Explanation for all three parameters (from, to, limit) with defaults, ranges, and format. Schema has 0% coverage, so description adds full meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it returns NDJSON of audit log entries, describing the structure (operation, identity, hashes, signature, hash-chain). Distinguishes from sibling 'get_task' for status.

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

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

Explicitly lists when to use (tamper-evident recording, auditing, verification) and when not (anonymous, need status - use get_task).

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

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

No annotations provided, so description carries full burden. It discloses error conditions (409 for terminal state), identity restriction, cost (free), and latency (<150ms). However, does not explicitly state if cancellation is reversible, though implied by terminal state concept.

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

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

Well-organized with clear sections: purpose, usage guidelines, inputs, returns, cost, latency. Every sentence provides value; no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (one parameter, no output schema), the description covers all essential aspects: behavior, constraints, error handling, cost, and performance. Complete for an agent to use correctly.

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

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

While schema provides pattern for task_id, description adds that it's a path parameter and a 26-char ULID. With 0% schema description coverage, this adds significant meaning beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool marks a task as 'cancelled' and specifies conditions (terminal state conflict). It distinguishes itself from sibling tools like get_task and stream_task by focusing on the cancellation action.

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

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

Explicitly provides when to use (async probe no longer needed, free pending task) and when not to use (task already complete). Also mentions identity constraint (only creator can cancel).

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

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

With no annotations, description discloses rate limits, caching (60s edge-cached), latency expectations (<100ms typical), and response fields (revoked, revoked_at, reason, etc.). No contradictions.

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

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

Well-structured with sections (first sentence summary, bullet points for use cases, inputs, returns, cost, latency). Each sentence provides value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema or annotations, description fully explains return values, constraints, and performance. Covers all aspects needed for single-item lookup tool.

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

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

Schema coverage is 100% with descriptions and examples. Description adds value by stating the mutual exclusivity requirement ('Provide one of key_id or id'), which is not in schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Single-item revocation lookup per Receipt Format v1.0 §8.2', specifying the exact resource and action. Distinguishes from sibling tools like verify_receipt and get_receipt by focusing on revocation status.

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

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

Includes explicit 'Use this tool when' and 'Do NOT use this tool when' sections, providing clear contexts (e.g., verifying a receipt, rechecking trust) and alternatives (fetch full set directly, operator-controlled API).

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

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

With no annotations, the description bears full burden. It discloses constraints (retention_days range, regime from catalog, export_formats subset) and states 'No bespoke engineering — you pick, the ledger adapts', indicating a safe mutation. However, it does not detail authorization requirements, rate limits, or what exactly changes on the ledger.

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

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

The description is extremely concise at three sentences, immediately stating the purpose and then listing the body fields with their constraints. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 optional parameters, no output schema), the description adequately explains the configuration effect. It lacks return value description but hints at ledger adaptation. It covers constraints that schema enums lack, but could mention what happens on success or error.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful constraints: retention_days range (1..3650), regime is from catalog IDs, export_formats is non-empty subset of explicit list. 'enabled' is only mentioned as optional with no further detail, slightly reducing completeness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'set's customizable knobs' for compliance configuration, specifying the three configurable aspects: regulatory regime, retention days, and export formats. It distinguishes from sibling compliance tools (export, ledger, verify) by focusing on configuration rather than data retrieval or verification.

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

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, use cases, or situations where sibling tools like compliance_export or compliance_verify would be preferred. The body format is given but no contextual cues for selection.

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

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

With no annotations, the description explains output nature (downloadable, verifiable) and non-destructive behavior, but does not detail side effects or limitations.

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

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

Two sentences, front-loaded purpose, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, output nature, and use for verification, but lacks mention of sync/async behavior or error cases.

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

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

Adds default behavior for format and regime override beyond schema, which only provides types and descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it generates a signed export bundle with specific components, but does not differentiate from sibling 'audit_export' or other compliance tools.

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

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

Provides parameter guidance (format defaults, regime override) but lacks explicit when-to-use vs alternatives or prerequisites.

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

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

No annotations provided, so description fully describes the read-only, log-retrieval behavior. It includes return fields and chain hashes, but does not mention auth requirements or what happens if compliance is disabled.

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

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

Single, well-structured sentence front-loads the core purpose, then efficiently details return fields and filter parameters. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description details return fields adequately. Mentions pagination limits. Lacks explanation of behavior when compliance is off or error scenarios.

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

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

Schema coverage is 100% with clear descriptions. The description reiterates the same filtering and pagination info, adding no new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns hash-chained decision records for specific verdict-bearing calls, distinguishing it from sibling tools like audit_export or compliance_export.

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

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

The description explains filtering (from/to ISO8601) and pagination (cursor + limit), but does not explicitly compare to alternatives or state when not to use.

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

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

With no annotations, the description must carry full behavioral disclosure. It mentions authentication and the tamper-evident nature of the ledger, but omits details like rate limits, idempotency, or whether results are cached. The safe read-only nature is implied but not stated.

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

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

The description is three sentences, each serving a clear purpose: stating the core function, listing supported values, and adding context about the ledger. No fluff, perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless read tool with no output schema, the description fully covers what the agent needs: it specifies the returned configuration fields, the catalog of regimes and formats, and the authentication requirement. Nothing essential is missing.

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

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

No parameters exist, so the description adds value by detailing what is returned: configuration fields (regime, retention_days, export_formats, enabled) and the catalog of regimes and export formats. This meets the baseline of 4 for 0-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'Returns your current compliance configuration' and the catalog of supported regimes and formats. This distinguishes it from sibling tools like compliance_configure (write) and compliance_export (export), making its read-only purpose unambiguous.

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

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

The description implies usage for viewing current configuration and available regimes/formats. It notes authentication is required and provides context about the ledger, but does not explicitly state when not to use or name alternatives, though sibling names make it clear.

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

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

No annotations are provided, so the description carries full responsibility. It discloses that the tool recomputes server-side, reports integrity status with detailed fields, and mentions signed checkpoints and immutability guarantees, providing strong behavioral transparency.

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

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

The description is informative but slightly verbose with parenthetical details and a second sentence. It front-loads the main action and is generally well-structured, though could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description fully explains the return values and the tool's behavior. It covers integrity fields, checkpoint signing, and immutability claims, making it complete for an auditor's verification tool.

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

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

The tool has zero parameters and 100% schema coverage. The description does not need to add parameter details, and it correctly explains the return fields. Baseline of 4 is appropriate for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool recomputes the entire hash chain and reports integrity, with specific return fields. It distinguishes itself from sibling compliance tools by focusing on verification rather than configuration or export.

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

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

The description positions the tool as the 'auditor's prove it button', implying use for integrity verification. However, it does not explicitly state when not to use it or contrast with alternatives like compliance_export.

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

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

No annotations provided, so description carries full burden. It describes response features (coverage block, issued_by) but does not disclose behavioral traits like mutability, error conditions, rate limits, or whether external calls are made. While it adds some transparency, it lacks comprehensive behavioral disclosure.

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

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

The description is structured with the core function first, then usage context, then response details. It is clear and efficient, though slightly verbose. Every sentence adds value, and it is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity tool (1 parameter, 100% coverage, no output schema), the description adequately explains what the tool returns (three lens views, coverage, issued_by) and its purpose. It provides enough context for an agent to decide when to use it, though without output schema, some return details are assumed.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter description for the 'node' parameter. It mentions the single node key implicitly but provides no extra formatting or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns all three lens views (Tracker, Scry, Sigil) for a single node key without computing a fused verdict. It uses specific verbs and resources, and distinguishes itself from siblings like cross_lens_verify and preflight_should_i_act.

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

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

Explicitly says when to use: when you want raw transparency and intend to make your own decision. It also names alternatives: cross_lens_verify for opinionated verdict, preflight_should_i_act for an allow/caution/deny gate. This provides clear when/when-not guidance.

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

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

No annotations are provided, so the description carries full burden. It thoroughly explains fusion math, co-observation bonus, GhostRoute hard safety floors, lens unavailability handling, and the 503 fallback. This is comprehensive and leaves minimal behavioral ambiguity.

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

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

The description is long but front-loaded with the main purpose. It is structured with blocks and a coverage matrix. Every sentence adds value, though some verbosity could be trimmed. It remains efficient in conveying a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 params, nested objects, no output schema), the description is remarkably complete. It explains the response structure, fusion logic, lens unavailability, and edge cases (e.g., GhostRoute dropping out). An AI agent has sufficient information to use this tool correctly.

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

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

Schema coverage is 100%, but the description adds value beyond schema by explaining the AIT optionality and signed token behavior, and how weights/thresholds are used. The schema descriptions for parameters are already detailed, so the description enhances understanding without redundancy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: fusing multiple lenses (Scry, Sigil, GhostRoute) into a single verdict for a given node. It uses specific verbs and resources, and distinguishes from siblings like cross_lens_lookup by explaining it produces a fused verdict.

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

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

The description provides clear context on when to use this tool via the lens coverage matrix and mentions that GhostRoute has no routing surface for bare entity_slug, but it does not explicitly state when-not-to-use or name alternatives. It implies usage based on node type and lens availability.

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

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

Despite no annotations, the description thoroughly discloses behavior: it returns the same verdict as /v1/verify, includes a traced evidence chain with attributions, weights, and a P38 signed receipt via evidence_digest. It also clarifies that null weight means supplementary. Missing details like authentication requirements or rate limits, but the transparency is high for a tool without annotations.

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

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

The description is well-structured and front-loaded with an imperative statement. It contains several details but every sentence adds value. Slightly long, but not overly verbose. Could be tightened, but remains effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (evidence chain, cryptographic receipt) and the absence of output schema, the description is fairly complete. It explains the nature of evidence, null weights, and the key space. Minor omissions (e.g., how pagination works for large evidence) but sufficient for most use cases.

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

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

The input schema has one parameter (node) with concise description. The description adds significant context, explaining that node can be IPv4/IPv6, ASN, domain, or entity_slug and that it uses the same key space as /v1/verify. This goes beyond the schema's description, providing clear semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to return a verdict with a traced evidence chain for acting on it. It uses specific verbs ('ACT ON', 'returns') and identifies the resource (verdict). It distinguishes from sibling tools like verify_receipt or cross_lens_verify by emphasizing the evidence chain and cryptographically verifiable receipt.

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

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

The description opens with 'Call this when you need to ACT ON a verdict and prove why,' providing clear usage context. It implies when to use but does not explicitly state when not to use or list alternatives. However, the context is sufficient for an agent to differentiate from verification-only tools.

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

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

No annotations provided, but the description fully discloses behavior: deduplication, URL stripping, return fields, exposure levels, cost (one request per call), and latency. No contradictions.

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

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

Well-structured with clear sections (purpose, usage, inputs, returns, exposure, cost, latency). Every sentence adds value; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description thoroughly documents return fields, exposure metrics, and operational details (cost, latency), fully equipping the agent for correct invocation.

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

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

Schema coverage is 100% for both parameters. Description adds further context: deduplication, URL stripping, and the alternative domain shorthand, enriching understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it looks up domains, aggregates risk metrics, and issues a signed surveillance receipt, distinguishing it from siblings like get_domain and get_receipt.

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

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 with specific alternatives (get_domain, get_receipt, /v1/intel/*) provide clear guidance.

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

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

No annotations are provided, so the description carries full burden. It discloses free anonymous access, separate rate limiting from data API, latency expectations, and the signed nature of the bundle.

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

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

The description is thorough but somewhat lengthy; however, every sentence adds meaningful information and the structure is logical (purpose, usage, inputs, outputs). Minor redundancy could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description thoroughly documents all return fields, headers, cost, and latency. It covers everything an agent needs to invoke and interpret the tool correctly.

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

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

The schema covers the three parameters with enums and defaults. The description adds value by explaining content negotiation via Accept header and detailing the effect of each parameter, though schema coverage is already good.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Returns the TunnelMind analyst config bundle', providing a clear verb+resource. It distinguishes from sibling tools by explaining this is for configuring LLMs, not for data operations or receipt verification.

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

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

The description includes explicit 'Use this tool when' and 'Do NOT use this tool when' sections, with specific scenarios and named alternatives like check_receipt_revoked.

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

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

No annotations are provided, so the description carries full burden. It comprehensively discloses behavioral traits: the tool only reflects the calling key, 'requests_today' is best-effort and resets at UTC midnight, 'limit_per_day' is null for enterprise (unlimited), cost is free (does not count against limit), and latency is provided (<150ms typical, p99 <400ms).

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

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

The description is well-structured with sections for usage guidance, inputs, returns, cost, and latency. Every sentence provides essential information without redundancy. It is concise yet comprehensive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description fully details the return fields (tier, requests_today, limit_per_day, last_used) with types and example values. It covers usage guidelines, behavioral notes, cost, and latency, making it complete for an agent to use correctly.

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

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

There are no parameters, so baseline is 4. The description explains that auth is derived from the 'Authorization: Bearer' header, which adds implicit meaning beyond the empty input schema. No further parameter details are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns details about the API key used in the request, including tier, label, masked owner email, creation date, last-used timestamp, request count, and daily limit. This specific verb and resource scope distinguishes it from sibling tools like 'revoke_api_key' or 'audit_export'.

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

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

The description includes explicit 'Use this tool when' and 'Do NOT use this tool when' sections, providing clear context for appropriate usage and exclusions (e.g., managing multiple keys, needing tracker data). It also suggests alternative tools like tracker endpoints, guiding the agent effectively.

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

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

Discloses polling mechanism, self-baselining, event types with severities, and empty array meaning all clear. No annotations exist, so description provides adequate behavioral context.

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

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

Well-structured with bullet points, front-loaded purpose. Slightly long but each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains output fields (event_type, prev_origins, count, events) and filter behaviors. Complete for a query tool.

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

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

All parameters have schema descriptions (100% coverage). The description adds semantics: resource filter explanation, limit bounding, and output structure (count vs events).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns routing anomalies from a BGP monitor against a watchlist. It is specific and distinct from sibling tools like ghostroute_* and audit_export.

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

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

Explicitly says to use it to check for hijack-shaped events for prefixes or ASNs. Provides context but does not mention when not to use or list alternatives.

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

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

With no annotations, the description fully discloses behavior: it attempts a database lookup first, then a live probe if not found. It explains latency differences, cost limits, tier variations, and error responses (404). No contradictions.

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

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

The description is well-structured with sections for usage, inputs, returns, cost, latency. It is informative but slightly verbose; could be trimmed without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description thoroughly explains return fields, tier differences, and error handling (404). It covers all necessary context for an agent to use the tool correctly.

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

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

The single parameter 'domain' is described in the schema and the description adds valuable context: auto-strip www, subdomain resolution to parent, and examples. This goes beyond the schema's basic description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns 'complete surveillance intelligence record for a domain name', listing specific data fields. It distinguishes from siblings like 'search' and 'get_entity' by explicitly stating when to use those alternatives.

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

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, citing specific scenarios and naming alternative tools (search, get_entity).

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

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

Despite no annotations, the description discloses free vs paid tier differences (5 vs 200 domains), additional fields for Pro/enterprise, cost inclusion, and latency (typical <150ms, p99 <400ms). Covers all key behavioral aspects.

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

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

Well-structured with sections (overview, use cases, anti-use cases, inputs, returns, cost, latency). Every sentence adds value; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Explains return structure (EntityRecord with data categories, data cost, domains) and tier differences. No output schema exists, so description compensates fully.

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

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

Only parameter slug is described in detail: URL-safe, lowercase, hyphens, with examples (e.g., alphabet, meta). Adds meaning beyond schema pattern and example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns an entity record for a surveillance company or data broker, detailing fields like industry, data value, categories, and domains. It distinguishes from siblings by naming alternative tools for other use cases.

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

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

Explicitly lists when to use (three scenarios) and when not to use (three scenarios with alternative tool names). Provides clear decision criteria for the agent.

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

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

The description transparently discloses that the tool does not return the signature (anti-phishing protection), specifies the cost as free with no API key required, provides latency expectations, and explains the 404 error case. No annotations are provided, so the description fully covers behavioral traits.

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

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

The description is well-structured with sections and front-loaded with the main purpose. It is slightly verbose with latency and cost details that could be inferred from context, but all sentences add value and no information is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description covers all necessary aspects: purpose, usage conditions, input details, all return fields including the 404 case, cost, and latency. It also contextualizes against sibling tools like verify_receipt and check_receipt_revoked.

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

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

The only parameter receipt_id is fully described with its source, format requirements (alphanumeric with hyphens, max 128 characters), and requirement. The schema has 0% description coverage, but the description adds complete semantic meaning beyond the schema's type/pattern constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns metadata for a surveillance receipt, distinguishing it from similar tools like verify_receipt by specifying it does not return the receipt itself or its signature.

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

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 guidance on appropriate usage, including a direct reference to the alternative tool verify_receipt for content verification.

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

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

With no annotations provided, the description compensates by disclosing that the tool is read-only, returns null instead of silent zeros for unavailable data, and is cacheable for ~10 minutes. This provides sufficient behavioral context for safe invocation.

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

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

The description is front-loaded with the key purpose and is structured in clear paragraphs. While it is somewhat lengthy, every sentence adds meaningful information, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has no parameters and no output schema, the description provides a comprehensive overview of the returned data, including null tolerance and caching behavior. It is fully complete for an agent to understand and use the tool.

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

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

The tool has no parameters, but the description adds significant value by detailing the structure and content of the returned data, such as coverage counts for publishers, SSPs, DSPs, etc. It satisfies the baseline of 4 for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool as a single, public readout of the entire supply graph, spanning multiple layers (Scry, Sigil, Tracker, attestation, routing). It uses specific verbs ('cite', 'spans', 'holds') and distinguishes itself from sibling tools by its scope and content.

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

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

The description implies usage for citing live coverage statistics but does not explicitly state when to use this tool versus alternatives like get_bgp_events or list_domains. It mentions a contrast with Scry-only sensor stats but lacks comprehensive when-to-use guidance.

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

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

Discloses polling behavior (poll until terminal status), status values and transitions, cost (free, no rate limits), and latency (<100ms). Since no annotations are provided, the description fully covers the tool's behavioral traits, including that tasks expire after 1 hour.

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

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

Description is well-structured with clear sections (purpose, use/no-use, inputs, returns, cost, latency). Front-loaded with essential information. Every sentence adds value; no redundancy or wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one param, no output schema), the description comprehensively covers input, return fields (status, result, error, expires_at), cost, and latency. It leaves no ambiguity for an agent to correctly select and invoke the tool.

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

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

Input schema has 0% description coverage, so the description must compensate. It clearly explains task_id as '26-char ULID returned in the 202 response', adding origin and format beyond the schema's pattern and example. This is sufficient for an agent to understand what to provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states 'Returns the current status of a task created by an ?async=true intel request', specifying the verb (returns), resource (status of task), and context (async intel request). It distinguishes from sibling stream_task by noting it is for polling rather than real-time streaming.

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

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

Provides explicit use cases: 'Use this tool when: You submitted an intel probe with ?async=true and need to retrieve the result. You want to check whether a background task finished without opening an SSE stream.' Also includes clear negative guidance and alternative: 'Do NOT use this tool when: You want real-time event streaming — use stream_task instead.'

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

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

With no annotations, the description discloses behavioral traits: it checks sovereignty claims, returns specific fields, and mentions low latency (<300ms) from a cached corpus read. It implies non-destructive read-only behavior, but lacks details on authentication requirements or error handling.

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

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

The description is well-structured with a purpose sentence, a 'Use this tool when:' list, and clear Inputs/Returns/Latency sections. Each sentence adds value without redundancy, making it concise and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description covers purpose, when to use, inputs, return fields, and latency. It lacks error handling or edge cases, but for a lookup tool this is largely sufficient. Minor gap in explaining the return fields' semantics.

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

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

Schema description coverage is 0%, so the description must compensate. It specifies the format 'domain or ASN (AS####)' for the entity parameter, adding meaning beyond the schema's type 'string'. However, it does not define domain format or provide further constraints, so it is adequate but minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Checks whether' and specifies the resource: a domain or ASN belonging to an AI company's infrastructure with sovereignty claims. It differentiates from sibling tools like ghostroute_asn_lookup by mentioning sovereignty and return fields, providing a distinct purpose.

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

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

The description includes an explicit 'Use this tool when:' section with two clear use cases (identifying AI infrastructure and enriching endpoints before inference). It provides context but does not mention when not to use or alternative tools, missing exclusionary guidance.

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

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

No annotations provided, so description carries full burden. It discloses behavior: returns specific fields or {matched:false} if not found, mentions latency (<300ms), caching, and RDAP fallback. This is sufficient for a read-only lookup tool.

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

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

The description is well-structured with clear sections for inputs, returns, and latency. Every sentence adds value, no wasted words, and it is appropriately concise for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter, no output schema, and is a simple lookup, the description covers all necessary aspects: purpose, input format, return fields, and performance characteristics. It is complete and leaves no ambiguities.

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

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

Schema description coverage is 0%, but the description adds full meaning: it specifies the format 'AS#### or a bare AS number' for the `asn` parameter and indicates it is a path parameter. This completely compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns GhostRoute's ownership-graph record for an ASN, including specific fields like registrant/parent org, country, RIR, and cloud/AI flags. It distinguishes itself from sibling tools like ghostroute_ai_lookup by focusing on ASN ownership.

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

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

The description provides explicit when-to-use scenarios: when you have an origin ASN and need its corporate owner/jurisdiction, or when assessing if an ASN belongs to a cloud front. It does not mention when not to use or alternatives, but the context is clear.

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

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

No annotations are provided, so the description bears full responsibility. It discloses live lookups (BGP, RPKI, cert), caching behavior, typical latency, and the ability to issue receipts. It does not mention side effects, but as a read-only verification tool, this is expected.

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

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

The description is well-structured: first a definition, then usage guidelines, then parameter descriptions, then output description, then latency. It is informative without being overly verbose, though the output section could be condensed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of sovereignty verification and the absence of an output schema, the description covers the key output fields (sovereign_tier, sovereign_integrity, _meta.caveats/penalties). It provides enough context for an AI agent to understand the tool's capabilities, though details on subfield values are lacking.

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

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

Schema description coverage is 0%, but the description adds substantial meaning. It explains that 'entity' accepts IPv4/IPv6, domain, ASN, or cert SHA hashes, and that 'receipt' (optional) issues a signed receipt with a specific format. This compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: GhostRoute is a routing-integrity and sovereignty verification lens. It answers specific questions about infrastructure jurisdiction and scores reality against claims. It distinguishes itself from sibling tools like ghostroute_ai_lookup by being a comprehensive sovereignty check.

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

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

The description provides explicit use cases: routing data to claimed-jurisdiction endpoints and detecting masquerading infrastructure. It also mentions latency implications. However, it does not explicitly contrast with other ghostroute tools or state 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.

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

No annotations provided, so the description fully shoulders behavioral disclosure. It describes the tool as returning an immutable log, explains the meaning of events, notes that an empty feed indicates a healthy ecosystem, and provides typical latency. All key behaviors are covered.

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

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

The description is well-organized: core purpose, event definitions, usage guidance, input/output details, and latency. Every sentence adds value without redundancy. It is concise given the complexity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description fully details the return structure (`summary` and `alerts[]` with all fields) and explains the context of events. Latency is provided. The description is complete for an agent to use the tool correctly.

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

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

The only parameter, `limit`, is described as 'max recent alerts, 1–200, default 50', which matches the schema but adds the phrase 'recent alerts', clarifying its purpose. Since schema description coverage is 0%, the description compensates adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a 'durable, deduplicated ledger of CT equivocation events' and distinguishes it from a sibling tool ('Where `/v1/ghostroute/witness` shows live computed health...'). It lists specific event types, making the purpose unambiguous.

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

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

Explicit usage guidance is given: 'Use this tool when: - You want a chronological record of CT trust violations, not live state. - You're polling for new equivocation events (check `summary.last_detected_at`).' This clearly tells the agent when to choose this tool over alternatives.

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

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

Explains failed attempts with reason, that unproven cert is a signal, latency info, and the read-only nature. Fully transparent without annotations.

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

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

Well-structured with sections, but slightly verbose. Could tighten wording without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description details return structure (summary, recent[], by_domain[]) and latency, providing a complete picture for agent use.

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

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

Schema has no descriptions (0% coverage), but the description explains `domain` as filter and `limit` as max rows with range and default, fully compensating.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool returns per-cert inclusion proofs for CT logs, and distinguishes itself from sibling tools like ghostroute_verify or ghostroute_ct_witness by focusing on proof retrieval.

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

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

Explicitly lists when to use: for a specific domain or corpus-wide rollup. Provides clear scenarios, no ambiguity.

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

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

No annotations are provided, so the description carries full burden. It describes the output structure, explains that the tool returns first-party verified roots (not from third parties), and notes latency and caching behavior. It does not mention authentication or rate limits, but these may be system-wide. Overall, it is fairly transparent about what the tool does and returns.

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

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

The description is well-structured with distinct sections: what it does, when to use, inputs, returns, and latency. Every sentence adds value, and there is no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of CT witness state and no output schema, the description provides a thorough explanation of the return fields (summary, logs, regressions) and their meanings. It is complete enough for an agent to understand the output and act on it.

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

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

The input schema has no parameters (100% coverage trivially). The description explicitly states 'Inputs: none', which is clear. Baseline for zero parameters is 4, and the description adds no confusion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns GhostRoute's first-party CT witness state, including signed tree heads and regression scans. It distinguishes this from other tools like ghostroute_ct_proofs by emphasizing that it provides corpus-wide health rather than individual certificate checks.

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

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

The description explicitly provides two 'Use this tool when' scenarios: for corpus-wide CT witness health and for detecting CT log misbehavior. It implicitly excludes use cases like checking a single certificate, which would be covered by siblings like ghostroute_ct_proofs.

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

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

No annotations provided, but description identifies the action as a retrieval (read), mentions typical latency (<200ms single indexed read), and specifies the return content (full persisted receipt row). Lacks authentication requirements but sufficient for a read operation.

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

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

Very concise: one sentence followed by bullet points for use cases, inputs, returns, latency. No redundant information. Well structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameter format, return value, and latency. Missing error behavior (e.g., if receipt not found) but otherwise complete for a simple retrieval tool.

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

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

With 0% schema description coverage, the description compensates by explaining the receipt_id format (GR-YYYY-NNNNNNN) and noting it is a path parameter. Provides precise guidance for the single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Retrieves a previously-issued, signed GhostRoute receipt' and gives the purpose (audit). While it doesn't explicitly differentiate from sibling 'verify_receipt', the specific id format and audit context provide enough clarity.

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

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

Bullet points list two specific use cases: holding a receipt id for confirmation, and reconciling action logs. Provides good context but does not mention when not to use or alternatives.

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

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

With no annotations provided, the description fully discloses behavioral traits: it is free, requires no API key, is not rate-limited, and has typical latency under 50ms with p99 under 200ms. This goes well beyond the minimal required info.

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

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

The description is efficiently structured with clear sections (when to use, when not, inputs, returns, cost, latency) and is front-loaded with the core purpose. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema, no annotations), the description is thoroughly complete. It explains the return fields (ok, ts), cost, latency, and provides contextual usage guidance.

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

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

There are zero parameters, so the baseline is 4. The description correctly notes 'Inputs: None,' adding no additional semantics but confirming the absence of parameters clearly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns a minimal status object confirming the API is alive, with specific verb ('Returns') and resource ('status object'). It distinguishes from sibling tools like 'get_domain' and 'search' by explicitly stating it does not return tracker data or domain-specific info.

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

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

The description provides explicit 'Use this tool when' and 'Do NOT use this tool when' sections, detailing contexts like verifying connectivity before a multi-step investigation, after 503/504 failures, or debugging new environments. It also names alternatives ('get_domain' or 'search') for other needs.

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

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

With no annotations, the description fully discloses behavior: probes multiple endpoints, returns boolean flags and integer score, notes cost (free, no API key), and latency (2-5s typical, p99 8s). No contradictions.

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

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

Well-structured with clear sections (purpose, signals, when to use/not use, inputs, returns, cost, latency). Every sentence adds value; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description lists all return flags and explains the score range (0-8). Covers cost, latency, and input details. Suffices for an agent to understand and use the tool correctly.

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

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

Description explains 'domain' parameter meaning and provides example, but does not mention the 'async' parameter. However, schema already describes 'async' well, so the description adds value for the required parameter while the schema covers the optional one.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool probes a domain for AI agent integration signals and returns a score. It uses specific verbs and resources and explicitly distinguishes from sibling tools like intel_robots, intel_http, and get_domain.

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

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 specific scenarios and alternative tools, leaving no ambiguity about when to use this tool versus siblings.

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

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

With no annotations, the description carries the full burden. It discloses the HEAD request, redirect limit, timeout (6s), security scoring, and CSP actor detection. It mentions latency and cost. A minor gap: the async parameter is not described here (though covered in schema), but the hint 'Plan for async' is present. Overall highly transparent.

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

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

The description is well-structured with clear sections: operation, use cases, inputs, returns, cost, latency. Every sentence adds value, and it is front-loaded with the essential action. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description thoroughly explains return values (reachable, redirect_chain, security_headers, csp_actors, error). It covers timeout, redirect limit, and common use cases. The async parameter is covered in schema, so the description is complete for the tool's complexity.

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

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

Schema coverage is 50% (domain has example only, async has description). The description adds value by giving domain format examples and explaining output fields in detail. However, it does not elaborate on the async parameter beyond a vague suggestion. Still, it compensates partially for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it makes a live HEAD request, follows up to 5 redirects, and returns specific data like redirect chain, status, headers, security score, and CSP actors. It distinguishes itself from sibling tools like get_domain, intel_stack, and intel_robots by specifying what it does not do.

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

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

Explicitly lists when to use (verify HTTPS/HSTS, inspect CSP, assess security) and when not to use (tracker data, tech stack, robots.txt), with named alternatives. This provides clear guidance for an AI agent.

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

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

No annotations provided, so description fully covers behavioral aspects: fetches HTML, checks for hidden text, invisible divs, AI comments, injection patterns; describes return fields (injection_signals, risk_level); mentions cost (free) and latency (2-4s, p99 7s).

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

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

Well-structured with sections (purpose, usage, inputs, returns, cost, latency). Each sentence adds necessary information, though slightly verbose but efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all essential aspects for a security scan tool: input requirements, output fields, cost, latency, async behavior. No output schema needed as return values are described.

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

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

Schema covers 50% of parameters (async described). Description clarifies domain parameter as 'Domain to scan' and reiterates async behavior. Adds value by confirming usage context for domain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it fetches a domain's homepage and checks for prompt injection patterns. Differentiates from siblings by naming alternatives for other use cases (get_domain, intel_optout, intel_agent).

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

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

Provides explicit 'Use when' and 'Do NOT use' sections with specific alternatives, making it easy for the agent to decide when to invoke this tool.

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

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

With no annotations, the description carries the full burden. It details the checks performed, specifies cost (free) and latency (2-4s, p99 7s), and explains the async parameter behavior. It lacks explicit mention of read-only nature but implies it through 'checks' and returns.

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

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

The description is tightly structured with clear sections (what it does, when to use, inputs, returns, cost, latency). Every sentence adds value without redundancy, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return fields clearly. It covers inputs, usage context, cost, and latency. Missing error handling or edge cases, but for a domain-probing tool, it is reasonably complete.

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

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

Schema description coverage is 50% (only async described). The description adds meaning by specifying 'domain (query, required)' and providing return fields, which helps an agent understand the domain parameter's role and the output shape. This compensates for the missing schema description of domain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear verb ('Checks') and specific resource ('domain for AI training data opt-out mechanisms'), listing concrete signals (TDM headers, meta tags, CC licenses). It immediately distinguishes from sibling tools by specifying what it covers beyond robots.txt.

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

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

The 'Use this tool when' and 'Do NOT use this tool when' sections provide explicit context, including alternatives (intel_robots, get_domain, intel_inject) and the condition 'compliance before using domain's content in training dataset'.

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

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

No annotations provided, so the description bears full responsibility. It explains the tool's read-only nature, return fields, cost, and latency. It does not mention rate limits or error handling, but covers key behavioral aspects thoroughly.

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

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

Highly structured with clear sections (purpose, usage, inputs, returns, cost, latency), front-loaded with core functionality. Every sentence adds value, no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 lists all return fields, which is helpful. It covers cost and latency. Missing error scenarios or edge cases, but overall adequate for a simple probing tool.

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

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

Schema description coverage is 50%: async parameter is well-documented in schema, but domain lacks description there. The tool description adds meaning for domain ('Domain to probe') and states it is required, compensating for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves and parses robots.txt for AI crawler disallow rules. It distinguishes itself from siblings by naming intel_optout, intel_stack, and get_domain, making it easy to select.

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

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 with concrete scenarios and alternative tool names, providing excellent guidance for correct invocation.

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

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

Despite no annotations, description discloses behavioral traits: up to 32KB fetch, edge fingerprinting, detection sources, cost, and latency. No contradictions.

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

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

Description is well-structured with sections (use cases, inputs, returns, cost, latency) and each sentence adds value. Slightly long but not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provides complete context: what it does, when to use, alternatives, input/output details, cost, latency. No output schema, but description explains return fields sufficiently.

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

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

Schema coverage is 50% with only async parameter described. Description does not add meaning beyond the schema for parameters; domain has only an example. However, the tool's usage is simple enough that this is minimally adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool fetches HTML and fingerprints for CMS, frameworks, CDN, analytics. It distinguishes from siblings like intel_http and get_domain.

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

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

Explicitly states when to use and not to use, with specific alternative tools named (intel_http, get_domain, intel_robots).

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

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

Discloses pagination behavior, result ordering, filtering capabilities, tier limits (free vs paid), latency expectations, and return structure. No annotations exist, so description fully covers behavioral traits without contradiction.

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

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

Well-structured with sections for usage guidance, inputs, returns, cost, and latency. Front-loaded with core purpose, each sentence adds value, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all aspects needed for a list tool with 4 parameters: pagination mechanics, filtering, tier limits, latency, return format without output schema, and proper usage context.

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

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

Despite 0% schema description coverage, the description adds comprehensive meaning for all 4 parameters: explains limit tier differences, cursor usage from previous response, category valid values, and min_score semantics, going well beyond the schema's type/constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool returns a paginated list of domains from the tracker database, specifies alphabetical ordering and pagination method, and distinguishes from siblings by listing alternative tools for specific use cases.

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

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

Provides explicit 'Use when' and 'Do NOT use when' sections with specific alternative tool names (get_domain, search, get_entity), giving clear guidance on appropriate contexts.

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

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

No annotations provided, but description fully discloses pagination, cost tiers, latency, and return structure. No contradictions.

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

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

Well-structured with sections for summary, use cases, inputs, returns, cost, latency. Every sentence is informative and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Completely covers all necessary context for a list tool: pagination, filtering, return format, performance characteristics. No output schema exists, but return structure is explained.

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

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

Input schema has 0% description coverage, but the description explains each parameter in detail: industry examples, limit with tier constraints and default, cursor for pagination. Adds significant value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns a paginated list of corporate entities with data categories, value, and industry. It distinguishes itself from siblings by naming alternatives like get_entity, search, and list_domains.

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

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

Provides explicit when-to-use scenarios (enumerate by industry, build landscape) and when-not-to-use with specific alternative tools (get_entity, search, list_domains).

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

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

No annotations are provided, so the description carries full burden. It transparently explains that the tool returns a tri-state decision and a receipt (sigil_token), details the effect of the `ait` parameter, the bounded tracker-presence bonus, and that the receipt is the load-bearing artifact for accountability. It does not hide any behavioral traits such as side effects or rate limits, but the lack of explicit read-only declaration is a minor gap.

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

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

The description is well-structured with key information front-loaded in the first paragraph, explaining the core purpose and output. Subsequent paragraphs add important details about the receipt, AIT chaining, and tracker bonus. While thorough, it is slightly verbose and could be tightened while retaining clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters including nested objects, no output schema), the description is remarkably complete. It explains the output format (tri-state decision and sigil_token), the decision logic with default thresholds, the role of the receipt as a cryptographic proof, and the behavior of each parameter including the optional AIT chaining. No additional context seems necessary.

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

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

Schema coverage is 100% with descriptions for all five parameters, but the tool description adds significant context beyond the schema. For example, it explains that `thresholds` are overridable and must satisfy 0 <= caution < allow <= 1, that `intent` is free-form and never affects the decision, and that `ait` chains a witness event. This enriches semantic understanding beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is 'the single call an agent makes before transacting with a destination on the open web' and explains it composes a cross-lens verdict with a tracker-presence bonus to produce a tri-state decision and a signed receipt. This specific verb-resource-action combination distinguishes it from all sibling tools.

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

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

The description gives explicit context for when to use (before transacting with a destination) and explains key behaviors like the tracker-presence bonus and default thresholds. While it doesn't explicitly list when not to use or name alternative tools, the singular purpose implied by 'the single call' provides sufficient guidance.

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

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

With no annotations provided, the description fully carries the burden of behavioral transparency. It explains that the tool fuses all three TunnelMind lenses, returns a confidence-scored profile and a signed P38 receipt, and details the cross_lens.hits and cross_lens.flags fields. It also describes the confidence weighting mechanism (1.5× multiplier for corroboration, Scry weighting by attestation tier) and bounds [0,1].

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

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

The description is detailed and well-structured, with the primary use case front-loaded. However, it is somewhat lengthy and could be slightly more concise without losing essential information. Each sentence contributes value, but minor trimming could improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (three lenses, confidence scoring, cross-lens signals, and receipt generation), the description covers all key aspects: input requirements, output fields (cross_lens.hits, cross_lens.flags), confidence weighting, and differentiation from siblings. It also explains the output format (signed P38 receipt) despite no output schema being provided.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema by explaining which lens each parameter targets (ip for Scry, domain for Sigil+Tracker, entity for Sigil+Tracker) and noting that at least one is required. This provides context for how parameters affect the analysis.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Call this before routing traffic, bidding on inventory, or trusting a counterparty.' It specifies the verb 'profile', the resource 'entity' (a combination of ip/domain/entity), and distinguishes itself from siblings like cross_lens_verify and cross_lens_lookup by explaining what makes profile_entity unique (richest fused detail for pre-transaction decision).

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

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

The description explicitly states when to use the tool ('before routing traffic, bidding on inventory, or trusting a counterparty') and differentiates from alternatives by stating 'Unlike cross_lens_verify (one node → one verdict) and cross_lens_lookup (one node → raw three-lens view), profile_entity takes the SUBJECT...'. It also specifies parameter requirements: 'At least one of ip / domain / entity is required.'

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

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

No annotations provided, but description fully covers behavioral traits: irreversibility, 401 response after revocation, billing note, free cost, and latency. No contradictions.

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

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

Well-structured with clear sections (use, inputs, returns, cost, latency). Front-loaded with key information, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, description specifies return fields (revoked, note). All relevant aspects covered for a simple 0-param tool.

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

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

No parameters in schema, description explains auth is from header and no body/query. Baseline 4 for zero-param tool; adds value by clarifying input mechanism.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it permanently deactivates the API key used for the request. Specific verb 'revoke' and resource 'API key' are distinct from sibling tools like get_api_key.

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

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

Provides explicit when-to-use scenarios (rotate, compromised) and when-not-to (check quota, intend to keep using). Names alternative tool get_api_key.

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

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

Despite no annotations, the description discloses key behaviors: multi-table search, result caps (20 per type), no pagination, minimum/maximum query length, cost info, and latency estimates. Missing only a note on authentication requirements, but otherwise thorough.

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

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

The description is comprehensive but slightly verbose, repeating some schema details (min/max length) and including cost/latency which could be inferred. Still, it is well-structured with bullet points and sections, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers return arrays, empty results, and pagination limits. It also handles constraints, usage guidance, and performance expectations, leaving no obvious gaps for a search tool of this complexity.

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

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

The schema has 0% parameter description coverage, so the description must compensate. It adds context: the query 'q' is matched against domain names and entity names/slugs, with character limits already in schema but reinforced. The description provides practical semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches both domains and entities tables simultaneously, and provides explicit instructions on when to use this tool versus siblings like get_domain and get_entity, making the purpose unambiguous.

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

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

The description includes a clear 'Use this tool when' and 'Do NOT use this tool when' section, listing specific scenarios and alternative tools (e.g., get_domain, get_entity, list_domains), which fully enables correct tool selection.

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

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

With no annotations, the description carries full burden. It explains return fields (newest first, changes array) and notes limit defaults/max. Could mention read-only nature, but sufficient.

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

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

Well-structured with paragraph and bullet-like input list. Every sentence adds value, no fluff. Front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description lists return fields (changes[], observed_at, added_count, etc.) and explains their meaning. Complete for a history tool.

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

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

Schema coverage is 0%, but description compensates fully: explains domain as path required, since as ISO date optional, limit with default and max. Adds meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns a publisher's ads.txt change log, with specific verb and resource. It distinguishes from sibling verification tools like sigil_verify_ads_txt.

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

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

Provides a real-world use case (fraud signal detection) and how buyers audit supply. Implicitly suggests when to use, but lacks explicit 'when not to use' or alternatives.

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

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

The description lists return values but lacks disclosure of behavioral traits such as side effects, idempotency, or authentication requirements. Since no annotations exist, the description bears full responsibility for transparency.

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

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

The description is a single, well-structured sentence that lists the output clearly. It is front-loaded with the verb 'Returns' and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter, but the description lacks parameter explanation and usage context. It does cover the return fields, which is good given no output schema.

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

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

The schema has 0% description coverage, and the description does not explain the 'id' parameter, leaving the agent with no additional meaning. The description must compensate but fails to do so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns an AIT's status and lists specific data fields, distinguishing it from siblings like sigil_atap_register_ait and sigil_atap_witness. However, it could be more explicit about what an AIT is.

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

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

No guidance is provided on when to use this tool versus other AIT-related tools. There is no mention of prerequisites, alternatives, or 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.

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

Discloses validation, signing, storage, and witness role, but lacks detail on side effects, failure modes, or idempotency. Since annotations are absent, the description carries the full burden and is adequate but not thorough.

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

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

Two paragraphs, front-loaded with the main purpose. No redundant information, but the second paragraph could be integrated more concisely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks details on parameter formats, return values, error handling, and edge cases. References external URL but does not sufficiently equip the agent for autonomous use given the tool's complexity.

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

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

Schema description coverage is only 14%, and the description does not explain individual parameters (e.g., capabilities, constraints format). The description mentions 'capability set and constraints' but provides no parameter-level semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (register), resource (ATAP v0.1 AIT), and profile (sigil:media_buyer:v1). It distinguishes from siblings like sigil_atap_ait_status by focusing on registration vs. status checks.

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

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

No explicit when-to-use or when-not-to-use guidance. Does not contrast with other ATAP tools, leaving the agent to infer contexts.

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

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

The description discloses key behaviors: it processes pending events, signs the block, chains it to the prior block, and uses a specific profile ('period_summary'). However, with no annotations, it lacks details on permissions, idempotency, or failure modes, leaving gaps for an agent.

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

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

The description is a single sentence that conveys the core action without unnecessary words. It is front-loaded with the verb and object, making it easy to parse. Minor reduction possible by removing 'every not-yet-blocked' but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter and no output schema, the description explains the tool's primary function. However, it omits return value details, error conditions, and prerequisites (e.g., AIT registration status). An agent may need additional context to use it confidently.

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

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

The schema has one required parameter 'ait' with no description (0% coverage). The description mentions 'for an AIT' but does not explain the format or semantics of the 'ait' string, such as what constitutes a valid AIT identifier or where to obtain it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Rolls' and clearly identifies the resource: 'not-yet-blocked Witness Event for an AIT' to create a signed ATAP Attestation Block. It differentiates from siblings like sigil_atap_witness and sigil_atap_register_ait by describing a distinct aggregation step.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention prerequisites like needing registered AITs or pending witness events, nor does it advise against using it in certain contexts.

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

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

With no annotations provided, the description fully discloses behavioral traits: payload validation, PII rejection, evidence tier classification (anchored vs asserted), derivation of constraint:violated events, and chaining/signing. It also highlights the non-bypassability of the witnessed tier, adding critical context for safe use.

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

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

The description is densely informative with no redundant sentences. It front-loads the core action, then systematically details validation, classification, and sibling differentiation. Each sentence earns its place, achieving conciseness without sacrificing completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no output schema, and no annotations, the description is remarkably complete. It covers input semantics, processing logic, and usage boundaries. The agent can confidently invoke the tool based on this description alone.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining the event_type values and their implications (e.g., bid:submitted leads to anchored if valid token), and describes payload validation rules. However, it does not detail the structure of the `payload` object or `ait` string, leaving some gaps. Still, it provides significant additional semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'ingests' and the resource 'agent-reported events into an AIT's hash-chained attestation log'. It lists the specific event types accepted and distinguishes this tool from its sibling `sigil_verify_supply_path` by noting that supply events are not accepted here, ensuring no confusion.

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

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

The description explicitly states when to use this tool (for ingesting bid:* and budget:decremented events) and when not to use it (supply:verified/rejected events are handled by a different tool). It also explains the validation and classification logic, providing clear context for appropriate invocation.

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

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

Despite no annotations, the description discloses behavioral details: pending events are rolled into a final block, the ZIP verifies offline, and the summary grades events. This adds transparency, though rate limits or side effects are not mentioned.

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

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

The description is somewhat lengthy but each sentence adds value, detailing contents and verification. It is front-loaded with the main purpose. Minor redundancy could be trimmed, but overall it is structured and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and annotations, the description covers many aspects but leaves gaps: it does not explain what an AIT is, the return format (file or buffer), or how the output is delivered. It adequately explains content but not handling details.

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

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

With 0% schema coverage, the description must explain parameters. It mentions 'AIT' but does not clarify the 'ait' parameter format or that 'format' controls whether output is 'full' or 'summary'. The description misses key parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool assembles a Receipt ZIP for an AIT, listing its contents and verification steps. It distinguishes from siblings by referencing ATAP v0.1 §7.5 and specific artifacts.

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

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

The description implies usage for generating a receipt package but does not provide explicit guidance on when to use this tool versus alternatives like 'generate_receipt' or 'verify_receipt'. No when-not or alternative comparisons.

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

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

With no annotations, the description must fully disclose behavior. It does mention that per-item parse failures are returned inline and the batch never fails as a whole, which is critical. However, it lacks details on return format, authentication requirements, or rate limits, leaving gaps.

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

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

The description is highly concise: three sentences total, front-loaded with core purpose, then key behavioral trait, then optional parameter. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should explain return values; it only implies inline error handling. It lacks details on what 'scores' means, response structure, and prerequisites. While it covers the main purpose and key behavior, it is not fully complete for an unannotated tool.

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

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

Schema description coverage is 50% (weights has a description, entity_ids does not). The description adds the cap of 200 for entity_ids and explains that weights re-weights every entity, adding value beyond the schema. Yet, for a low-coverage scenario, it does not fully compensate by describing both parameters in detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scores up to 200 entities in one round-trip, specifying the verb 'scores' and the resource 'entities'. It also provides context ('built for agents evaluating many supply sources during campaign setup'), distinguishing it from sibling tools like sigil_score_entity which handle single entities.

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

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

The description gives clear usage context ('evaluating many supply sources during campaign setup') and implies efficiency with 'one round-trip'. However, it does not explicitly contrast with singular alternatives or specify when not to use this batch tool, though the context is sufficient for appropriate selection.

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

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

With no annotations provided, the description carries full burden. It discloses: returns score, breakdown, trend; scores are refreshed daily; fast and deterministic; never recomputes; entity format; v1 components; not_evaluated list; optional weights. This is highly transparent about behavior and limitations.

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

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

The description is around 150 words, well-structured with front-loaded purpose, then entity_id format, v1 details, and optional weights. Every sentence adds value with minimal redundancy. Could be slightly tighter but is consistently focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description covers the tool's behavior comprehensively: pre-computed scores, daily refresh, entity format, v1 components, not_evaluated list, and optional weights. An agent can fully understand what to expect from the tool's response.

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

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

Only 50% of parameters have schema descriptions, but the description adds significant meaning: it explains entity_id format with examples and entity types, and defines weights as URL-encoded JSON for re-weighting. This compensates for the schema gap and provides clarity beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Returns the pre-computed 0.0–1.0 trust score for one entity, its component breakdown, and the 14-day trend.' This is a specific verb and resource, and distinguishes from siblings like sigil_score_batch and sigil_score_weights. It also explains that scores are pre-computed and refreshed daily, setting clear expectations.

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

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

The description provides context on when to use the tool (e.g., fast and deterministic, never recomputes) and explains the entity_id format and accepted types. While it doesn't explicitly say 'use for single entity instead of batch', the context signals and sibling names imply the appropriate use case. It lacks an explicit exclusion of alternatives.

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

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

With no annotations, the description carries full burden. It discloses that the operation returns data without modification ('without changing the defaults'). However, it does not explicitly state that it is a read-only operation or mention any required permissions, but the non-destructive nature is implied.

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

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

The description is two sentences, front-loading the main functionality in the first sentence and providing context in the second. Every sentence adds value, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and no output schema, the description adequately covers what it returns (default weights and unevaluated components) and how to use a sibling for customization. It lacks specific details about the return format but is sufficient for a straightforward read tool.

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

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

There are no parameters, so schema coverage is 100% by default. The description adds no parameter information because none exist, which is appropriate. Baseline for zero parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'returns the active, versioned default weights' and 'the list of spec components that are not yet evaluated.' It uses a specific verb and resource, distinguishing itself from siblings like sigil_score_batch which accepts custom weights.

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

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

The description explains when to use this tool (to get default weights) and explicitly suggests an alternative: 'Pass a custom weights object to sigil_score_batch to re-weight without changing the defaults.' This provides clear usage guidance.

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

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

With no annotations provided, the description fully carries the burden of disclosure. It details the risk-classification logic (corroborated, contradicted, unchecked), ordering riskiest-first, reseller expansion, and the in_supply_graph flag. This is comprehensive for a query tool.

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

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

The description is information-dense and well-structured, starting with the main function and distinction, then classification details, then ordering. While a bit lengthy, every sentence adds value. Could be slightly tighter but still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains the output structure (itemized paths, classification, resells_to, in_supply_graph flag) and ordering. It also covers the edge case of domain not being a known publisher. Missing error handling details but sufficient for a query tool.

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

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

The input schema has 100% coverage with descriptions for both parameters. The description adds value by explaining how the limit parameter interacts with ordering (riskiest-first truncation) and that counts are over the full set, going beyond the schema's simple bounds description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reconstructs supply paths for a domain and returns them itemized. It explicitly distinguishes from two siblings: sigil_verify_supply_chain (verifies a given schain) and signal_dark_pool_risk (aggregate counts), leaving no ambiguity about its unique purpose.

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

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

The description provides clear context for when to use this tool versus alternatives by naming specific sibling tools and their different functions. However, it does not exhaustively compare with all relevant siblings (e.g., sigil_verify_supply_path), and lacks explicit 'when not to use' guidance, though the context is sufficient.

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

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

With no annotations, the description fully discloses behavior: stateless, DNS-only, and not signature verification. It also details return fields, aiding agent understanding.

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

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

The description is well-structured with clear sections but could be slightly more concise. It front-loads the core purpose and provides necessary details without excess.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description includes return fields and explains limitations (e.g., delegation requirement). It is complete for a simple DNS-checking tool.

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

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

The description explicitly defines the single parameter 'domain' with its type, requirement, and purpose ('Domain to check'), adding value beyond the schema's minimal 'string' definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: reporting whether a domain publishes ads.cert DNS records. It distinguishes itself from 'signature verification' and is unique among siblings like sigil_verify_ads_txt.

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

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

The description explains it is 'DNS-only and stateless' and clarifies that signature verification requires a future build. It implies use for readiness checks but does not explicitly contrast with all sibling tools.

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