AgentIndex — measured reliability for agent services

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

No annotations exist, so the description carries the full burden and does so well: it discloses the cost ($0.25 USDC on base via x402), that no account/API key/invoice is needed, the page size (1000 records), that billing is per page not per record, and that the cursor must be passed to continue.

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?

Five short sentences, each earning its place, with the core purpose and the payment protocol front-loaded before pagination details. 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 4-param, no-annotation, no-output-schema tool, this covers pricing, auth posture, page size, and pagination adequately. It doesn't explain the `type`/`protocol` filter semantics, but those are documented in the 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains the payment field's two-mode contract (omit vs supply) and clarifies the per-page billing semantics of `cursor` continuation, which the schema does not state.

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+resource: 'Cursor-paginated bulk snapshot of endpoints or resources.' An agent can tell this is a bulk-dump tool rather than a scoring or lookup tool, though it doesn't explicitly name which sibling it supersedes (bulk_score, get_rankings).

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?

Gives an explicit two-step invocation recipe: call without `payment` to get requirements, call again with `payment` to be served. Clear operational context, but no guidance on when this tool is preferable to sibling alternatives like bulk_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, the description carries the full burden and does well: it discloses pricing ($0.02 USDC on Base via x402), that no account or API key is needed, the two-call payment handshake, and the 1000-domain cap. It does not clarify whether $0.02 is flat per call or per domain, nor what happens on payment failure or over-limit batches, which matters for a paid 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?

Dense and largely waste-free, with the operation and return shape packed into a few sentences. The pricing block is inserted second, ahead of what the tool actually does, which slightly buries the core purpose, but nothing is redundant.

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

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

With no output schema, the description usefully enumerates the return fields (score, grade, 90-day uptime, probe count, distinct on-chain payers) and explains the payment prerequisite. It is close to complete, missing only sibling differentiation and edge-case behavior for large or failed batches.

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 both `days` and `payment` are already documented in the schema, including the omit-vs-supply payment behavior. The description reinforces the payment mechanic but adds no syntax or format detail beyond the schema. Baseline 3 applies when the schema does 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 moves past the name-restating opener ('Bulk scoring') to state a concrete operation: post up to 1000 domains and get one scored row back per input row, with named output fields. It is clear what the tool does, but it never explicitly distinguishes itself from the sibling bulk_export, leaving the agent to infer the boundary.

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 operational guidance for the two-step flow: 'Call without `payment` to receive the exact payment requirements, then call again with `payment` to be served.' That is a clear usage sequence. It stops short of naming when to prefer this over bulk_export or other scoring 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 well: it discloses the exact price ($0.01 USDC on Base via x402), that no account or API key is required, and the required payment handshake. It stops short of describing what is returned (no output schema exists) or pagination/limit 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 purpose is front-loaded and the payment/ranking facts follow in a logical order. The closing line ('A cheap service that is down is worth nothing') is mild editorializing that justifies the ranking method rather than pure 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 paid, three-parameter lookup with no annotations and no output schema, the description covers pricing, auth model, and the payment handshake adequately. It could be more complete by stating the shape of what is returned (ranked list vs single pick), which the `limit` param hints at but never confirms.

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 the schema already documents `category`, `limit`, and `payment` fully. The description reinforces the `payment` semantics and the category concept but adds no syntax or format detail beyond the schema. Baseline 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 names a specific resource (services in a capability category) and states the selection rule: observed price ranked against measured uptime. The name plus the ranking sentence make the intent clear. However, it never explicitly distinguishes itself from siblings like price_check, get_rankings, or find_tool, so an agent must infer the difference.

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-step invocation flow (call without `payment` for requirements, call again with `payment` to be served) is genuinely useful usage guidance. But there is no guidance on when to choose this over the many sibling ranking/lookup tools, which is the harder routing decision here.

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 well: it discloses the exact price ($0.002 USDC on base via x402), that no account/API key/invoice is needed, and the x402 payment handshake. It omits return format, result limits, and any rate/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?

Three sentences with no egregious waste, but the ordering is weak: it opens with the vague label 'Tool finder' and buries the actual purpose (searching published tool lists) at the very end, after the pricing boilerplate. Front-loading the core function would help.

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 exists, so the description should describe what a result looks like, and it does not — an agent learns nothing about the response shape or result count. The payment flow and pricing are covered adequately, but the return-value gap leaves it only minimally 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 both parameters are already documented. The description reinforces the payment mechanic (omit vs supply `payment`) but adds no new semantics beyond what the schema states, so the baseline 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 names a specific verb+resource ('Find services by the tools they actually publish') and even quantifies scope ('6,530 services'). The 'searching the real tool lists... rather than their marketing text' clause distinguishes it somewhat from the marketing-oriented siblings, though it never names an alternative like search_agents.

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 an explicit two-step invocation flow: call without `payment` to receive requirements, then call again with `payment` to be served. That is clear context for how to use it, but there is no guidance on when to prefer this over sibling search tools such as search_agents or cheapest_that_works.

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 a good job: it discloses free allowance (50/day per caller), price ($0.02 USDC on base via x402), and the exact retry protocol when over quota. It stops short of stating failure modes or auth prerequisites beyond the payment 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?

