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

With no annotations, the description carries the full behavioral burden. It does disclose the data composition and the 30-day observation window, which is useful, but says nothing about freshness/lag, caching, rate limits, or the fact that this is a safe read-only call. The one clear behavioral fact (a fixed 30-day window) keeps it at a 3.

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 tight sentences with zero filler; the content inventory is front-loaded and the usage hint follows. Every clause 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?

With no output schema and no annotations, the description must convey what comes back, and it does: metric families plus the 30-day time scope. It is not fully complete, since units, granularity, and data latency for the settlement volume are unstated, but for a no-arg stats endpoint this is close to sufficient.

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

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

The tool takes zero parameters and the schema is empty, so per the rubric the baseline is 4. Nothing in the description contradicts or muddies that, and no parameter semantics need explaining.

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 output artifact ('Snapshot of the whole x402 ecosystem') and enumerates the exact contents: endpoint counts, reachability, and 30-day USDC settlement volume. This ecosystem-wide aggregate scope implicitly separates it from per-endpoint siblings like x402_trust_score and x402_endpoint_history, though 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?

It supplies one genuine use case ('Use it to gauge market health'), which gives the agent a scenario for selection. It does not state when not to use it, nor point to any alternative such as x402_trust_leaderboard or x402_verified_providers, so usage remains implied rather than directive.

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. It does add one genuinely useful semantic rule — 'Excluded probes never count as downtime' — which an agent could not infer from the schema, and it discloses that a summary is bundled in. It omits auth requirements, rate limits, and return format, so it is helpful but incomplete.

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 dense sentences with no filler, front-loading what the tool returns before the caveat about excluded probes. Every clause maps to a concrete output type.

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, but the description enumerates the return contents (probes, events, price/payTo changes, failures, latencies, summary), which is the key gap filler. For a two-parameter read tool with a fully documented schema, only return format/shape and any pagination or windowing caveats remain unspecified.

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% (both `resource` and `days` are documented, including the default of 30), so the schema already carries parameter meaning. The description's '1-90 days' restates the schema's min/max rather than adding new semantics, making the baseline 3 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 verb+resource pair ('Raw probe and event history for one endpoint') and scopes it to 1-90 days, enumerating the contents (price/payTo changes, failures, latencies, summary). It does not name or contrast with siblings such as x402_watch_events or x402_trust_score, so the 'one endpoint' vs. watch/bulk distinction is left implicit.

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 scope (single endpoint, historical window) implies the use case of investigating one endpoint's past behavior, but the description never states when to prefer this over x402_watch_events, x402_trust_score, or x402_trust_preview. No exclusions or prerequisites 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?

No annotations, so the description carries the burden. It helpfully discloses the empty-result semantics ('nothing beats it'), which is a real behavioral trait an agent must handle. It doesn't cover ranking order, data freshness, or result shape, but the key edge case is covered.

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

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

Two short sentences, fully front-loaded, zero filler. The second sentence delivers the critical edge-case behavior without verbosity.

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?

Adequate for a 3-param read tool with full schema coverage and no output schema, but it omits what the response looks like when non-empty and how alternatives are ranked. The empty-result note is the main completeness win.

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

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

Schema coverage is 100% and all three params are fully documented in the schema, including defaults and ranges. The description adds the semantic framing (out-score, trust-score advantage) that ties the params to meaning, exceeding 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?

States a precise verb and resource: finding semantically similar endpoints that out-score a given one. The title reinforces it and it's clearly distinct from siblings like x402_search or x402_trust_score.

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 (when you want better alternatives) but never names alternatives like x402_semantic_search or x402_trust_score, nor states prerequisites such as needing the endpoint's score first. Usage is inferable but not guided.

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 usefully discloses that matching is literal rather than semantic, but says nothing about result ordering (relevance vs. catalog order), pagination behavior, or that this is a read-only, non-mutating lookup.

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, zero filler, with the scope of the search front-loaded before the sibling routing hint. Every clause earns its place.

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

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

For a simple three-parameter, read-only search with a fully documented schema, the description covers purpose and alternative routing adequately. With no output schema and no annotations, it could say more about ordering and result shape, but nothing essential to correct invocation 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 the schema already documents query, limit and offset in detail. The description's field list and 'literal, not by meaning' note largely restate what the query parameter description already says, adding little beyond 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?

States a specific mechanism (substring search) and the exact fields searched (host, URL, service name), which makes it immediately distinguishable from x402_semantic_search. An agent can pick between the two without opening either schema.

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

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

