TunnelMind Data API

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

With no annotations, the description fully covers behavior: it checks all reachable registries, returns explicit states (observed, not_present, etc.), lists specific registries, mentions caching (KV-cached 1h), latency bounds (5s cold), and receipt option. 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 bullet points but verbose (4 paragraphs). Some redundancy, e.g., repeating cross-lens concept. Front-loaded with purpose, but could be trimmed while retaining key details.

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 comprehensively explains all possible answer states, registries checked, and latency behavior. It provides sufficient context for an AI agent to understand tool's scope and results.

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, but the description adds context: explains subject types (IP, domain, agent name/UA fragment) and receipt as 'signed Receipt v1.0 committed to transparency log', enhancing understanding beyond the enum.

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 performs a cross-lens join across multiple registries to check agent/bot/MCP server registration. It distinguishes from siblings by contrasting with 'incumbent providers each consult only their own registry' and positions this as a single-call aggregation.

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 bullet points for when to use: deciding on registration status and needing blind spots. Implicitly contrasts with checking registries individually, but does not name specific alternative tools or explicitly 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?

Discloses read-only nature, KV read, returns cached bundle with freshness meta, 404 on miss, no sigil token, cost as one request, latency <100ms. No annotations provided, so 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?

Well-structured with clear sections, but moderately verbose. Could be slightly shorter without losing clarity, 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?

Covers inputs, returns (including error 404), cost, latency, and staleness contract. No output schema, but description explains return values comprehensively.

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 one parameter 'node' with no description (0% coverage). Description adds meaning by specifying allowed formats (IPv4, domain, ASN, entity_slug) and referencing /v1/verify grammar.

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's a fast attributes endpoint for node attribute lookups using a cached bundle, distinguishing it from the full /v1/verify endpoint and other 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?

Explicitly states when to use (hot path with staleness tolerance, re-checking verified nodes) and when not to use (per-request auth loops, need for fresh verification or sigil token).

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 of behavioral disclosure, and it excels: it explains the hash-chaining and deletion detection, authentication scoping (own entries vs admin), NDJSON stream format, response headers, offline verification procedure, cost counting, and latency profile. This is far beyond minimal 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?

Although lengthy, the description is well-structured with clear sections (description, use cases, inputs, returns, verification, cost, latency), front-loaded with the core purpose. Every sentence adds operational value—no filler. The structure makes it easy to scan and ingest.

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, absent annotations, and lack of output schema, the description is remarkably complete: it covers inputs, output format, HTTP headers, chain verification logic, authentication behavior, rate-limit cost, and typical latency. There are no significant gaps for an agent to select and invoke 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 description coverage is 0%, so the description must compensate. It does: every parameter (`from`, `to`, `limit`) is explained with format, default, and constraints (e.g., 'default 7 days ago', '1–5000, default 1000'). This gives the agent full comprehension without needing to infer from 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 opens with a specific verb and resource: 'Returns NDJSON (one JSON object per line) of audit log entries.' It goes on to detail what each entry records, making the tool's purpose unmistakable. It also distinguishes itself from siblings by explicitly saying 'use `get_task` instead' for task status, which differentiates it from at least one alternative.

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 an explicit 'Use this tool when:' and 'Do NOT use this tool when:' section, including a concrete alternative (`get_task`). It also states the authentication requirement, clarifying a key condition for use. This is exemplary 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 covers behavioral traits: returns 409 Conflict for terminal states, requires the creator identity to cancel, returns task_id and status, states cost is free, and gives typical latency. This is comprehensive and goes beyond basic mutation semantics.

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 action, usage, inputs, returns, cost, and latency. Each section earns its place, though cost and latency could be considered optional; however, they do not bloat the text significantly.

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 one parameter and no output schema, and the description covers the mutation, conflict behavior, authorization, return values, cost, and latency. It provides all necessary context for an agent to decide when to use it and what to expect.

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 description for task_id (0% coverage), but the description compensates by specifying it is a path parameter, required, and a 26-char ULID. This fully resolves the parameter's meaning and format, exceeding what the schema alone 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's function: 'Marks the task as `cancelled`', with a specific verb and resource. It also mentions the conflict on terminal states, but does not explicitly differentiate from sibling tools like get_task or stream_task, so it falls short of a 5.

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, giving clear invocation scenarios and an exclusion (already complete). However, it does not name alternative tools for other scenarios, so it misses the 'alternatives' component for a 5.

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 fully carries the burden of behavioral disclosure. It goes well beyond a basic read operation: it states the endpoint is an alternative to a local mirror, includes `feed_version` for cache coherence, details response fields (`revoked`, `revoked_at`, `reason`, etc.), and discloses cost, rate-limiting, edge-caching (60s), and latency ranges. This level of detail is exceptional and leaves little ambiguity about side effects or operational behavior.

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 organized into clear, labeled sections (purpose, use cases, non-use cases, inputs, returns, cost, latency) with bullet points for scannability. Every sentence adds operational value—the cost and latency sections are not fluff but pragmatic details for an agent deciding whether to use this endpoint. It is longer than average but tightly written and front-loaded with the core 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?