Three tightly packed sentences, front-loaded with what the tool returns and then the billing/retry mechanics. No filler; every clause carries information an agent needs to call it correctly.

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 and no annotations, so the description must cover everything, and it covers the return contents and payment flow well. It is slightly thin on error behavior and pagination or size limits for a profile that returns multiple sections.

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 value by tying the `payment` parameter to the two-step quota-exceeded workflow, which is not expressible in the schema alone. The `id` semantics are only restated, not enriched.

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 and resource ('Retrieve a full profile for a specific agent or endpoint') and enumerates exactly what the profile contains (protocol detection, liveness, payment evidence, MCP tools, A2A skills). That enumeration distinguishes it from granular siblings like get_liveness_history, payment_evidence, and get_trust_score without needing to name 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?

Usage is implied by the aggregate nature of the tool, and it does spell out the conditional payment workflow ('call without payment to receive the exact payment requirements, then call again with payment'). However, it never says when to prefer this composite profile over the narrower sibling tools, nor any exclusions.

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 burden and does so well: it discloses the price ($0.25 USDC on base via x402), that no account/API key/invoice is needed, the two-step payment handshake, and the deliberate exclusion of unprobed services. It does not cover failure modes (e.g., what happens with an invalid or expired payment) 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?

Front-loads the purpose, then price, then the call mechanics, then the paging and the absence caveat. Every sentence carries distinct information (cost, auth model, protocol flow, output ordering, exclusion rule) and nothing is 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?

There is no output schema, so the description must describe the return: a ranked, 0-100 scored table ordered best-first with category tags, paginated. Combined with the payment flow and the unprobed-service caveat, an agent has everything needed to call and interpret 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 100% and the schema already documents limit/offset ranges and defaults plus the payment omit/supply behavior. The description adds only the phrase "Page with limit and offset," which restates what the schema provides, so the baseline 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?

States a specific resource and scope: "the full ranked table of every scored service," ordered best-first, scored out of 100. This implicitly separates it from the narrower sibling get_top_ten, but it never names that sibling or any other, so the differentiation is inferred rather than stated.

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?

Gives explicit operational sequencing: "Call without `payment` to receive the exact payment requirements, then call again with `payment` to be served." It also states a when-not condition (services never probed are absent, not ranked last) and specifies paging via limit/offset.

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?

With no annotations, the description carries the full burden and does so well: it discloses pricing ($0.02 USDC on base via x402), no-account/no-key access, the two-call payment handshake, the scoring inputs, nightly freezing for consistency, and the at-most-three-categories placement rule. It omits any description of the response shape, which keeps it from a 5.

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?

Front-loaded with the core purpose, and each subsequent sentence carries distinct value: price, payment flow, scoring inputs, and the fairness guarantee. It is longer than ideal, with the methodology sentence notably dense, but nothing is outright redundant.

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

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

For a 2-param read tool with no annotations and no output schema, the description covers pricing, the invocation handshake, and what the ranking is built from. The only meaningful gap is that it never hints at the shape of the returned list, though an agent has enough to call 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 description coverage is 100% and both parameters are documented there, including the payment flag mechanics and the full category enum. The description reinforces the payment flow and the category-assignment logic but adds no syntax or value details beyond what the schema already provides, so the 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?

States a specific resource and scope: 'The ten best services in one capability category today.' It implies differentiation from siblings like get_rankings by explaining that lists are per-category and genuinely different, but it does not name a sibling explicitly, so it lands just 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?

It gives clear operational guidance for the payment flow ('Call without payment to receive requirements, then call again with payment'), which is real usage instruction. However, it never says when to choose this over get_rankings, cheapest_that_works, or search_agents, so the routing guidance is implied at best.

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 load and does well: it discloses price ($0.02 USDC on base via x402), that no account/API key/invoice is required, the two-call payment handshake, and the provenance of the score (liveness history, on-chain payment evidence, cross-registry corroboration, protocol richness, no self-reported input). It omits failure/refund behavior and idempotency of the paid call.

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?