Explicitly routes the agent to x402_semantic_search when meaning-based matching is wanted, which implicitly defines the when-not case. It stops short of stating any preconditions or noting that this is the cheaper/faster option for known domains or paths.

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 supplied, so the description carries the full behavioral burden. It does disclose a meaningful trait beyond the schema — the tool is non-evaluative ('no verdicts') and semantic rather than substring-based — but says nothing about authentication needs, rate limits, pagination, or result shape. Useful context, yet insufficient for an annotation-free 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?

Two tight sentences with zero filler; the core purpose is front-loaded and the scope qualifier follows immediately. Every phrase earns its place.

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

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

For a simple two-parameter search with no output schema, the description covers the intent and the semantic-matching behavior but omits anything about the returned result (e.g., what a match contains or whether relevance scores are included). Adequate but leaves the agent guessing about output shape.

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 the query and limit parameters are already fully documented, including the 'matching is by meaning, not substrings' note. The description repeats that same semantic-matching idea without adding formatting or syntax meaning beyond the schema, making the baseline 3 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 verb and resource ('Meaning-based search across the catalog') and clarifies the input style ('describe the capability you need in plain words'), which is more precise than a generic 'search the catalog'. However, it never distinguishes itself from the closest sibling, x402_search, so the agent cannot tell the two apart without inspecting both schemas.

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?

'Discovery only, no verdicts' gives a clear scope boundary that implicitly routes evaluation-type queries to the trust siblings (x402_trust_score, x402_trust_preview). It does not explicitly name an alternative or state when to prefer x402_search over this tool, so it stops just short of full routing 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 disclosure burden and delivers two genuinely useful behaviors: unknown URLs return found:false, and the batch is billed regardless of misses. That billing-on-miss caveat is real cost information an agent needs. It stops short of confirming the operation is read-only or describing failure/rate-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?

Two tight sentences: the core action and scope lead, then edge-case/cost behavior follows. No filler, and the most surprising fact (billing on misses) is not 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 batch tool with no output schema and no annotations, the description omits the shape of the response (how per-endpoint scores are returned, ordering, partial failures). It covers behavior and cost but leaves the agent guessing what it gets back.

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 schema already documents both `resources` and `tier`. The description restates the auto-tier behavior ('cheapest fitting tier is picked automatically') but adds no syntax or format detail beyond 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 verb and resource ('Score ... endpoints') with an explicit batch scope ('up to 500 endpoints in one call'), which inherently distinguishes it from the single-endpoint x402_trust_score sibling. An agent can tell immediately this is the batch-scoring path.

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 batch framing implies when to use it (many endpoints), but there is no explicit guidance on when to prefer it over x402_trust_score or x402_trust_preview, nor any stated prerequisites. Usage is inferable rather than declared.

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 supplied, so the description carries the behavioral burden. It discloses the 100-host cap and pagination nature, but does not state that this is a read-only operation, whether any auth is required, or what 'whole measured surface' scoring actually means. Adequate for a low-risk read listing, but thin given zero annotation coverage.

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 what the tool returns, followed by the pagination mechanic and the sibling handoff. No filler, no repetition of the title.

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 should hint at the return shape; it conveys 'ranking ... scored' but not which fields (host, score, rank) come back. Combined with the missing read-only/auth disclosure, it is nearly complete for such a simple paginated listing but leaves minor gaps.

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

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

Schema description coverage is 100% – both limit and offset are already documented, including the 1-25 bounds and the 100-host board size. The description's 'Page with offset' adds no syntax or format detail beyond the schema, 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 verb+resource: a ranked top-100 list of trustworthy x402 hosts. It distinguishes itself from siblings like x402_trust_score (single host score) and x402_trust_preview by describing a cross-host leaderboard, so an agent can route correctly without opening schemas.

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 clear usage context ('Page with offset') and explicitly routes follow-up work to x402_search for a host's endpoints, which is a real alternative for adjacent intent. It stops short of stating when to prefer the leaderboard over x402_trust_score or x402_trust_preview, so no explicit exclusion criteria.

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 and no output schema, the description carries the full burden and does disclose the return content: exactly three reports at best/median/worst positions, in the same shape as x402_trust_score. It does not mention quota, cost, or determinism, but for a static no-arg sample pack this is solid disclosure.

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

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

Two short sentences with zero filler; the content of the pack is front-loaded before the no-argument note.

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?

Because there is no output schema, the description is the only source of return-value information, and it supplies the cardinality and shape. It stops short of describing the report fields themselves, but that detail is fairly delegated to the referenced x402_trust_score shape.

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?

