AgentIndex — Agentic Web Index

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

With zero annotations provided, the description correctly carries the full burden of disclosure — and it excels. It transparently discloses the $0.50 cost, the blockchain/fiat rails ('USDC on base via x402'), the no-API-key need, the per-page (not per-record) billing, the exact page size, and pagination continuation. For a money-charging operation, this is exemplary 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?

Every sentence earns its place: purpose, price, protocol, page size, and continuation. The most critical fact — pricing model — is prominently flagged with 'PRICED:' and the per-page clarification prevents a costly misunderstanding. No wasted words despite condensing payment instructions, pagination, and page limits into ~50 words.

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

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

For a 4-param, 0-required export tool with no output schema, the description covers the key contract: page size (1000 records), continuation mechanism, and the service-level terms of the exchange. It could be faulted for not stating idempotency or retry semantics given the system charges money per page, but the essential behavior an agent needs to call it correctly is fully present.

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%, meeting the baseline of 3. The description adds genuine value on top by framing the payment and cursor params within the multi-call flow: it explains WHY you'd pass a payment value (to be served) and how to obtain one (from the first call) — context the schema alone doesn't offer. The 'no account, no API key' context enriches the type param's meaning.

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

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

The opening phrase 'Cursor-paginated bulk snapshot of endpoints or resources' uses a specific verb, resource, and scope, immediately distinguishing it from the granular single-item sibling tools (get_agent_profile, get_trust_score) and search_agents. It clearly answers what the tool does and positions it as the bulk/batch option.

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 two-phase invocation protocol is explicit: 'Call without `payment`' then 'call again with `payment` to be served' — a clear step-by-step usage instruction. However, it never names sibling tools as alternatives (e.g., when to prefer search_agents over this export) or states exclusions for when NOT to use it, so the guidance is flow-centric rather than comparative.

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. Mentions specific return content (protocol detection, liveness history, etc.), implying read-only behavior. 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?

Two concise sentences: first states purpose, second lists return contents. No unnecessary words, highly scannable.

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?

Single-parameter tool with no output schema; description adequately lists return categories. No missing context for 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?

Single parameter 'id' with schema coverage 100%. Description redundantly mentions ID type but adds no new semantics beyond schema's detailed example.

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

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

Description explicitly states the verb 'retrieve' and resource 'full profile', with specific identifiers (numeric ID or identifier URI). Clearly distinguishes from sibling tool 'search_agents' by focusing on individual profile retrieval.

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

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

Indicates usage via numeric ID or URI, providing clear context. Lacks explicit when-not or alternatives, but the sibling name 'search_agents' implies when to use this 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?

There are no annotations, so the description must disclose behavior. It states the tool is 'free' and returns specific data (top three themes with signal counts). However, it does not explicitly state whether the operation is read-only, whether any authentication is required, or any rate limits. For a simple preview tool these omissions are minor, but the description could be more explicit about the scope of data (only top 3) and the fact that it's a summary, not live data.

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

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

Two sentences, front-loaded with the core purpose, then a clear contrast with the full report. No wasted words or repetition.

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 what the tool returns, what it excludes, and how to access the full version. Given the tool's simplicity (one optional parameter, no output schema), this is nearly complete. A minor gap is not specifying whether the preview reflects live data or a sample, but this is likely not critical for a preview.

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 'days' is fully documented in the schema with its range and default. The description does not mention the parameter, but with 100% schema coverage the baseline of 3 applies, and no additional meaning is 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?

Clearly identifies the tool as a free preview of the AgentIndex Builder Demand Report and specifies the content (top three themes with signal counts). Differentiates from sibling get_demand_report by explicitly stating what the full report contains and that it's priced. This makes the tool's 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 directly contrasts the preview with the full get_demand_report tool, indicating that users seeking comprehensive data should use get_demand_report instead. It does not explicitly state a condition for using the preview, but the free/priced distinction implies usage for quick insights without paying. This provides clear routing to the 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?

No annotations are provided, so the description carries the full burden. It transparently discloses pricing, payment mechanism (x402), the two-step call sequence, data sources, and output contents (ranked themes, evidence, implications, supply index, inventory, and caveats). It does not mention rate limits or error handling, but for a report endpoint this is adequate.

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 dense but well-structured paragraph. Every sentence contributes value—purpose, pricing, usage, data sources, and output. It is slightly longer than necessary but remains focused 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?

With no output schema provided, the description compensates by explaining the nature of the returned data (ranked themes, evidence, supply index, inventory, caveats). It does not specify exact fields or pagination, but for a report tool this level of detail is sufficient for an agent to understand expectations.

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?

Both parameters are fully described in the schema (100% coverage), so the schema does the heavy lifting. The description adds meaningful context beyond the schema, particularly around the payment parameter's two-step invocation flow and the default window behavior, which enhances comprehension without redundancy.

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

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

The description states precisely what the tool does: reports builder demand and supply gaps, with specific details on data sources and output format. It clearly differentiates from siblings like get_demand_preview by describing a comprehensive report rather than a preview, 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?