Four tight sentences, front-loaded with what the tool returns and immediately followed by the pricing/payment mechanics. Little waste; the scoring-input list is dense but informative rather than padded.

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 paid, single-endpoint scoring tool with no annotations and no output schema, the description should ideally characterize the returned score (range, components, confidence). It explains the payment path and methodology but leaves the response shape undefined, which is a real gap when no output schema exists.

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 the schema already documents both `id` and `payment`. The description reinforces the meaning of omitting vs supplying `payment`, but adds no syntax or format detail beyond the schema, so baseline 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?

States a specific verb+resource ('Measured-signal trust score for one endpoint') and implicitly scopes to a single endpoint, which distinguishes it from bulk_score and get_rankings. It stops short of naming a sibling explicitly, so an agent must infer single-vs-bulk routing.

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?

Gives concrete invocation guidance for the two-step x402 flow: call without `payment` to get requirements, call again with `payment` to be served. It does not, however, say when to prefer this over sibling tools like bulk_score, get_service_report, or cheapest_that_works.

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 well: it discloses the price ($0.05 in USDC on base via x402), that no account or API key is needed, the two-step payment handshake, the hourly rebuild cadence, the 30-day window cap, and that every buyer gets an identical, flat-priced response. It does not cover failure modes (e.g., what happens if payment is rejected) or rate limits, keeping it just short of a 5.

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?

Front-loaded: the first sentence answers 'what does this return' before any pricing mechanics. The pricing/determinism paragraph is somewhat verbose and the 'first or hundredth' clause is closer to marketing than operational guidance, but nothing is confusingly ordered or badly buried.

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 paid, output-schema-less data endpoint with no annotations, the description covers cost, auth-free access, the payment workflow, freshness, and the qualitative shape of the result (started/stopped services plus index-wide totals). It stops short of describing the actual response structure, but an agent has enough 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 description coverage is 100%, so the schema already documents both `days` and `payment`, making 3 the floor. The description adds real meaning beyond the schema by explaining the x402 two-call protocol and framing `days` as a user-chosen window, which clarifies how the optional `payment` param is actually used.

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 sentence states exactly what the tool returns — services that started and stopped answering across the whole index — and the follow-up ('Services that started answering and services that stopped, with index-wide totals') removes the metaphor's ambiguity. It is clearly distinguished from narrow siblings like gone_dark and new_services because it covers both directions of change plus index-wide totals.

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

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

The description gives explicit procedural guidance for payment ('Call without `payment` to receive the exact payment requirements, then call again with `payment` to be served') and a window constraint (up to 30 days). However, it never says when to prefer this tool over alternatives such as gone_dark, new_services, or has_it_changed, which is the more important selection 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 full burden and does disclose key traits: the pricing model ($0.005 USDC on Base via x402), the no-auth model, the two-call payment handshake, and the inclusion/exclusion scope. It omits return format and any rate-limit behavior, which prevents a 5.

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 pricing/payment sentence is front-loaded ahead of the actual semantics of what the tool returns, so the purpose is buried near the end. Nothing is egregiously wasteful, but the ordering hurts fast 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?

For a low-complexity read/list tool with two optional parameters and no output schema, the description covers purpose, scope exclusions, auth model, and payment mechanics adequately. It could still say what fields are returned or the default lookback window, but nothing essential for calling it correctly is missing.

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

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

Schema description coverage is 100%, so both `days` and `payment` are already documented in the schema, making 3 the baseline. The description restates the `payment` handshake but adds no syntax or format detail beyond what the schema provides, and never mentions the `days` parameter's 1-30 range.

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 behavior: it lists services that used to answer and have stopped, explicitly excluding never-alive services. This distinguishes it from siblings like new_services and uptime_history. The purpose is clear but the terse 'Gone dark.' opener defers the real meaning to the final sentence.

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 explains the payment invocation flow (call without `payment` to get requirements, call again with `payment`), which is useful procedural guidance. However, it gives no guidance on when to choose this tool over siblings such as uptime_history or get_liveness_history.

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 well: it discloses statelessness ("you pass the time you last looked, we compare it against our probe record"), exact price and rail, and that no account or API key is needed. It still does not say what constitutes a change or how staleness/probe freshness affects the answer.

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 core purpose sentence is buried third behind a pricing block, so it is not front-loaded. "No account, no API key, no invoice" and "No account and no subscription to administer" are redundant restatements of the same point.

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 2-parameter, no-output-schema tool, the payment mechanics are covered, but the description omits what the response contains (changed true/false, timestamp granularity) and any limits on how far back the 'moment you name' can be. Adequate but with clear gaps given no output schema exists.

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 `target` and `payment` are already documented in the schema. The description restates the omit/ supply payment behavior rather than adding new syntax or format detail, so the baseline 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?