The description is fully self-contained for a tool with no output schema and no annotations: it explains the input options, the exact response structure, the cache/rate-limit behavior, and even provides fallback guidance (fetch well-known directly). There is no missing context an agent would need to make an informed invocation decision. The only minor omission is explicit authentication requirements, but the 'Free; rate-limited like the rest of the data API' implies public access, and the overall completeness is outstanding.

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 both parameters already having descriptions and examples. The description adds the critical constraint 'Provide one of `key_id` or `id`', which is not encoded in the schema, and reinforces the context for each parameter (e.g., 'Receipt-format key_id'). This adds meaningful semantics beyond the schema, though the schema already does most of the heavy lifting.

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 opens with 'Single-item revocation lookup per Receipt Format v1.0 §8.2', immediately stating the specific verb ('lookup'), resource ('revocation'), and scope ('single-item'). It further distinguishes this tool from siblings like 'get_receipt' and 'verify_receipt' by contrasting it with fetching the full revocation set. This is a clear, specific purpose statement that differentiates the tool effectively.

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, enumerating concrete scenarios (verifying a receipt's key_id, checking a specific receipt_id, long-term rechecking) and explicitly naming the alternative (fetching `/.well-known/receipt-revocations.json` directly) for the negative case. This gives an agent unambiguous guidance on when to invoke this tool versus another resource.

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 transparency burden. It discloses optional fields, allowed ranges, and the non-empty subset constraint, plus the 'ledger adapts' behavior. However, it does not describe side effects like whether existing settings are overwritten, persistence, or authorization requirements.

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 with no fluff. It front-loads the purpose, provides a compact body template, and packs constraints and behavioral notes efficiently. Well structured for quick parsing.

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 configuration tool with no output schema or annotations, the description covers most key aspects: settings, constraints, and adaptation. But it omits what happens on success (e.g., return value), whether it's a patch or full replacement, and the exact effect of 'enabled'. Slightly incomplete given the 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 0%, but the description compensates by explaining regime, retention_days, and export_formats with concrete constraints. The 'enabled' parameter is only mentioned as optional without explaining what it enables, which is a minor 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 identifies the tool as setting compliance configuration (regime, retention, export formats) with a specific verb 'Set'. It does not explicitly differentiate from sibling tools like compliance_export or compliance_verify, but the scope is evident.

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?

Usage is implied through 'Set the customizable knob' and the list of settings, but there are no explicit when-to-use or when-not-to-use instructions or references to alternatives. The 'No bespoke engineering' note hints at when it's appropriate, but not definitively.

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 behavioral disclosure burden. It reveals that the output is a downloadable artifact including a manifest, chain-integrity proof, and latest signed checkpoint, and that the result is independently verifiable. It does not mention auth requirements, rate limits, or side effects, but for an export tool the given detail is substantial and goes beyond a simple 'generates export' statement.

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 dense paragraph but is front-loaded with the core purpose ('Generates a signed export bundle'). All sentences contribute relevant information (format, regime, artifact contents). Slightly verbose due to packing many details, but no fluff; still concise enough for an MCP tool with four parameters.

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 moderately complex with 4 optional parameters and no output schema. The description explains the return value (a downloadable artifact with manifest, proof, checkpoint) and mentions verification context, covering what an agent needs to invoke it. It doesn't detail every edge case or error behavior, but given the schema coverage and description richness, it is sufficiently 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 100%, so baseline is 3. The description adds extra meaning beyond the schema: it explains that the time window is optional, identifies format choices ('signed_json | csv | eat | stix'), states the default behavior (profile's first), and clarifies the 'regime' override semantics. This enriches the bare parameter descriptions and justifies a score above baseline.

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 ('Generates') and names the resource ('signed export bundle of your ledger') with detailed contents. It clearly distinguishes this export tool from siblings like audit_export by emphasizing the signed bundle, chain-integrity proof, and regime mapping.

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 how to use the tool: choose format via ?format= and override regime via ?regime=. It implies the optional time window and default format behavior, but does not explicitly mention when to use this tool instead of alternatives or when not to use it. Lacks an explicit exclusion clause, so not a 5.

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 the full burden. It discloses the scope (records from verdict-bearing calls while compliance is enabled), the fields each entry carries, and the filtering and pagination behavior. It does not mention ordering or error cases, but covers the essential behavioral traits well.

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: purpose, fields, and filtering/pagination. It is front-loaded with the core purpose, and every sentence provides necessary information without waste. The structure is logical and easy to scan.

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 (a paginated ledger) and the absence of an output schema or annotations, the description is quite complete. It covers the returned content, the filtering and pagination mechanics, and the scope. It could mention ordering, but overall it is sufficient for an agent to invoke 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 input schema already provides 100% coverage with descriptions for all four parameters. The description largely restates the schema ('Filter with from/to (ISO8601) and page with cursor (a seq) + limit (≤1000)') and adds marginal clarification that cursor is a sequence number, which the schema already notes. Thus, the baseline of 3 applies.

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 ('Returns') and clearly identifies the resource ('hash-chained decision records') with a precise scope ('one per verdict-bearing call... while compliance is enabled'). It distinguishes itself from siblings like compliance_export or audit_export by emphasizing the hash-chained structure and the included fields.

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 clearly implies when to use the tool: when you need your hash-chained decision records. It provides context by listing the qualifying call types and the filtering/pagination options. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.

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 that authentication is required, describes the underlying ledger as 'tamper-evident, retained record,' and notes that the configuration 'self-maintains' after configuration. While it doesn't explicitly state that the tool is read-only, 'Returns' implies it, and the added context about persistence is valuable.

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 and front-loaded with the core purpose. The first sentence is dense and specific. The second sentence about the compliance ledger adds useful system context, though it is slightly tangential to the profile tool itself. No unnecessary repetition, and it stays within an appropriate length.

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 is highly informative: it lists the exact fields returned (regime, retention_days, export_formats, enabled) and enumerates supported regimes and export formats. It also notes authentication. For a zero-param, no-output-schema tool, this is essentially 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?

The tool has zero parameters and an empty schema, which is fully covered (100%). Per the rubric, a baseline of 4 is appropriate for 0 params; the description naturally doesn't need to add parameter-level detail, and no such detail is missing.

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 opens with 'Returns your current compliance configuration' and specifies the exact scope (current configuration plus catalog of regimes and export formats). The verb 'Returns' clearly indicates a read operation, distinguishing it from siblings like compliance_configure (which likely modifies) and compliance_export (which likely exports).

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 states 'Authenticated,' indicating a prerequisite, and the read-only nature of returning a profile is clear. It doesn't explicitly name alternatives or exclusions, but the list of fields and catalog implies it is the go-to tool for inspecting current compliance settings, especially in contrast to configuration or export 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 and does an excellent job. It explains the recompute behavior, the conditional reason and first_break_seq fields, and the security property that TunnelMind cannot rewrite history before a signed checkpoint without detection—offering substantial insight beyond the tool's name.

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 compact yet information-dense, with no fluff. The first sentence front-loads the core mechanism and output, and the second sentence adds usage context and a security guarantee. Every clause earns its place, making it appropriately sized for a complex verification 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 no output schema and no annotations, the description thoroughly explains return values (including conditional fields) and the security context. It does not need to cover parameters since there are none. The description is complete enough for an agent to understand when and why to invoke this 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 zero parameters, so schema coverage is effectively 100% and there is nothing for the description to compensate for. Per the rubric, a tool with 0 parameters gets a baseline of 4, and the description appropriately focuses on behavior rather than unnecessary parameter details.

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 states a specific verb ('Recomputes') and resource ('your entire hash chain') and clearly describes the output (integrity report with entry_count, chain_head_hash). It distinguishes itself from sibling verify tools by focusing on server-side hash chain integrity and the signed checkpoint, making it the auditor's 'prove it' button.

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: it is the auditor's 'prove it' button, implying use when independent verification of chain integrity is needed. However, it does not explicitly name alternatives or state when not to use it, stopping short of full fallback 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 key is shown once, stored as SHA-256 hash (unrecoverable), limits (50/day, 1 per email, 3 per IP), and cost (free). No annotations exist, so description fully carries 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?

Concise and well-structured: overview, usage guidance, limits, and key recovery note. 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 one parameter, no output schema, and no annotations, the description fully covers input, behavior, limits, and implications, making it complete for agent decision-making.

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?

Although the schema defines email with format and example, the description adds context ('One email in') and confirms the email is the revocation handle, adding meaning beyond the schema 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 creates a free API key, distinguishing it from siblings like get_api_key (retrieve) and revoke_api_key (invalidate). It positions the tool as the step between anonymous and paid access.

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: when hitting anonymous rate limits or wanting persistent usage tracking. Implicitly suggests not to use if already have a key or need paid tier.

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 the full burden and does so excellently. It discloses the ~20 minute sweep interval, trigger conditions (verdict label flips, trust score crosses a band, signal set changes), the signature header scheme, the one-time return of the signing key, delivery body structure, and that the baseline verdict is captured at creation.

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 multi-paragraph but well-structured: purpose first, then webhook behavior, authenticity, delivery body, inputs, and requirements. Every sentence adds necessary detail without redundancy. It is long but appropriately sized for a complex webhook creation 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?

The description covers the full scope of the tool: creation inputs, recurring behavior, webhook signature scheme, delivery payload, and first-event semantics. Even without an output schema, it mentions that the signing_key is returned once at creation, giving agents a critical piece of the response. The description is remarkably 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 description coverage is 0%, so the description must compensate. It does with an 'Inputs (JSON body)' section that explains each parameter: node as 'the node to watch', callback_url as 'an https URL to receive deliveries', and events as optional/reserved defaulting to ['verdict_change']. This adds substantial meaning beyond the bare 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's action: 'Subscribe to a node (ip, domain, asn, or entity slug).' It also explains the webhook semantics, distinguishing it from sibling tools like get_subscription and delete_subscription. The verb 'subscribe' is specific and the resource (node) is well-defined.

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 context (setting up recurring change notifications) but does not explicitly mention when to use this tool versus alternatives like list_subscriptions or get_subscription. No exclusions or alternative tool names are provided, so guidance is only implied.

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 transparency burden, and it adds meaningful behavioral detail: it does not compute a fused verdict, it returns raw lens views, the coverage block indicates which lenses responded, and issued_by provides attribution. It does not mention error handling or rate limits, but for a read-only style lookup this is adequate and substantially beyond a bare restatement.

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 concise and front-loaded: the first sentence states the core behavior, the second clarifies use cases and alternatives, and the third adds response-relevant details (coverage, issued_by). Every sentence earns its place, with no filler or repetition of schema content.

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 single-parameter lookup tool with no output schema and no annotations, the description provides complete context: it names the three lens views, explains the no-fused-verdict behavior, points to alternatives for different needs, and highlights response fields needed for reasoning about partial data. This is sufficient for an agent to select and invoke 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?