The description provides explicit and actionable usage guidance for the payment flow: call without `payment` to get requirements, then call again with `payment` to be served. This is clear and functional, though it does not discuss when to choose this over sibling tools or note exclusions, leaving a minor gap.

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 behavioral burden. It transparently discloses the pricing model ($0.05), authentication requirements (no account/API key), the x402 payment flow, the maximum 500 results, and filterability. It stops short of describing error cases or the exact response structure, but given no output schema exists, the disclosure is solid.

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?

Every sentence in the description contributes unique information: core purpose, pricing, payment flow, result limit, filtering, and usage intent. It is front-loaded with the main purpose and remains compact with no fluff.

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

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

Given the tool has only 3 optional parameters and no output schema or annotations, the description covers all essential aspects needed for correct invocation: how to call, why to call repeatedly, what to expect (up to 500 changes, filters), and payment handling. Nothing relevant appears missing.

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

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

The schema covers 100% of parameter descriptions, so the baseline is 3. The description adds value beyond the schema by explaining the payment call flow, clarifying that 'payment' is the x402 header, and specifying that the feed supports time-window and protocol filtering, which enriches the semantic understanding of the parameters.

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 is a change feed of recently added, changed, or newly dark endpoints. It specifies the exact resource (endpoints) and differentiates itself from sibling tools like search_agents or get_agent_profile, which focus on other aspects.

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 call sequencing: first call without 'payment' to get requirements, then call with 'payment' to be served. It also mentions the intended repeated usage instead of re-crawling the index, giving clear context. However, it does not explicitly state when not to use this tool versus alternatives.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the pricing model, network, auth requirements, the two-call payment protocol, live probing at request time, the exact output contents and ordering, and the irreversibility of history loss. This is far more transparent than a minimal 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 five sentences, and each one carries distinct value: purpose, pricing/auth model, payment flow, return data shape, and temporal limitation. It is front-loaded with the purpose and contains no filler, repetition, or promotional language.

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 and no annotations, so the description must explain both invocation and return semantics. It does: payment requirements, live probe behavior, retained history ordering, uptime percentage, observed-day count, and transition details. Combined with a fully documented input schema, this is complete enough for an agent 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 coverage is 100%, so the baseline is 3. The description restates the payment workflow already present in the payment parameter schema and adds no new meaning for the `id` parameter. It adds only contextual framing around the payment flow, not new parameter semantics.

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

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

The description opens by naming the exact resource: liveness attestation and retained probe history for one endpoint. It then specifies what is returned, including the live probe, full probe series, uptime percentage, observed-day count, and transitions. This clearly distinguishes it from the sibling tools, which are about alerts, trust scores, profiles, search, and bulk export.

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

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

It provides clear invocation guidance: call without `payment` to receive payment requirements, then call again with `payment` to be served, and warns that history cannot be reconstructed after the fact. It does not explicitly name alternative sibling tools or exclusion conditions, but the one-endpoint scope and temporal warning give strong contextual guidance for selection.

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

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

With no annotations, the description carries the full disclosure burden and satisfies it: pricing, x402 payment protocol, no account/API key/invoice required, two-step call flow, ordering, pagination, and the notable design decision that never-probed services are omitted rather than ranked last. The 'absence of evidence' rationale adds valuable context.

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

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

The first sentence states the core purpose, and each subsequent sentence covers a distinct necessary fact: pricing/protocol, scoring/ordering, paging, and the absent-services edge case. There is no filler or repetition.

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

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

Despite lacking an output schema, the description tells an agent enough to call correctly: purpose, payment handshake, pagination, output ordering/scoring, and an important edge-case semantic. The explicit 'scored out of 100' and category tags provide a sufficient picture of what will be returned.

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. The description reinforces limit/offset and the two-step payment flow, but this closely mirrors the schema's own parameter descriptions and does not add meaningful new parameter-level semantics.

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

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

The description opens with an unambiguous definition: the complete ranked table of every scored service. Phrases like 'full' and 'every scored service' plus 'ordered best first' clearly separate this from siblings such as get_top_ten, even without naming them.

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 concrete procedural guidance: call first without `payment` to receive exact payment requirements, then call again with `payment`, and page with `limit` and `offset`. It does not explicitly contrast this tool with alternatives, so it just misses the top score.

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 pricing, the two-step payment flow, refusal of unknown domains free of charge, the report contents, and the fact that every figure cites its source table. This is thorough and leaves no major behavioral surprises.

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 every sentence carries essential information—pricing, usage steps, report contents, and a caution. It is front-loaded with the core purpose and pricing, and while long, it remains organized and free of 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 the tool's complexity (payment flow, coverage check, detailed report contents) and the absence of an output schema, the description is remarkably complete. An agent can correctly invoke the tool and understand what to expect without additional documentation.

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 both parameters are already documented. The description adds meaningful context: it explains the two-step payment flow for the payment parameter and gives an example for domain. This goes beyond the schema and enhances understanding.

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 produces a one-page report on a single indexed service with a verdict, and enumerates the specific data points (uptime, payment evidence, TLS, jobs, alternatives). This verb+resource phrasing distinguishes it from sibling tools like get_demand_report or get_trust_score without 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?