States a specific resource and question: "Has this endpoint changed since a moment you name." The verb/resource pairing is clear and distinct from siblings like liveness_history or new_services. The interleaved pricing preamble delays the core purpose, and it never defines what 'changed' means (content, status, hash).

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 procedural guidance for the two-step x402 flow: call without `payment` to get requirements, call again with `payment` to be served. However, it offers no guidance on when to choose this over siblings such as get_weekly_changes, new_services, or uptime_history, so the routing decision is left to inference.

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 well: it discloses the price ($0.01 USDC on Base via x402), that no account/API key/invoice is needed, the expected volume (~170/day), and the important caveat that 'new' means new-to-us rather than newly-created. It does not describe the shape or fields of the returned listing, which is the remaining 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?

Front-loaded with the pricing/payment model, followed by scope and the 'new to us' caveat. Every sentence carries information, though the ordering jumps between price, invocation flow, and definition, which is slightly less smooth than it could be.

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 and no annotations mean the description must explain the operation, and it covers pricing, invocation, volume, and scope definition adequately for a paid discovery tool. It stops short of describing what a served response contains, which would be the one missing piece for an agent that has to decide whether the $0.01 call is worth 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 coverage is 100%, so both `days` and `payment` are already documented in the schema. The description reinforces the payment semantics (omit vs. supply) but adds no syntax or meaning for `days` beyond what the schema states. Baseline 3 is appropriate when the schema does 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 states the resource ('new services') and elaborates that these are services that 'appeared recently, roughly 170 a day,' so an agent knows this is a discovery/listing tool for recently-seen services. It distinguishes itself in concept from date-window tools like get_weekly_changes, but it never names an alternative sibling, so the differentiation is implicit rather than explicit.

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-step payment flow is spelled out clearly: call without `payment` for the requirements, call again with `payment` to be served. However, there is no guidance on when to prefer this over siblings like search_agents, get_rankings, or cheapest_that_works, and no exclusions. Usage is implied rather than directed.

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 well: it discloses the paid model ($0.002 USDC on base, no account/API key/invoice), the exact two-call payment handshake, and a non-obvious data caveat ('Counts are per receiving wallet, so one operator on several hostnames shows the same totals on each'). It omits error/failure behavior and 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?

Dense but well front-loaded: the pricing/access model comes first, the call protocol second, the returned data and its caveat last. Every sentence carries 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?

No output schema and no annotations, yet the description names exactly what is returned (payment count, distinct paying wallets, first/last seen) and flags the per-receiving-wallet aggregation. That is sufficient for an agent to invoke and interpret 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 description coverage is 100% and the schema already explains both `target` and the optional `payment` header, including 'Omit it to receive the payment requirements... supply it to be served.' The description largely restates that handshake, so baseline 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?

States a concrete verb+resource: 'On-chain payment evidence for one service: how many payments, how many distinct paying wallets, first and last seen.' The phrase 'Read off the chain, not off a claim' implicitly distinguishes it from claim-based siblings like get_trust_score, but no sibling is named explicitly.

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-step invocation protocol is spelled out ('Call without `payment`... then call again with `payment`'), but there is no guidance on when to choose this tool over adjacent siblings such as get_trust_score, get_service_report, or price_check. Usage is implied rather than framed against alternatives.

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

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

With no annotations, the description carries the full burden and does it well: it discloses price ($0.001 USDC on base via x402), the no-account/no-API-key auth model, the free tier of 500 calls/day, and — importantly — that results come from the provider's own probe record rather than the service's claims. It omits error/not-found behavior and return shape, keeping it short of a 5.

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?