There is only one parameter, node, and the schema already fully describes it (IPv4/IPv6 address, domain, ASN with optional AS prefix, or entity_slug; type auto-detected). The description adds no new parameter-specific details beyond calling it a 'node key,' so a baseline of 3 is appropriate given 100% schema coverage.

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 opens with a specific verb and resource: 'Returns all three lens views for a single node key without computing a fused verdict.' It also differentiates from siblings by stating what it does NOT do ('without computing a fused verdict') and by naming the raw-transparency use case, which clearly separates it from 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?

Usage guidance is explicit: 'Use this when you want raw transparency... and intend to make your own decision.' It also names specific alternatives ('For an opinionated verdict, call cross_lens_verify instead. For an agent-side allow/caution/deny gate plus signed consultation receipt, call preflight_should_i_act.'), giving clear when-to-use vs. when-not-to-use context.

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 behavior: streaming mode with Accept header, response structure with base record and lens views, fusion math with hard safety floors, in-band lens unavailability reporting, and 503 only when all lenses are down. It also covers claim-bearing calls bypassing cache and ADR-012, providing deep 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 structured with clear sections but is extremely verbose, covering streaming mode, fusion math, response layout, and a coverage matrix. While each section adds useful information, the sheer length may overwhelm an agent; the opening is not front-loaded with a succinct purpose statement, starting instead with 'A2 — the cross-lens join.'

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, nested objects, no output schema), the description thoroughly covers output structure, edge cases, and behavior under various node types. It explains the response shape (base record, lens views, cross_lens) and failure modes (in-band lens degradation, 503 conditions), making it complete 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?

The input schema already provides 100% parameter coverage with detailed descriptions for node, ait, and claimed_zone. The description adds minimal parameter-specific value beyond noting that weights and thresholds are per-request overridable, which is already implied by the schema. Therefore, it meets the baseline of 3 without exceeding.

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 'fuses them into one verdict on a single node key', combining Scry, Sigil, and GhostRoute lenses. This is a specific verb+resource (verify a node via cross-lens fusion) and distinguishes it from sibling tools like cross_lens_lookup by emphasizing the verdict generation and verification aspect.

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 extensive context on when the tool is applicable, including a coverage matrix for different node types and behavior under lens unavailability. However, it does not explicitly name alternative tools or give 'use this instead of X' guidance, leaving when-to-use vs alternatives implied rather than stated.

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

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

Annotations are absent, so the description carries full responsibility. 'Cancel a subscription' implies a mutation but does not disclose whether cancellation is reversible, what happens to the subscription's data, or side effects like billing or access changes. This is a significant transparency 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 extremely terse ('Cancel a subscription.') but this is under-specification rather than effective conciseness. It omits essential details that could have been included in a slightly longer but still efficient description.

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 mutation tool with no annotations, output schema, or parameter details, the description is insufficient. It does not explain return values, error conditions, or behavioral consequences, making it incomplete for an agent to invoke safely and understand outcomes.

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 'id' (string) with no description, and the tool description does not explain its meaning, format, or how it identifies the subscription. With 0% schema description coverage, the description fails to compensate.

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 ('Cancel') and resource ('a subscription'), clearly distinguishing it from siblings like create_subscription, get_subscription, and list_subscriptions. It is unambiguous about the core 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?

No usage guidance is provided. The description does not state when to use this tool, any prerequisites, or alternative tools to consider, leaving the agent without context for choosing it over other subscription-related 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?

With no annotations, the description carries the full burden and excels. It discloses the exact verdict computation, evidence attribution details, weight semantics (null = supplementary), P38 signed receipt commitment via evidence_digest, and explicitly addresses empty evidence as honest 'no corpus presence'. This provides comprehensive behavioral insight.

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 the core use case. Three paragraphs pack substantial detail without redundancy: purpose, evidence chain mechanics, receipt and edge-case behavior, and node key space. Every sentence contributes meaning.

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 no annotations, the description explains key output aspects: exact verdict, evidence chain attributes, weight interpretation, and cryptographic receipt via evidence_digest. It also clarifies the node key space and empty-evidence semantics, making the tool fully understandable for an agent.

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 already fully describes the single parameter with 100% coverage. The description adds only that 'node' uses the same key space as `/v1/verify`, which is minor contextual reinforcement. No new semantic meaning is introduced 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 starts with a clear directive: 'Call this when you need to ACT ON a verdict and prove why.' It specifies that the tool returns the exact verdict and a traced evidence chain, distinguishing it from siblings like verdict_lookup by emphasizing the evidence and cryptographic 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 states when to use the tool ('when you need to ACT ON a verdict and prove why') and notes that 'node' uses the same key space as `/v1/verify`. It doesn't explicitly name alternative sibling tools, but the usage context is clear and actionable.

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 carries the burden, disclosing that the receipt is stored in a public registry, verifiable at /verify/{receipt_id}, that signature may be empty if signing key is not configured, cost implications, and latency. It also explains deduplication and URL stripping.

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 (intro, usage, inputs, returns, exposure, cost, latency), each sentence providing essential information. It is front-loaded with the core functionality and avoids 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?

The description covers inputs, outputs, cost, latency, and alternatives comprehensively, despite lacking an output schema and annotations. It provides enough detail for an agent to invoke the tool correctly and understand its side effects.

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?