Zero parameters, so the baseline is 4; the description reinforces this with 'Takes no arguments', leaving no ambiguity about invocation.

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 concrete deliverable: three complete trust reports (best, median, worst) formatted exactly as x402_trust_score returns them. It implicitly distinguishes itself from sibling x402_trust_score by framing itself as a sample/preview of that tool's output, though it never states this routing 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 relationship to x402_trust_score is implied by 'exactly as x402_trust_score returns them', letting an agent infer this is a preview. However there is no explicit when-to-use guidance (e.g. 'call this before spending quota on x402_trust_score') and no when-not-to-use statement.

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 does disclose one genuinely useful behavioral trait — unknown endpoints are live-probed on the spot, implying real network latency or cost — but says nothing about caching of known endpoints, authentication, rate limits, or error behavior.

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

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

Two tight sentences: the return payload is front-loaded and the operational caveat follows. No filler, and every clause 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?

With no output schema, the description usefully enumerates the return fields (score, grade, recommendation, price, flags), which is exactly what the agent needs to interpret results. It remains slightly incomplete on cost/latency expectations of the live probe and on how failures or unknown-but-unprobeable endpoints are reported.

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% for the single 'resource' parameter, and the schema already gives a format example, so the baseline is 3. The description adds no syntax, normalization, or validation detail beyond what the schema states.

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 resource (one x402 endpoint) and the artifact returned (a full trust verdict with score, grade, recommendation, price, flags), so an agent can tell it apart from a generic search tool. It does not name or contrast with the nearest siblings (x402_trust_preview, x402_trust_bulk), so differentiation is implied by 'full' and 'one' 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?

There is no explicit when-to-use guidance and no mention of alternatives, despite siblings x402_trust_preview and x402_trust_bulk that clearly compete for the same task. The only usage-adjacent signal is that unknown endpoints get live-probed, which hints at latency but never tells the agent when to prefer this over a preview or bulk call.

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

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

With no annotations, the description carries the full burden. It usefully defines what 'verified' means (domain control plus confirmed contact email) and discloses a real behavioral trait — verification is informational and never affects the score — but says nothing about read-only safety, permissions, or result shape.

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 tight sentences with no filler, and the identifying criteria are front-loaded. The opening is a noun fragment rather than a verb phrase, a minor structural weakness, but overall efficient.

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

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

For a simple read-only list tool with full schema coverage this is adequate, and pagination is covered by the schema. However, with no output schema the description doesn't indicate what fields a listed provider contains, leaving a small completeness gap.

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

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

Schema description coverage is 100%, so both limit and offset are already fully documented with ranges and defaults. The description adds no parameter context, which is acceptable at this coverage level but earns no credit above baseline.

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

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

The description clearly identifies the resource (hosts that proved domain control and confirmed a contact email) and implies a listing operation. It implicitly differentiates itself from score-related siblings via 'it never changes the score', though it never explicitly names an alternative tool.

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

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

Usage is implied rather than stated: an agent can infer you call this to see which providers are verified. There is no explicit when-to-use, when-not, or reference to a sibling like x402_trust_score as the alternative, leaving routing 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 delivers two genuinely useful behavioral facts: cancellation is idempotent, and the watch log remains readable until expiry (i.e. cancel is not a data-destroying operation). It omits error/permission behavior for an already-expired or unknown watch, so it is strong rather than complete.

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 short clauses, action first, then the two facts that matter most (log retention, idempotency). Every word earns its place and nothing is 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 two-parameter mutation with no annotations and no output schema, the description covers the two things an agent most needs: the effect on existing data and safe retry behavior. Minor gaps remain around failure modes and whether a cancelled watch can be renewed or recreated.

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

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

Schema coverage is 100% and both parameters (watch_id, secret) are documented in the schema, including that the secret is a one-time bearer token from x402_watch_create. The description adds no parameter-level detail, so the baseline of 3 applies.

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

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

"Stop a watch now" states a specific verb and resource, and the surrounding watch_* siblings (create/edit/renew/events) make the cancel semantics easy to place. It does not explicitly name which sibling to use instead when the intent is to pause or edit, so it stops short of full differentiation.

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?

"Stop a watch now" plus "cancel early" implies the trigger condition (ending a watch before its expiry rather than letting it lapse), but no alternative is named and no prerequisites or exclusions are stated. Usage is inferable, not explicit.

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

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

With no annotations, the description carries the full burden. It does disclose real behavioral traits: a fixed 30-day lifetime, one-endpoint scope, push-vs-poll delivery, and that a one-time secret is returned and must be kept. It omits auth/permission requirements, whether the watch starts immediately, quota limits, and what happens at expiry (silent stop vs. transition to a renew state).

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 tight sentences with no filler; the scope ('one endpoint'), lifetime ('30-day'), and delivery modes are front-loaded, and the closing 'Returns a one-time secret, keep it.' efficiently flags the one operational gotcha an agent must not miss.

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 creation tool with no output schema, naming the one-time secret return covers the most important return value. However, a 5-parameter mutation of nontrivial state should also mention the observation-set precondition, auth needs, and the follow-up tools (watch_events, watch_renew, watch_cancel) needed to make the watch useful.

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 baseline is 3 and the schema already documents event names, webhook URL formats, max-5 limits, and liveness sensitivity. The description adds only loose correspondence between alert categories and the events parameter, without new syntax or default details.

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

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