Sentences are short and front-loaded with the core purpose, then pricing, then flow, then value proposition. Price is stated twice ($0.001 up front and again in the payment line) and the staccato fragments are slightly choppy, but almost every sentence 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 tool with no annotations and no output schema, the description covers the essentials an agent needs: what is checked, how to pay, cost, free tier, and data provenance. It stops short of describing behavior on an unknown/invalid target or any concurrency/rate limits beyond the free tier.

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 both `target` and `payment` are already documented, including the omit-vs-supply semantics of `payment`. The description repeats the payment flow and price rather than adding new parameter meaning (e.g., what target formats are accepted), so this lands at the baseline 3.

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 (pre-flight check of an endpoint) and enumerates exactly what is answered: liveness, how long known, protocols, price, and whether real money has reached it. This implicitly distinguishes it from single-signal siblings like get_liveness_history or price_check, though it never names 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 explains the two-step invocation (call without `payment` to get requirements, call again with `payment` to be served), which is genuine usage guidance. However, it gives no when-to-use/when-not framing relative to the many overlapping siblings (payment_evidence, price_check, get_liveness_history), so the agent must infer routing.

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 so well: it discloses the cost ($0.001 USDC on base via x402), the auth model (no account, no API key, no invoice), and the payment protocol flow. It stops short of stating rate limits, failure modes, or what happens if payment is rejected, which keeps it from a 5.

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 summary is front-loaded but the middle is a sprawling run-on sentence that packs protocol details, pricing, and two-call mechanics together. The content mostly earns its place, but the structure could be broken into clearer clauses.

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 paid x402 endpoint with no output schema and no annotations, the description covers the essential context an agent needs: cost, auth model, the two-step payment handshake, and the nature of the returned data (live terms and whether they match published ones). Minor gaps remain around payment failure behavior.

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 the schema already documents both `target` and `payment`, including the omit-vs-supply behavior and the price. The description restates that same mechanic rather than adding new meaning, so the 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 names the resource and states a specific scope: 'What this endpoint charges as we last observed it, not as it advertises, with the live payment terms and whether they match the published ones.' This distinguishes the observed-vs-advertised angle from siblings like get_service_report or payment_evidence, though it never names an alternative explicitly. The opening 'Price check.' is terse but the second sentence carries the real 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?

It gives clear invocation guidance for the two-call handshake ('Call without `payment` to receive the exact payment requirements, then call again with `payment` to be served'), which is genuinely useful. However, it offers no guidance on when to choose this over sibling tools such as payment_evidence, preflight_check, or cheapest_that_works, leaving the selection decision to inference.

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 so well: it discloses the free quota (50 calls/day per caller), the exact price and rail past it ($0.005 USDC on base via x402), and the recovery handshake for the over-allowance case. Cost, rate limit, and auth/payment requirements are all surfaced before the agent calls.

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 sentences, front-loaded with purpose then return shape then pricing/payment flow; no filler. The final sentence is dense with a nested call-again instruction, which costs a little readability but earns its place given the x402 complexity.

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 search tool with no output schema and no annotations, the description covers return contents (type, description, URL, tags), cost model, and payment mechanics. It omits pagination behavior and what the `type` filter values map to in practice, minor gaps given the schema documents 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 the baseline is 3, but the description goes beyond it by explaining the operational semantics of the `payment` parameter – that omitting it yields payment requirements and re-calling with it completes the transaction. The `capability` and `type`/`limit` params are left to the schema, which documents them 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?

States a specific verb and resource ('Search the AgentIndex for AI agents, MCP servers, A2A agents, and x402-gated APIs by capability keyword'), which is concrete and unambiguous. However, it never differentiates itself from siblings like find_tool or cheapest_that_works, which an agent scanning the toolset must distinguish on its own.

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?

Gives explicit conditional guidance for the paid path: 'Over the allowance, call without payment to receive the exact payment requirements, then call again with payment to be served' – a genuinely actionable two-step flow. It stops short of naming when to prefer this over find_tool or the other search-adjacent siblings, so no true alternatives/exclusions are given.

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 behavioral burden and does well: it discloses pricing ($0.002 USDC on base), the no-account/no-API-key model, the two-step handshake, and the 90-day retention depth. It stops short of rate limits, error behavior, or what a probe record contains, but the payment and retention traits are meaningful context beyond 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?

It is front-loaded with the resource name and the payment terms, which is good. But the final sentence ('This is the part nobody who started later can reconstruct.') is pure sales copy that consumes space without adding actionable information, and the pricing line would fit better after the data 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?

With no output schema and no annotations, the description must stand alone, and it largely does: data scope, retention window, granularity, and access mechanics are all covered. The main gap is return shape — 'probe by probe' hints at per-record output but the format is never specified.

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 both parameters are already documented with their purpose and price. The description restates the omit-supply payment semantics without adding format details (e.g., header encoding, what the requirements response looks like). Baseline 3 is appropriate when the schema does 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 states the resource and its scope precisely: 'The 90-day probe record for one service, probe by probe.' An agent knows it retrieves per-probe uptime data for a single target. However, it never distinguishes itself from the near-twin sibling get_liveness_history, leaving a real risk of wrong-tool selection.

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 invocation guidance for the x402 flow ('call without payment to receive requirements, then call again with payment'), which is genuinely useful. But it offers no when-to-use versus alternatives guidance — nothing says when to choose this over get_liveness_history or get_endpoint_alerts, which is the more important routing question.

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