It gives explicit step-by-step usage: call without payment to get requirements, then call again with payment. It also advises checking coverage first at /covered/{domain}. However, it does not explicitly contrast with sibling tools or state when not to use it, so it falls short of full guidance.

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

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

No annotations are provided, so the description carries the full burden, and it delivers extensively. It discloses the $0.10 USDC x402 payment requirement, the no-account/no-API-key model, the two-call payment flow, the exact ranking methodology, nightly freezing of results, and the category-assignment rule.

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

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

The description is detailed yet front-loaded: the core purpose appears first, followed by payment mechanics, ranking criteria, and list-construction rules. Every sentence contributes distinct information, with no filler 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?

Given there is no output schema and no annotations, the description supplies enough context for correct invocation: how to pay, the exact call sequence, what the ranking means, and why the results are stable per day. An agent can determine whether to call this tool and how to call it successfully.

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 meaning beyond the schema by explaining the `payment` parameter's behavioral contract: omit it to receive requirements, then include it to be served. It also clarifies the semantic of the `category` parameter as defining a capability category for the top-ten list.

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-plus-resource statement: 'The ten best services in one capability category today.' It further differentiates itself from siblings like get_rankings by emphasizing the category-scoped top-ten list, the ranking score, and the guarantee that the category lists are 'genuinely different from each other.'

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

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

The description gives clear, actionable usage context: pick a category and either omit `payment` to receive payment requirements or provide `payment` to be served. It does not explicitly name alternatives such as get_rankings or get_agent_profile, so it stops short of full when-to-use versus alternative 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 full burden. It discloses the pricing, the payment mechanism (x402, no account/API key), the exact two-call flow, and the independent measurement methodology. This is unusually transparent about how the tool behaves.

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, front-loaded with the core purpose, then pricing, then usage flow, then scoring basis. No wasted words, though a bulleted structure might improve scannability. It is appropriately sized for the amount of 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?

While the pricing and payment flow are well covered, there is no output schema, and the description does not specify the structure of the returned trust score (e.g., number, object, confidence intervals). For a tool with this much behavioral complexity, the return format is a notable omission.

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 parameters are already described. The description adds crucial semantics beyond the schema by explaining the payment parameter's role in the two-step flow and the nature of the id (numeric or identifier URI). This raises value above the 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 states a specific verb (get), resource (trust score), and scope (one endpoint), immediately distinguishing it from bulk-like tools. It also explains what the score is based on, making the tool's function 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?

The description gives clear operational context: it's a paid call requiring a two-step payment flow. It doesn't explicitly mention alternatives, but the phrase 'for one endpoint' and the distinct purpose imply when to use it over siblings like bulk_export. Lacks explicit when-not guidance, but context is strong.

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 handles it well: it discloses pricing ($0.25 USDC on base via x402), no-account/no-API-key/no-invoice access, the two-call payment flow, hourly rebuilds, and identical service to all buyers. This provides valuable behavioral context well beyond the schema.

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 four dense sentences with purpose front-loaded, followed by payment flow and fairness guarantees. Every sentence adds distinct information, with no filler or repetition.

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 the expected result, window behavior, and the important payment handshake in enough detail for an agent to call the tool correctly and interpret the response. Even without an output schema, the description's summary of 'services started/stopped with index-wide totals' is sufficient for a two-parameter 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 already covers both parameters fully: `days` is a 1-30 window defaulting to 7, and `payment` is an optional x402 header. The description mostly rephrases this and adds pricing/payment context, so the 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 clearly identifies the tool's output as 'what came alive and what went dark' / 'services that started answering and services that stopped' across the whole index, with a configurable 1-30 day window. This is specific and sufficient to distinguish it from index-focused siblings like get_liveness_history or get_service_report.

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 gives explicit call guidance: omit `payment` to receive exact payment requirements, then call again with `payment` to be served. It also explains the configurable window, though it does not name sibling alternatives or state when not to use 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?

No annotations; description states results are ranked but doesn't mention idempotency, auth needs, or side effects. Provides some behavioral insight into output structure.

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

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

Two concise sentences, front-loaded with key action and result description, no fluff.

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

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

Given no output schema, description adequately explains return fields. Covers all essential aspects for a search tool with 3 parameters.

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 descriptions already do the work. The tool description adds context about searched resources but no new parameter semantics beyond the schema.

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

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

Clearly states it searches the AgentIndex for specific resource types (AI agents, MCP servers, etc.) by capability keyword, distinguishing it from sibling 'get_agent_profile'.

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?

Implies usage for discovery by keyword, but lacks explicit exclusion or when-not-to-use compared to 'get_agent_profile'.

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