The description states a concrete resource (a 30-day monitor for one endpoint) and enumerates the alert conditions it covers (payTo/price changes, delisting, spec regressions, downtime), which is far more specific than a restated title. It implies creation via the one-time secret return, but never explicitly contrasts itself with x402_watch_edit, x402_watch_cancel, or x402_watch_renew, so sibling differentiation is left to the name.

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?

There is no guidance on when to create a watch versus editing, renewing, or cancelling one, nor a pointer to x402_watch_events for consuming alerts. The schema's important precondition that the endpoint 'must already be in our observation set' is never surfaced in the description, so an agent could call this on an unobserved URL without warning.

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 behavioral burden, and it does disclose one genuinely valuable trait: new URLs are validated first and a failed test leaves the old config untouched (atomic update). However, it omits other behavioral facts an agent needs for a mutation tool — the one-time bearer-secret auth requirement, reversibility of changes, and whether webhook/slack_url edits can be applied partially.

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, zero filler, with the action and its scope front-loaded and the transactional guarantee immediately following. Every clause 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 6-parameter mutation tool with no annotations and no output schema, the parameters are well covered by the schema and the description adds the key atomicity fact. What is missing is context on authentication (the required secret), the response/confirmation behavior, and precedence when multiple field groups are updated at once, leaving the definition minimally viable rather than 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 the schema already documents all six parameters, including the 'omit to keep current' semantics and the max-5 URL constraint. The description only restates the three edit categories at a high level and adds no syntax, format, or edge-case detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (Change) and resource (a watch) plus the three mutable fields (webhook URLs, sensitivity, subscribed events), so an agent knows exactly what the tool mutates. It does not explicitly name the sibling alternatives (create/cancel/renew), so sibling discrimination is left implicit 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?

The description gives no when-to-use vs when-not guidance and never points to related siblings like x402_watch_renew or x402_watch_cancel. Usage is inferable from the verb, but nothing tells the agent under what conditions editing is the right call versus recreating or renewing the watch.

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. 'Nothing between polls is lost' is a genuinely useful durability guarantee for a cursor-based poll, but the description says nothing about the one-time bearer secret's handling, rate limits, or error/expiry 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?

Two short sentences, front-loaded with the action and required inputs, and the durability clause is a deliberate, load-bearing addition. Nothing is padded or 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 4-parameter polling tool with no annotations and no output schema, the description covers the polling contract but omits what the event log actually returns and how the two distinct cursors (since vs watch_since) relate to different event streams, leaving an agent to learn that only from 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 description coverage is 100%, so both cursors and the two required identifiers are already documented in the schema. The description only restates watch_id/secret and the cursor paging idea, adding no syntax or format detail beyond what the schema provides.

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

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

States a specific verb (poll) and resource (a watch's event log), which cleanly separates it from the other x402_watch_* siblings that create, edit, cancel, or renew watches. It does not explicitly name an alternative, but the resource is 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 mention of 'paging by the returned cursors' implies an iterative polling loop and hints at how to continue, but there is no explicit when-to-use guidance or statement of when this is preferable to x402_watch_create or the trust/score siblings. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses the effect (adds exactly 30 days), the precondition (active watch), and that the same secret/credential is reused. It omits what happens on failure, whether renewal is idempotent, and any cost implications, so it is only partially transparent for a mutation 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?

Two short sentences with zero padding, and the core action is front-loaded ahead of the qualifier. Every word 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?

The tool is simple (one parameter, no nested objects) but has no output schema and no annotations, so the description is the only source of behavioral and return information. It covers the action and precondition but says nothing about the result or failure modes, leaving a modest gap.

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

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

There is a single parameter (watch_id) with 100% schema coverage, and the schema already explains it as the id returned by x402_watch_create. The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

The description gives a specific verb and effect ("Add another 30 days") on a specific resource ("an active watch"), so the operation is unambiguous. It does not explicitly differentiate itself from sibling watch tools like x402_watch_edit or x402_watch_cancel, so it falls short of a 5.

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

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

"an active watch" implies a precondition (the watch must exist and be active), which gives some usage context. However, it names no alternatives and gives no when-not guidance relative to x402_watch_edit or x402_watch_create, leaving the agent to infer the correct tool.

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