Even though schema coverage is 100%, the description adds meaningful details: 'Array of 1–50 fully qualified domain names', 'Duplicates are deduplicated', 'URLs are stripped to host component', and the relationship between `domain` and `domains` as a shorthand alternative.

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 states a specific action: 'Looks up each submitted domain in the TunnelMind tracker database, aggregates risk metrics... and issues a signed surveillance receipt.' It clearly distinguishes from siblings by naming alternatives like get_domain, get_receipt, and /v1/intel/*.

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?

It provides explicit 'Use this tool when' and 'Do NOT use this tool when' sections with concrete alternative tool names (get_domain, get_receipt, /v1/intel/*), giving clear context 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?

No annotations are provided, so the description carries the full burden. It discloses a rich set of behaviors: inline Ed25519 signing with key source, Receipt v1.0 envelope wrapping via ?receipt=true, content negotiation via Accept headers, free anonymous access with a separate rate-limit counter, and latency expectations (<100ms typical, <500ms cold). This is far beyond what structured fields would provide.

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?

Although lengthy, the description is excellently structured with labeled sections (Inputs, Content negotiation, Returns, Headers, Cost, Latency) and is front-loaded with the core purpose. Every sentence carries useful information; the bullet-style lists make it easily scannable for an agent.

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 complex (config bundle, content negotiation, signing, versioning, surfaces) and has no output schema. The description enumerates the returned fields (version, schema, issuer, system_prompts, tools.surface_subset, response_format, attestation_tiers, graph_state, references, bundle_signature, pin_recommended), lists relevant headers, and explains cost and latency. This is comprehensive enough for an agent to invoke and parse responses 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 description coverage is 67% (receipt and version have descriptions; surface does not). The description adds meaning beyond the schema: clarifies surface default as 'full surface', explains version pinning with '1' for latest 1.x.y, and introduces Accept header content negotiation not present in the schema. It doesn't fully explain the scry/sigil surfaces, but adds enough to merit above baseline.

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 opens with a specific verb and resource: 'Returns the TunnelMind analyst config bundle.' It clearly distinguishes from sibling data tools by positioning itself as the canonical config endpoint and explicitly excluding individual data tool calls in the 'Do NOT use' section, naming alternatives like check_receipt_revoked and @tunnelmindai/receipt-verify.

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 concrete scenarios (configuring a new LLM runtime, verifying the system prompt, BYOM deployments) and named alternatives (use data tools directly, check_receipt_revoked). This gives clear guidance for an agent to select this tool over 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?

No annotations are present, so the description carries full behavioral disclosure. It reveals that the request is free and does not count against the daily limit, notes that 'requests_today' is best-effort from KV and resets at UTC midnight, and gives latency estimates. It also clarifies auth via the Authorization header.

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 moderately long but highly structured with sections for use cases, returned fields, cost, and latency. Bullet points make it scannable, and there is no redundancy or filler.

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 fully compensates by specifying all return values, including edge cases like null last_used and unlimited enterprise limit. Usage guidance and cost/latency details make selection and invocation unambiguous.

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 zero parameters in the schema, the description states 'No body or query parameters' and clarifies that auth comes from the Authorization header, which adds meaning beyond the empty schema. It also enumerates the exact return fields with types and edge cases.

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 opens with a specific verb 'Returns' and enumerates exactly what is returned for the API key used in this request. It distinguishes from sibling tools like revoke_api_key and create_free_key by focusing on the calling key's quota and metadata.

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 lay out appropriate scenarios (monitor quota, check tier/limit, confirm active) and exclusions (managing multiple keys, needing tracker data) with an alternative ('use the tracker endpoints 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 provided, the description carries the full burden and delivers rich disclosure: it explains the polling source (RIPEstat), the self-baselining mechanism, the event-type taxonomy with severity mapping, and return semantics including 'count is the full filtered set; events is bounded by limit, newest first.' This goes well beyond what structured fields provide.

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 dense but purposeful; every sentence contributes technical or behavioral context. It front-loads the core purpose, then moves through usage and field semantics, using a clean list for event types and no filler.

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 read-only lookup with no output schema, the description fully equips the agent: it explains all event_type values, severity implications, `prev_origins`, pagination semantics, and the honest meaning of an empty `events` array. It even notes reserved event types for future monitor passes, leaving no critical interpretation gap.

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 the baseline is 3, but the description adds meaningful semantics: it explains that `limit` bounds the `events` array while `count` remains the full filtered set, and that results are newest-first. It also clarifies `resource` as a watched CIDR or ASN, which reinforces but goes slightly 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 opens with a specific verb and resource: 'Returns the routing anomalies the bgp-monitor has observed against TunnelMind's BGP watchlist', immediately distinguishing it from sibling lookup and verification tools. It also grounds the tool in the 'witnessability layer's routing dimension', making its unique role clear.

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 instructs when to use: 'Use this to check whether a prefix or ASN you depend on... has shown a hijack-shaped routing event.' This is clear context, but it does not name sibling alternatives or state when not to use it, so it misses the explicit exclusion criterion for a 5.

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. It discloses automatic subdomain resolution, the live probe fallback, tier-dependent return fields, 404 errors, cost, and latency. No hidden behaviors remain.

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 excellently structured with clear sections (overview, when to use, when not to use, inputs, returns, cost, latency). Every sentence provides necessary operational detail; nothing is filler. The opening sentence immediately establishes the core 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?

Gven the lack of an output schema, the description comprehensively covers return values (free vs pro fields, live_lookup flag, 404 response), error conditions, cost, and latency. It is fully self-contained 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?

While schema already specifies the `domain` parameter, the description adds significant meaning: subdomain normalization (ads.doubleclick.net → doubleclick.net), concrete examples, and behavioral implications (www stripping, live probe consequences). This goes well beyond the schema's minimal 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 'the complete surveillance intelligence record for a domain name' and details both database and live-probe modes. It explicitly differentiates from siblings by naming `search` and `get_entity` as alternatives for different 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?

Extensive 'Use this tool when' scenarios are listed (tracking behavior, ownership research, header checks, risk scoring) alongside explicit 'Do NOT use' cases with named alternative tools. This leaves no ambiguity about when to choose 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 present, the description carries the full burden and excels: it discloses tier-based output limits (5 vs 200 domains), cost context (free tier vs Pro/enterprise), return fields, additional fields for higher tiers, and latency expectations (<150ms typical, <400ms p99). This goes well beyond a simple read-only statement.

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 (Returns, Use when, Do NOT use, Inputs, Cost, Latency), but the returns information is duplicated: the opening paragraph lists fields and domain counts, then a later 'Returns' section repeats them. This small redundancy prevents a perfect score.

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 simple one-parameter lookup with no output schema, the description is highly complete. It covers purpose, alternatives, input semantics, tier behavior, cost, latency, and return content, leaving no significant gap in understanding.

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 compensates fully for the single parameter slug. It explains that it is a URL-safe entity identifier (lowercase, hyphens) and provides concrete examples like alphabet, meta, and oracle-data-cloud, adding meaning beyond the schema's pattern.

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 opens with a specific verb and resource: 'Returns an entity record for a surveillance company or data broker,' listing the exact fields included. It clearly distinguishes itself from siblings like get_domain, list_entities, and search via explicit 'Do NOT use' guidance.

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' conditions and equally explicit 'Do NOT use this tool when' exclusions that name alternative tools (get_domain, list_entities, search). This gives the agent clear decision criteria for 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 provided, the description carries the burden of behavioral disclosure. It covers the read-only nature ('Public read'), empty aggregate return (`total: 0` and `signal: none`), and the derivation rules for `signal`. It could be more explicit about the response shape (e.g., whether a `score` field is always present), but covers key behaviors well.

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 in three short segments: purpose, empty aggregate edge case, and signal derivation logic. Every sentence adds value with no filler or repetition. It's front-loaded with the core 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?

For a simple one-parameter read tool with no output schema, the description explains the main return value (`total` and `signal`) and the signal derivation thresholds. It doesn't explicitly describe the full response structure (e.g., whether a `score` field is present), but it's reasonably complete for the tool's simplicity.

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 already provides 100% coverage of the `node` parameter with a clear description ('ip, domain, asn, or entity slug.'). The tool description doesn't add further parameter-specific semantics beyond contextualizing node as the subject of the outcome aggregate, so baseline 3 is appropriate.

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: 'Public read of the crowd-sourced outcome aggregate for a node — how callers reported their real-world results after acting on its verdict.' It uses a specific verb ('read') and resource (outcome aggregate), and explicitly distinguishes it from a trust verdict, differentiating it from sibling tools like explain_verdict or verdict_lookup.

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 about when to use it: it's an advisory signal on real-world outcomes, not a trust verdict. It also explains empty aggregate behavior. However, it doesn't explicitly name alternative tools or say 'use this instead of X', so it stops short of full 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 carries the full burden and does so excellently. It discloses the SLO rule (2x cadence), explains that cadence comes from code/cron (never asserted), details null-tolerance behavior (null timestamps never fabricated), and reveals caching behavior. This goes well beyond a basic summary and gives the agent critical behavioral expectations.

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 reasonably concise given the complexity, but the opening 'D4 — the freshness contract' is somewhat cryptic and may require domain knowledge. Still, every sentence contributes useful detail, and the structure with clear paragraphs aids readability. It could be slightly tighter but earns a strong score.

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?

There is no output schema, so the description must explain return values. It fully covers the per-lens fields, the per-worker breakdown for GhostRoute, the SLO calculation, null-handling, and caching. For a read-only status tool, this is remarkably complete and leaves no ambiguity about what the agent will receive.

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 the schema coverage is 100% (trivially). Per the baseline for no-parameter tools, a score of 4 is appropriate, since there is no parameter meaning to add. The description does not attempt to invent parameters and stays focused on output behavior.

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 function: it reports freshness metrics per lens (Scry/Sigil/Tracker/GhostRoute), including observation timestamps, cadence, SLO, age, and whether the SLO holds. This is a specific verb ('reports') plus a well-defined resource (freshness contract), and it distinguishes itself from sibling tools like get_stats or snapshot_data by focusing on live freshness data.

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 context ('a PDP can gate on') and contrasts with the weekly /v1/stats snapshot, explaining why this tool is cached only 5 minutes. However, it does not explicitly name when to use this over alternatives or specify exclusion criteria. The indirect comparison provides clear context but stops short of explicit 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 behavioral disclosure burden. It explicitly states the tool does NOT return the signature for anti-phishing protection, lists return fields, indicates 404 for missing IDs, and discloses cost and latency, providing comprehensive transparency beyond what any schema would reveal.

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 clear sections (purpose, usage, inputs, returns, cost, latency). While it is somewhat long, every sentence provides valuable information. The latency and cost details are beneficial but could be considered supplementary, yet they do not detract from the overall 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?

For a single-parameter tool with no output schema, the description covers all necessary aspects: detailed return fields, error handling (404), cost, latency, and explicit usage guidance. It is complete enough for an agent to invoke the tool correctly without additional 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 thoroughly explains receipt_id, including its source (receipt document), path location, alphanumeric format with hyphens, and max length. This adds meaningful semantic context beyond the schema's pattern and maxLength 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 metadata for a TunnelMind surveillance receipt, using a specific verb and resource. It explicitly distinguishes itself from verify_receipt by noting it does NOT return the signature, and explains the difference between metadata and content 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 provides explicit 'Use this tool when' and 'Do NOT use this tool when' sections, naming verify_receipt as the alternative for verification. This clearly guides the agent on when to select this tool vs. 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?

Despite no annotations, the description thoroughly discloses behavioral traits: no rendering/browser/authorization, the three-value coverage vocabulary with no fourth state, the deliberate narrowness of claim_vs_conduct (unverifiable default), and the proxy effect on connection properties. This is comprehensive and prevents misuse.

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 bullet points, but is somewhat long due to detailed explanations about coverage states, JA4 limitations, and claim_vs_conduct behavior. While these details are valuable, a few sentences could be tightened without losing essential 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?

With no output schema or annotations, the description carries the full burden of explaining return data and operational nuances. It covers the three data surfaces, coverage states, edge cases, usage exclusions, and receipt behavior, making it complete for reliable tool selection and 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?

The only parameter `receipt` is explained in the description ('?receipt=true attaches a signed Receipt v1.0 committed to the transparency log'), fully compensating for the schema's 0% description coverage. The boolean semantics and its effect are clear.

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 opens with 'The caller is the subject' and enumerates three surfaces (client, state, network), clearly defining the tool as returning self-view data about the caller. It distinguishes from sibling tools by explicitly stating 'Do NOT use when... other host', 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 dedicated 'Use this tool when' and 'Do NOT use this tool when' section, explicitly naming the alternative for other hosts (POST /v1/verify/{node}). It also adds the proxy caveat requiring direct calls to data.tunnelmind.ai, providing clear context 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?

With no annotations, the description fully discloses critical behaviors: independent, null-tolerant counts ('reports null, never a silent zero'), cacheability for ~10 minutes, and public accessibility. These traits go beyond the basic 'read-only' implication and are genuinely useful for an agent deciding to call the 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 compact yet dense. The first sentence defines the tool, the second clarifies scope and distinction, the third gives usage context and examples, and the last addresses edge-case behavior and caching. Every sentence earns its place, and key information 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 zero-param read-only tool, the description covers the essential contextual ground: what's included (publishers, SSPs, DSPs, etc.), how to use it, and behavioral quirks (null tolerance, cache). The only minor gap is not describing the exact return structure (since no output schema exists), but the descriptive categories are likely sufficient for an agent.

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, so the baseline is 4. The description adds no parameter syntax (unnecessary), but it does reference the 'scry block' in the output, which indirectly hints at response structure. This is acceptable given the empty input 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 nails the purpose: a 'state of the corpus' readout that spans multiple layers. It uses a specific verb ('get') and resource ('stats') while detailing exactly what is covered, and it explicitly distinguishes from Scry-only sensor stats, effectively differentiating it from potential 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?

It provides explicit when-to-use guidance: 'Use it to cite live coverage.' It also offers a clear alternative/exclusion: 'Distinct from the Scry-only sensor stats at api.tunnelmind.ai/v1/stats'. This tells the agent both when to invoke this tool and when not to.

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 the transparency burden. It discloses that the signing key is redacted in the response, which is a useful behavioral detail. However, it does not mention other behaviors such as authentication requirements, error conditions, or response format beyond the redaction note.

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, front-loaded sentence that conveys the core action and a key output detail. No filler words or 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?

For a simple read operation with one parameter and no output schema, the description provides the essential purpose and a notable output caveat. However, it does not describe the full returned subscription object or any side effects, leaving some gaps for an agent to infer.

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 a single 'id' parameter with no description (0% coverage). The tool description does not explain what 'id' refers to or its expected format, although the context of 'subscriptions' implies it is the subscription identifier. This falls short of compensating for the lack of schema documentation.

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 the specific verb 'Read' with the resource 'subscriptions', making the operation clear. The parenthetical 'signing_key redacted' adds a distinctive detail that helps differentiate from related tools like 'list_subscriptions' or 'delete_subscription'.

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 phrasing 'one of your subscriptions' implies this is for reading a single subscription, contrasting with the sibling 'list_subscriptions' for multiple. However, it does not explicitly mention alternatives or when not to use, so guidance is implicit rather than explicit.

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 behavior: polling semantics, terminal statuses, result/error fields, expiration time, cost (free), and latency. This goes well beyond the minimal expectation.

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 (Inputs, Returns, Cost, Latency). Every sentence contributes valuable information without verbosity, making it easy to scan and understand.

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 enumerates all possible statuses and the conditions for `result` and `error` fields, making the tool's behavior fully comprehensible. Cost and latency further enhance completeness.

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 `task_id` is explained as a 26-char ULID returned in the 202 response, adding useful origin context beyond the schema's pattern and example. With 0% schema description coverage, this compensation is strong.

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 current status of a task created by an `?async=true` intel request', which is a specific verb and resource. It distinguishes itself from sibling tools by explicitly contrasting with `stream_task`.

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 context and name alternatives like `stream_task`. It also specifies prerequisites, such as having a task_id from an async request.

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?

Even with no annotations, the description fully discloses behavioral traits: append-only change-log, one row per observed change plus daily heartbeat, the honest interpretation of 'first_recorded', the start date (2026-08-04), and the zero-rows behavior for unverified domains. This exceeds what annotations typically provide and gives clear expectations about data completeness.

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: it opens with the core purpose, then details the data composition, and finally explains honesty semantics and edge cases. While it is longer than strictly necessary, each sentence adds meaningful context—such as what the tuple contains and the zero-rows behavior—so it 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?

For a simple tool with one parameter and no output schema, the description is quite comprehensive. It explains what data the history contains, the semantics of timestamps, and the behavior for unverified domains. It could be improved by briefly indicating the output format (e.g., list of change-log rows), but the description covers the most important 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?

The description does not explicitly explain the 'domain' parameter, but it repeatedly references domains ('every domain verify', 'a domain nobody has verified'), implying that the parameter is the domain to look up. Since the schema has no description and coverage is 0%, the description should compensate more, but for a single obvious parameter, a score of 3 is 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?

The description clearly states it provides the over-time history ('the radar's evolution') of domain verification observations, and details exactly what data is recorded in the change-log. This distinguishes it from sibling tools like status_history or snapshot_diff by focusing on the append-only history of domain machinery tuples.

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 this tool is for retrieving historical change-log data for a domain ('Every domain verify appends...'), but it does not explicitly state when to use this tool versus alternatives or provide exclusions. It explains the data source and semantics, but not the decision context for choosing it over other lookup 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?

With no annotations, the description carries the full burden. It discloses that this is a cached corpus read with typical <300ms latency, and emphasizes the distinction between claimed and verified sovereignty via the `verified_sovereign` field. This is transparent for a read-only lookup, though it could mention auth or error behavior.

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 use cases, inputs, returns, and latency. Every sentence earns its place; there is no fluff, and the main purpose 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 one-parameter lookup tool with no output schema, the description is remarkably complete: it explains inputs, lists all return fields, notes latency, and gives usage scenarios. It fully equips an agent to invoke it 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 0%, but the description fully compensates by explaining that `entity` is a domain or ASN in the 'AS####' format, and marks it as path/required. This adds meaning beyond the bare string type in 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 checks whether a domain or ASN belongs to a known AI company's infrastructure and reports claimed sovereignty. It specifies the resource (domain/ASN) and outcome, distinguishing it from sibling lookups like ghostroute_asn_lookup by adding sovereignty claims.

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' bullets with concrete scenarios (identifying AI infrastructure, enriching endpoints before inference). It does not explicitly mention when not to use or alternative tools, so it falls short of a 5, but it gives clear context.

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 `{matched:false}` return on misses, a cached corpus with RDAP fallback, and typical sub-300ms latency. This adds behavioral depth beyond simply stating 'returns data', though it does not cover auth or error states.

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 into purpose, usage, inputs, returns, and latency sections. It is front-loaded and efficient, though the 'long-term moat' phrase adds a touch of flourish without being harmful.

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 one-parameter lookup with no output schema, this description is comprehensive: it documents return fields, input format, usage context, latency, and the not-found sentinel. No critical gaps are apparent.

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 zero description coverage for the `asn` parameter, so the description compensates by specifying the format ('AS#### or a bare AS number') and that it is a required path parameter. This is more meaningful than the bare 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 opens with a specific verb ('Returns') plus the resource ('GhostRoute's ownership-graph record for an autonomous system') and enumerates the exact data fields returned. It clearly distinguishes this from sibling lookups by focusing on ASN ownership and jurisdiction rather than AI or domain-specific data.

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?

An explicit 'Use this tool when' section provides two concrete scenarios: needing corporate owner/jurisdiction from an origin ASN, or assessing whether an ASN belongs to a cloud front vs. real operator. It lacks explicit exclusions or alternative tool names, but the context is sufficiently 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?

With no annotations, the description reveals that it performs live lookups, returns caveats/penalties, and can optionally persist a signed receipt. It also states typical latency, though it doesn't disclose auth or rate limits.

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 sections (use-when, inputs, returns, latency) and front-loaded with purpose, but it's longer than necessary—some elaboration could be tightened.

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 tool with no output schema and no annotations, this description provides an exceptionally complete picture: return fields, scoring tiers, caveats, latency, and even the receipt identifier format. It leaves little ambiguity.

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 already covers both parameters at 100%; the description adds the accepted formats (IPv4/IPv6, domain, ASN, cert hash) and details the receipt's persistent ID format, going 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 names a specific verb (verifies routing-integrity/sovereignty) and resource (endpoint infrastructure), and clearly distinguishes this 'fourth lens' from sibling tools by explaining the claim-vs-reality scoring.

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 lists concrete scenarios ('Use this tool when...') such as routing data to jurisdiction-claiming endpoints or detecting masquerading/hijacked origins. It doesn't mention when not to use it or alternatives, but the guidance 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?

With no annotations provided, the description carries the full burden and does well: it discloses durability, deduplication, immutability ('immutable first-detection log'), the meaning of an empty feed ('healthy CT ecosystem returns an empty feed'), and latency (KV-cached 1m, typical <200ms). However, it does not explicitly state read-only semantics or mention auth/rate limits, though the phrasing implies 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?

The description is moderately long but well-structured: purpose, usage, inputs, returns, latency. It is front-loaded with the core purpose and every section earns its place. It could be tightened slightly, but the structure aids comprehension.

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 there is no output schema, the description thoroughly covers the return shape: both the summary fields (total, undelivered, rewinds, forks, bad_signatures, last_detected_at) and the alerts array fields (kind, severity, log_url, log_operator, from_tree_size, to_tree_size, distinct_roots, event_observed_at, detected_at, delivered). It also explains event semantics and latency, making it complete for an agent to 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?

The schema provides only a parameter named 'limit' with numeric constraints and no description (0% schema coverage). The description compensates by explaining 'limit (query, optional): max recent alerts, 1–200, default 50.' This adds the semantic meaning of limiting recent alerts, which is exactly what the schema lacks.

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 opens with a specific verb and resource: 'Returns the durable, deduplicated ledger of CT equivocation events.' It enumerates exact event kinds (tree_size_rewind, root_fork, sth_signature_invalid) and explicitly contrasts with '/v1/ghostroute/witness' (live computed health), clearly distinguishing itself from the sibling ghostroute_ct_witness tool.

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' bullets: for a chronological record of CT trust violations and for polling new events (check summary.last_detected_at). It also implies when not to use it by stating it is 'not live state' and referencing the witness endpoint for live health. This gives clear contextual guidance and an alternative.

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 and does so richly: it discloses failed attempts include a `reason`, that a cert suddenly unprovable is itself a signal, and that results are KV-cached for 5 minutes with typical latency under 300ms. This goes beyond a simple 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?

The description is well structured with clear sections (Use, Inputs, Returns, Latency) and front-loaded purpose. Every sentence contributes meaningful context, from the cryptographic explanation to latency boundaries, with no filler.

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 no annotations, the description provides a complete picture: purpose, when to use, input semantics, output field details, interpretation of failures, and performance expectations. It is self-sufficient for an AI agent to select and invoke 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 0%, but the description fully compensates: `domain` is explained as an optional hostname filter, while `limit` is documented as max recent rows with range 1–200 and default 50. This adds real meaning beyond the bare 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 opens with a specific verb and resource: 'Returns GhostRoute's per-cert inclusion proofs.' It clearly distinguishes this from sibling tools by emphasizing cryptographic demonstration of CT log inclusion, which differs from alerts, witness, and verification 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?

Explicit 'Use this tool when' bullets provide clear use cases: checking a specific domain's live cert provability or getting a corpus-wide rollup. It doesn't name alternative sibling tools or state when not to use it, but the context is clear and actionable.

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 the full burden. It discloses detailed behavior: returns specific fields for logs and regressions, lists regression violation kinds, states latency (<300ms), caching (KV-cached 5m), and update frequency (twice a day). It also explains the trust context ('Proof the platform holds its own signature-checked roots'). This is a rich, transparent 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 well-structured with clear sections (purpose, when to use, inputs, returns, latency). It is front-loaded with the main function, and every sentence adds value—covering output fields, regression kinds, and performance. No fluff or 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, the description fully documents the return structure, including the summary fields, per-log array, and regressions array with their possible kinds. It also covers use cases and performance characteristics, making the tool fully actionable for an agent.

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 an empty input schema, so the baseline is 4. The description explicitly states 'Inputs: none,' confirming there is nothing for the agent to configure. No additional parameter semantics 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 opens with a precise verb, 'Returns GhostRoute's first-party Certificate-Transparency witness state: the latest signature-verified Signed Tree Head (STH) for every trusted, non-Google CT log... plus a regression scan.' This clearly states what the tool does and its scope (corpus-wide), and distinguishes it from per-certificate tools with the phrase 'not one cert.'

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 an explicit 'Use this tool when' section with two specific conditions: 'corpus-wide CT witness health' and detecting log misbehavior. It also excludes per-certificate use with 'not one cert,' but it does not name alternative sibling tools, so it stops short of a full 5.

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 the full burden. It discloses that the tool returns 'the full persisted receipt row (routing, cert, sovereignty fields + signature)' and notes typical latency (<200ms) and that it is a 'single indexed read'. This implies a read-only, fast operation without needing to state explicit permissions.

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 (Inputs, Returns, Latency). Each sentence provides necessary information without redundancy. It is appropriately sized for a simple lookup tool and the key purpose 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?

Given the tool has only one parameter, no output schema, and no annotations, the description covers all essential aspects: what it does, when to use it, the input format, the return content, and expected performance. It is complete enough for an agent to select and invoke 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 only lists receipt_id as a string with no description, so schema coverage is 0%. The description compensates fully by specifying the exact format 'GR-YYYY-NNNNNNN' and noting it is a required path parameter. This adds critical 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 opens with a specific verb ('Retrieves'), a specific resource ('signed GhostRoute receipt'), and a precise identifier format ('GR-YYYY-NNNNNNN'). It also states the tool's purpose ('independent audit of a past sovereignty verdict'), which clearly distinguishes it from generic receipt lookups.

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 'Use this tool when' section with two concrete scenarios: confirming a receipt's contents/signature and reconciling an action log. This gives clear context, though it does not explicitly name alternative 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?

With no annotations provided, the description carries the full burden and does so admirably. It discloses the exact return fields ('ok', 'ts'), cost ('Free'), authentication needs ('No API key required'), rate limits ('Not rate-limited'), and latency (typical and p99). No contradictions with annotations since none exist.

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 (what, when, inputs, returns, cost, latency). Every sentence serves a purpose—no fluff. It is slightly long but highly informative, making efficient use of space.

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 the tool's simplicity, the description covers all essential contexts: purpose, use cases, non-use cases, inputs (none), outputs (with descriptions), cost, and performance. It is fully complete for an agent to decide when and how to invoke it, especially given the empty schema and 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 tool has zero parameters, and the description explicitly states 'Inputs: None.' This aligns with the baseline of 4 for zero-param tools and adds a useful explicit confirmation. Since there are no parameters to document, the description cannot add more value.

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 function: 'Returns a minimal status object confirming the API is alive.' It uses a specific verb ('returns') and resource ('status object'), and distinguishes from siblings by explicitly directing away from data retrieval tools like get_domain and search.

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, with concrete scenarios (connectivity verification, 503/504 recovery) and named alternatives (get_domain, search). This is exemplary 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?

Since no annotations are provided, the description carries the full burden. It transparently discloses the signals probed, return shape (boolean flags plus agent_surface_score 0-8), cost (free), and latency (typical 2-5s, p99 8s). It does not detail failure modes or edge cases (e.g., unreachable domains), but the core behavioral profile is well 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-structured with clear sections: purpose, when to use, when not to use, inputs, returns, cost, and latency. Every section earns its place, and the core purpose is front-loaded. No redundant or filler content.

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 absence of an output schema, the description fully specifies the output (boolean flags and integer score) and provides cost and latency. It also covers use cases, alternatives, and input requirements. This is complete for a signature probe tool, leaving little ambiguity about behavior or results.

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 high (67%), and async/receipt already have descriptions in the schema. The description's Inputs section only mentions 'domain' as 'Domain to probe', adding marginal meaning beyond the schema's example. It doesn't comment on the async or receipt parameters at all, but they are adequately documented in 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?

States a specific verb ('Probes') and resource ('a domain for known AI agent integration signals'), enumerating the exact signals (llms.txt, ai.txt, etc.). Clearly differentiates from siblings like intel_http, intel_robots, and get_domain by naming them in the 'Do NOT use' section.

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' bullet lists, naming specific alternative tools (get_domain, intel_robots, intel_http) and the exact scenarios that call for them. This gives clear decision 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, the description carries the transparency burden. It discloses the live network request nature, 5-redirect limit, 6-second timeout, return schema details, free cost, and 1-3s typical latency. It even notes that async may be needed for chaining calls, making behavior predictable.

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 organized with labeled sections (Use this tool when, Do NOT use, Inputs, Returns, Cost, Latency), each earning its place. Information is scannable and front-loaded with the core action.

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 high behavioral complexity, the description provides complete operational context: return fields defined, timeout, cost, and explicit alternative routing. An agent could confidently decide to invoke or avoid this 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 67% (async/receipt described; domain only has an example). The description compensates by explaining domain format ('Can include or omit https://') with examples. Async and receipt already have schema descriptions, so the tool covers all parameters 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 opens with a specific verb+resource: 'Makes a live HEAD request to the target domain' and enumerates unique outputs (redirect chain, security header score, CSP actors). It distinguishes itself from siblings through the 'Do NOT use' section, naming intel_stack and intel_robots as 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?

Lists explicit use cases ('verify whether a site enforces HTTPS and HSTS', 'inspect third-party scripts via CSP') and explicit exclusions with tool alternatives ('use get_domain', 'use intel_stack', 'use intel_robots'). This leaves no ambiguity about placement among the sibling set.

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 the full burden of behavioral disclosure. It covers the operation (fetching homepage, scanning for patterns), return values (injection_signals, risk_level), cost (free, no API key), and latency (2-4s typical, p99 7s). It also explains the risk level scale. This is comprehensive and 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 (Purpose, Use when, Do NOT use when, Inputs, Returns, Cost, Latency). It is front-loaded with the primary purpose and every sentence adds value without fluff. Despite being moderately long, it remains highly readable and organized.

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 explains return values (injection_signals, risk_level) and the risk scale. It covers cost, latency, use cases, and exclusions. It also explicitly states the scope (domain's homepage) and does not overreach. For a tool with this complexity, the description is complete and leaves no significant gaps.

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 async and receipt with descriptions, but domain lacks a description. The tool description adds 'Domain to scan' for domain and provides overall context for using the tool. It doesn't elaborate on the optional parameters, but the schema does, so the description adds meaningful value to the required parameter and compensates for the missing schema 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's purpose with a specific verb and resource: 'Fetches a domain's homepage and checks for content patterns that could constitute prompt injection attacks against AI agents.' It lists concrete signals like hidden text, invisible divs, and AI-ignore comments, and explicitly distinguishes from sibling tools by naming alternatives for related but different tasks (tracker surveillance, opt-out signals, agent surface).

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, listing concrete scenarios and alternative tools (get_domain, intel_optout, intel_agent). This makes the decision boundary crystal clear for an 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 the description carries the full burden. It discloses cost, latency (typical and p99), and the exact output fields. It implies a read-only check (no mutation implied). Missing minor details like rate limits or error behavior, but for a simple probe tool this is strong transparency.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses cost ('Free. No API key required.'), latency (typical 1-2s, p99 6s), return value details, and the truncation of raw output to 4096 characters. It does not explicitly mention rate limits or other failure modes, but the disclosed information is meaningful and goes beyond what annotations would provide.

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: overview, use cases, exclusions, inputs, returns, cost, latency. Every section adds useful information without redundancy or padding. It is longer than a minimal description but earns its length by providing actionable detail.

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 having no output schema, the description enumerates the exact return fields (robots_txt_found, ai_crawlers_blocked, all_blocked, raw) with explanations, which is essential for an agent to interpret results. Combined with usage guidance, cost, latency, and parameter info, the description fully compensates for missing annotations and schema detail.

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 67% (domain lacks a description, async/receipt have descriptions). The description adds context for the primary `domain` parameter ('Domain to probe') but does not mention async or receipt at all. The schema already covers those, and the description's domain context is marginal, so the value added beyond structured fields is limited.

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 opens with a specific verb+resource: 'Retrieves the target domain's robots.txt file and parses it for AI crawler disallow rules.' It clearly distinguishes from sibling tools by naming alternatives like intel_optout, intel_stack, and get_domain. This is precise and 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 'Use this tool when' and 'Do NOT use this tool when' sections give concrete decision criteria and name specific alternative tools (intel_optout, intel_stack, get_domain). This is exactly the level of guidance needed for an agent to choose correctly.

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 transparency burden. It discloses the 32KB limit, detection signals (meta tags, script src, headers, cookies), cost (free, no API key), and latency (typical/p99). It does not explicitly state read-only/non-destructive, but the fetching and fingerprinting behavior implies it. This is strong disclosure for a read-like 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: main purpose, usage conditions, input list, return fields, cost, and latency. Every section adds essential information without unnecessary verbosity. Front-loaded with the core 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?

The description covers the tool's purpose, inputs, return values, cost, latency, and exclusions. It even details the detection methods. Given no output schema, the 'Returns' section is especially valuable for setting expectations. This is a comprehensively specified tool description.

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 67%, leaving 'domain' without a schema description. The description compensates by listing 'domain (query, required): Domain to fingerprint.' It does not describe async or receipt beyond what the schema already provides, but the key required parameter gets semantic clarity.

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 the tool fetches HTML and response headers then fingerprints for CMS, frameworks, CDN, and analytics. It uses a specific verb ('fetches', 'fingerprints') and names the resource (domain's HTML/headers), clearly distinguishing its role from sibling tools like intel_http.

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, naming specific alternatives (intel_http, get_domain, intel_robots). This gives clear decision guidance for 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 provided, the description fully discloses behavior: pagination mechanism (cursor-based), ordering, filtering semantics, return structure including meta fields, cost/free-tier limits, and latency expectations. No hidden side effects or prerequisites are omitted.

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 with clear sections (overview, when to use, inputs, returns, cost, latency). It is slightly longer than necessary but every sentence adds value, and the structure aids comprehension. A minor trim could make it more concise, but it earns a strong score.

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 4 parameters, no output schema, and no annotations, the description covers all necessary context: usage scenarios, parameter details, return format, pagination, rate limits, and performance. The agent has everything needed to call 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?

Schema description coverage is 0%, but the description explains every parameter in detail: category enum values, min_score semantics (exclude below), limit max/default, and cursor usage. This fully 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 opens with a specific verb and resource: 'Returns a paginated list of domains from the tracker database.' It clearly states ordering and filtering capabilities, and distinguishes from siblings by explicitly naming alternatives like get_domain, search, and get_entity in the 'Do NOT use' section.

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' lists with concrete scenarios and named alternatives. This gives the agent clear decision criteria for selection versus other 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?

With no annotations, the description carries the full burden and excels: it discloses pagination behavior (next_cursor, has_more), rate limits (free tier limits, request per day), latency expectations, and return fields. This is rich behavioral context beyond a simple read-only hint.

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 (purpose, when to use/not use, inputs, returns, cost, latency). Each sentence adds value, and the formatting makes it easy for an agent to parse quickly without unnecessary 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?

Given no annotations or output schema, the description independently covers purpose, usage guidance, parameter details, return format, pagination, cost, and latency. It is complete for an agent to know exactly what this tool does and when to invoke 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?

Schema description coverage is 0%, but the description fully explains all three parameters: `industry` with examples, `limit` with tier-dependent max/default, and `cursor` with source from previous response. This compensates completely 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 opens with a specific verb and resource: 'Returns a paginated list of corporate entities in the TunnelMind surveillance database.' It clearly states what data is included and explicitly differentiates from siblings by naming `get_entity`, `search`, and `list_domains` in the 'Do NOT use' section.

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, listing concrete scenarios and naming the alternative tools for each exclusion case. This gives clear, actionable guidance for 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?

The description adds value beyond the absence of annotations by disclosing that the signing_key is redacted and that an API key is required. However, it does not explicitly state the read-only nature, error behavior, or response format. Given no annotations, more could be disclosed, but the 'Returns' phrasing strongly implies a safe 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?

The description is two concise sentences with no wasted words. It front-loads the action ('Returns the caller's...') and adds essential detail (redaction and auth) 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?

For a simple list tool with no parameters and no output schema, the description covers the core purpose, the scope (caller's subscriptions), the statuses (active/inactive), and important behavioral notes (signing key redacted, API key required). It is slightly sparse on the exact return shape (e.g., array of objects), but given the tool's simplicity, it is adequately 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?

The tool has zero parameters, and the schema coverage is 100%, so there are no parameter semantics to document. The description correctly avoids inventing parameters, and the baseline for 0-param tools 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's function with a specific verb ('Returns'), the resource ('subscriptions'), and a scoping qualifier ('caller's') that distinguishes it from sibling tools like get_subscription, create_subscription, and delete_subscription. It also specifies it covers both active and inactive subscriptions, leaving no ambiguity.

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 by indicating this returns the caller's own subscriptions, implying a listing operation, and notes the prerequisite of an API key. It doesn't explicitly exclude alternatives, but the context plus the presence of sibling tools like get_subscription (single) and delete_subscription makes the intended usage evident.

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 fully carries the transparency burden. It goes well beyond basics by disclosing the bounded +0.05 tracker bonus, the fact that absence is never a penalty, default thresholds, override capability, the 5-minute signed receipt with sub claim, and optional AIT witness chaining.

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 denser than typical MCP tools but well-structured: purpose is front-loaded, followed by receipt rationale, AIT behavior, tracker semantics, and defaults. The 'commodity-shaped' phrasing is a bit stylistic but not wasteful.

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?

It covers decision logic, thresholds, tracker behavior, AIT chaining, receipt purpose and TTL. However, with no output schema, it does not explicitly specify the full response shape beyond sigil_token and sub, nor potential error/edge conditions, leaving slight ambiguity for a complex 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 schema already covers all 5 parameters with 100% coverage, giving a baseline of 3. The description adds meaningful semantics: default allow/caution thresholds, threshold ordering constraints, intent being recorded-but-neutral, agent_id being recorded, AIT side effects, and inherited weights from cross_lens_verify.

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 states this 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 bonus, maps to allow/caution/deny, and returns a signed receipt. This clearly distinguishes it from sibling tools like cross_lens_verify, verdict_lookup, and generate_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?

It explicitly tells agents when to use this tool: before any transaction with an open-web destination, and frames the receipt as the load-bearing accountability artifact. It does not enumerate explicit when-not or alternative scenarios, so it stops short of a 5.

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 the confidence scoring mechanism, the 1.5× corroboration multiplier, the Scry attestation tier weighting, bounded output [0,1], the cross_lens.hits field semantics, and the signed P38 receipt. This goes far beyond a typical description.

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 longer than average, but every sentence contributes meaningful content and is front-loaded with the most critical context. The structure flows well from invocation to details to alternatives, though it could be trimmed slightly 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 there is no output schema and no annotations, the description fully compensates by explaining key return fields (cross_lens.hits, cross_lens.flags), confidence weighting, and examples of flag values. It also covers parameter constraints, making it complete for an AI agent to invoke 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?

Schema coverage is 100% and each parameter has its own description, but the tool description adds meaning by mapping each parameter to the relevant lens (ip → Scry, domain → Sigil+Tracker, entity → Sigil+Tracker) and explaining the combination flexibility. This exceeds schema-only 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 opens with a clear invocation context ('before routing traffic, bidding on inventory, or trusting a counterparty') and explicitly states it fuses all three lenses (Scry, Sigil, Tracker) into a confidence-scored profile. It distinguishes itself from siblings by naming cross_lens_verify and cross_lens_lookup and contrasting its richer subject handling.

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 guidance ('before routing traffic...') and explicit exclusion/alternatives ('Unlike cross_lens_verify... and cross_lens_lookup...'). Also states the input requirement of at least one of ip/domain/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?

Since no annotations are provided, the description carries full burden. It discloses that the tool returns both roots and the proof path, and suggests offline verification, clearly indicating read-only behavior. It does not mention prerequisites or side effects, but is sufficiently 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?

Three concise sentences: first states core purpose, second describes output, third suggests next step. No irrelevant 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 no output schema, the description adequately covers return values (roots and proof path). It lacks differentiation from similar sibling tools and assumes domain knowledge, but is complete for the intended 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?

With 0% schema description coverage, the description provides necessary context: it explains the roles of `first` and `second` as log sizes and their relationship. This adds value beyond the schema's type and minimum 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 proves the log at size `second` is an append-only extension of the log at size `first`, using a specific verb and resource. It distinguishes from sibling tools like receipt_log_inclusion_proof which serve a different 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 implies usage for verifying log consistency but does not explicitly state when to use this tool versus alternatives like receipt_log_inclusion_proof or receipt_log_sth. It provides a verification script instruction, which offers some 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 return values, default behavior (latest STH), and what is proven vs. not. This is transparent for a proof-of-inclusion 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 concise and front-loaded with the main purpose. Two paragraphs efficiently convey functionality, return values, limitations, and offline usage.

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 moderate complexity, the description covers return values, default behavior, proof semantics, and references ADR. Lacks error conditions but is fairly complete for the tool's purpose.

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 explains purpose of parameters: receipt_id unifies identifiers, tree_size defaults, leaf_index as alternative. Adds meaning beyond the schema, though lacks detailed parameter 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 proves a specific receipt is included in the tree, specifying identifiers and what it proves vs. does not prove. It distinguishes from siblings like receipt_log_consistency_proof and receipt_lookup.

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 implicitly distinguishes usage by focusing on inclusion proof, but does not explicitly state when to use this vs. alternatives like consistency proof. However, it provides a practical offline verification step.

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