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

With no annotations, the description carries the full burden, and it does disclose meaningful traits: the metric is modeled rather than observed, has monthly history, and costs 0.05 USDC on Base via x402 (a real billing/auth detail). It stops short of describing the return shape (no output schema exists) or the repeat-purchase semantics, which are only encoded in the confirmNewPurchase parameter.

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 that front-load the definition and the most decision-relevant caveat ('not actual assistant query logs'), then layer on availability, cap, and cost. Nothing is padding, though the parenthetical pricing clause is slightly bolted on.

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, un-annotated tool with no output schema, the description covers provenance, cadence, caps, and price, which is a reasonable amount. It still leaves the response format and the practical consequences of repeated purchases unexplained, so an agent cannot fully predict the call's outcome or cost profile.

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 75%, comfortably in the territory where the schema does the heavy lifting, so a baseline 3 applies. The description reinforces the 1000-keyword cap already stated by maxItems but adds no new semantics for keywords, language_code (undocumented in the schema), or location_code.

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, unusual resource — a 'modeled AI question-demand indicator' derived from DataForSEO signals including People Also Ask — and explicitly disclaims that it is real assistant query logs. That verb+resource pairing is precise enough to distinguish it from near-neighbors like keyword_metrics, keyword_metrics_multi, and google_trends, though it never names an alternative.

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

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

Usage is only implied: an agent can infer this is the tool for AI-search question demand rather than classic search volume, and the 'not actual assistant query logs' caveat warns when the data is inappropriate for certain claims. But there is no explicit when-to-use, when-not-to-use, or sibling 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 at all, the description carries the full burden, and it does disclose the key behavioral fact that the call costs 0.15 USDC on Base via x402. However it says nothing about permissions, failure/refund behavior, or why confirmNewPurchase exists for re-purchases, leaving meaningful gaps.

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

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

A single tight sentence that front-loads the resource and output scope, with the cost appended parenthetically. No filler, nothing 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?

There is no output schema, so the description appropriately specifies the return shape (summary metrics plus top 25 referring domains) and notes the payment requirement. It stops short of describing what the summary metrics contain or how failures are handled, but it is largely sufficient for a simple report tool.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema (including the domain/url aliases and the confirmNewPurchase warning). The description adds no parameter-level meaning beyond that, 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?

Names a specific resource (backlink profile) and states exactly what comes back (summary metrics plus top 25 referring domains). No sibling tool in the list covers backlinks, so it is naturally distinguishable, though it does not explicitly contrast itself with related tools like domain_rank or trust_check.

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

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

The description states what the tool produces but gives no guidance on when to reach for it versus sibling analytics tools such as domain_rank, trust_check, or competitors. The only situational hint is the price, which is a cost disclosure rather than usage direction.

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

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses the paid nature (0.03 USDC on Base via x402), which is genuine behavioral context, but omits idempotency/retry semantics, auth needs, and return format.

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?

A single front-loaded sentence leading with purpose, then cost. Efficient, though the parenthetical payment detail is dense and could be split for clarity.

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

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

For a payment-gated tool with no annotations, no output schema, and half-documented params, the description covers purpose and cost but leaves the return format and the confirmNewPurchase/dedup behavior unexplained. Adequate but with clear 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 coverage is only 50%: keyword and confirmNewPurchase are documented in the schema, while language_code and location_code are bare defaults. The description adds no parameter-level meaning to compensate for the undocumented half.

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 (organic Bing results) scoped to a keyword, and explicitly distinguishes itself from Google. It does not name the numerously similar siblings (serp_report, news_search, image_search), so it falls 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?

The phrase 'often different from Google' hints at why one might pick this engine but gives no explicit when-to-use/when-not guidance or named alternatives among the many search siblings. An agent is left to infer when Bing SERP beats serp_report or news_search.

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 exist, so the description carries the full load. It usefully discloses that this is a paid call costing 0.08 USDC on Base via x402 and that results carry source page and sentiment. It does not cover retry/failure behavior, rate limits, or authentication beyond the payment rail, leaving gaps for a paid mutation-adjacent endpoint.

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?

A single front-loaded sentence carrying purpose, return shape, index, and cost with no filler. The stacked parentheticals are dense but each earns its place; nothing is wasted.

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 3-parameter paid tool with no output schema and no annotations, the description adequately names the returned fields and the cost, and confirmNewPurchase handles repeat purchases in the schema. It still leaves the limit/pagination semantics and any failure behavior unexplained, so it is only just 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?

Schema coverage is 67%: keyword and confirmNewPurchase are documented in the schema, but 'limit' (integer, default 20, max 50) has no description anywhere. The description adds no parameter meaning at all - it never mentions paging, result caps, or the re-purchase flag, so it fails to compensate for the undocumented limit parameter.

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

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

States a specific resource and what it returns: web mentions of a brand or keyword with source page and sentiment, and identifies the underlying index (Content Analysis). This is clear enough to distinguish it from siblings like news_search or keyword_metrics, though it never names those alternatives 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?

No when-to-use guidance is given. With many SERP/keyword/news siblings (news_search, serp_report, keyword_metrics, llm_share_of_voice), the description never says when brand_mentions is the right choice rather than one of those. The only conditional guidance lives in the confirmNewPurchase schema field, not the description.

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 declares read-only safety, discloses that the call is paid, quantifies the cost (0.02 USDC on Base via x402), and reveals return behavior (decoded revert reason). It omits rate limits and failure/refund semantics on the paid path, 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?

It is a single information-dense sentence with the core action front-loaded and no filler. The stacked parentheticals are slightly compressed but nothing is wasted.

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 7-parameter tool with no annotations or output schema, the description covers the essentials an agent needs: read-only nature, payment model and cost, and revert decoding behavior, with the schema supplying parameter detail. Missing rate limits and partial-call/failure handling keep it from 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 86%, so the schema already documents almost every parameter (to, from, data, block, confirmNewPurchase, etc.). The description adds no parameter-level detail beyond what the schema 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 verb and resource ('Read-only EVM contract call') and names distinguishing traits (decoded revert reason, optional gas estimate). An agent can separate this from siblings like chain_info and chain_state, which read chain metadata rather than execute a contract call.

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/when-not guidance and never names an alternative. The only conditional hint is 'optional gas estimate' tied to the paid aspect, but there is no explicit instruction on when to choose chain_call over chain_info/chain_state, nor when the paid path is warranted.

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 burden. It does disclose cost ('free') and outlines the payload contents (chains, limits, prices), which is useful for a read-only metadata call, but says nothing about rate limits, auth, or freshness of the price 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?

It is a single short sentence, which is appropriately sized, but the trailing '(free) (free)' is duplicated boilerplate that wastes space and suggests templated generation. The redundant token should have been removed.

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 is the only source of information, and listing the returned fields (chains, limits, prices) partially substitutes for a return-value spec. However it omits the relationship to chain_state/chain_call and any usage trigger, leaving the agent to guess when this call is warranted.

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, so per the baseline this scores 4. There is nothing for the description to clarify beyond what the empty schema already communicates.

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 the resource and its contents specifically: supported chains, limits and prices for the on-chain data lane. It reads as the metadata/discovery counterpart to siblings chain_state and chain_call, though it never names them or explicitly contrasts itself. The jargon 'on-chain data lane' is the only 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?

There is no when-to-use guidance at all — no statement that this should be consulted before chain_call/chain_state, and no alternatives or exclusions mentioned. An agent can infer it is an info endpoint, but the definition provides nothing 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, and it does disclose the notable behavioral trait that this is a paid operation with a specific price and payment rail (x402 on Base). It omits anything about auth/payment prerequisites, failure or refund behavior, or rate limits, so the disclosure is partial.

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?

A single compact line, front-loaded with the resource and returned data, then the cost. Every clause carries information, though the parenthetical stacking of '(paid) (costs 0.05 USDC on Base via x402)' is slightly 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-param paid tool with no output schema, listing the returned fields is valuable, and the pricing disclosure is present. However, with no annotations and no output schema, the description should also cover prerequisites, the tokens/confirmNewPurchase interaction, and sibling differentiation, which it does not.

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 75% and the schema already documents tokens, address, and the confirmNewPurchase purchase-confirmation flag. The description confirms the ERC-20 balance read maps to the tokens param and the 5-chain scope matches the chain enum, but adds no format or semantic detail beyond the schema.

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

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

States a specific resource (wallet/contract state) and enumerates what is returned: native balance, nonce, EOA/contract status, and ERC-20 balances across 5 EVM chains. Clear verb+resource, though it never names or distinguishes itself from the apparent siblings chain_info and chain_call.

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 flags that ERC-20 balance reads are paid (0.05 USDC on Base via x402), which hints at cost-sensitive usage, but it gives no explicit when-to-use guidance and no routing versus chain_info or chain_call. An agent is left to infer which chain tool to pick.

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 behavior: a claimSecret is issued, the job is held for 48 hours, then returns to the board, and claiming is free. It omits failure modes (already-claimed job), exclusivity guarantees, and any permission requirements.

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

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

Short and front-loaded with the core action, but the trailing '(free) (free)' is a duplicated fragment that adds noise rather than information. The 48-hour rule is buried in a parenthetical instead of being stated cleanly.

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 annotations, no output schema, and only one-third schema coverage, so the description is the sole source of guidance — yet it omits parameter meaning, auth requirements, and the already-claimed case. The claimSecret/48-hour disclosure is helpful but the definition is not complete enough for a 3-parameter mutation tool.

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

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

Schema coverage is only 33% — just agent_url is documented — and 2 of 3 parameters (id, note) are undocumented anywhere. The description says nothing about the required id or the optional note, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource: 'Take an open job.' Combined with the sibling set (jobs, jobs_get, deliver, close), an agent can tell this claims an existing posting rather than listing or delivering one. It stops short of explicitly naming a contrasting sibling, so it is clear but only implicitly differentiated.

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 the usage context (open, unclaimed jobs) and reveals the 48-hour commitment window, which is useful timing guidance. However, it never says when not to use it — e.g., what to do if the job is already claimed, or how it relates to jobs_get/deliver.

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 full disclosure burden. It states the auth requirement (posterSecret) and that the call is "free," but says nothing about what closing does to the job, whether it is reversible, who is affected, or side effects. For a state-changing job operation this is a significant 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?

Short and front-loaded, which is good, but wastes tokens by repeating "(free)" twice and states the same idea redundantly. Still compact enough to read quickly.

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?

A state-mutating job tool with no annotations, no output schema, and 0% parameter documentation. The description should clarify the mutation's effect and the second parameter; instead it omits both, leaving an agent unable to predict the outcome of the call.

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

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

Schema coverage is 0%, so the description must compensate for both parameters. It explains poster_secret's origin ("you got when posting"), which is genuinely useful, but the "id" parameter is never mentioned and no format or meaning is given for it. Partial compensation at best.

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?

Names a specific verb and resource ("Close your own job"), which is more than a tautology. However, "close" is ambiguous - it could mean mark complete, cancel, or remove - and the description never clarifies the resulting state or distinguishes this from siblings like deliver, claim, or jobs. Adequate but underspecified.

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?

Only guidance is a prerequisite ("needs the posterSecret you got when posting"), which implies you must be the job's poster. There is no statement of when to choose this over deliver/claim/jobs_get or any exclusion. Minimal context, no 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 it does disclose one materially important trait: the call costs 0.05 USDC on Base via x402. However, it omits the purchase mechanics implied by confirmNewPurchase (caching, re-billing on identical requests) and says nothing about rate limits, permissions, or what happens if payment fails.

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?

A single front-loaded sentence with no filler, and the cost is placed at the end where it is easy to catch. It is efficient, though its brevity contributes to the gaps in the other dimensions rather than being purely virtuous.

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 five-parameter, paid, purchase-gated tool with no annotations and no output schema, the description is thin. It never explains the language/location defaults, the billing model tied to confirmNewPurchase, or the shape of the returned competitor list beyond 'keyword overlap metrics'.

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

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

Schema description coverage is only 40%, so the description must compensate and does not. It adds no meaning beyond the schema for limit, language_code (default 'de'), or location_code (default 2276), and an agent gets no hint that results default to the German market unless it inspects the raw defaults.

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 and scope: organic search competitors of a domain, plus the returned metric type (keyword overlap). An agent can distinguish it from data-retrieval siblings like domain_rank or ranked_keywords. It stops short of explicitly contrasting with the closest sibling, keyword_gap.

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

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

No when-to-use guidance, no prerequisites, and no named alternatives are given. The only routing hint is the price disclosure, which tells the agent this is a paid call but not when it is the right call versus free siblings such as keywords_for_site or domain_rank.

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, yet it discloses little beyond the fact that reports are 'published' and the call is free. It says nothing about permissions, rate limits, report freshness, or what a report contains; the duplicated '(free) (free)' consumes space without adding information.

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?

Short and front-loaded, which is good, but the trailing '(free) (free)' is a verbatim duplication that is pure waste. One sentence with a redundant parenthetical is not egregious but is clearly unpolished.

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

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

For a single-parameter read tool with no output schema and no annotations, the description is minimally adequate: an agent knows what it reads and that one example question is answered. It stops short of indicating the shape or scope of the returned report, which is the main remaining gap given the missing output schema.

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

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

Schema coverage is 100% and the single optional parameter already documents the bare-host format and the omit-for-list behavior, so no compensation is required. The description adds no parameter meaning beyond the schema, making the baseline 3 correct.

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 ('Read published x402 conformance reports') and adds a clarifying gloss of what a report answers ('does a seller refuse invalid payments?'). No sibling covers x402 conformance, so differentiation isn't needed, but 'x402' is jargon that leaves the resource somewhat opaque to an unfamiliar agent.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternatives are named. The only routing hint ('Omit for the list of latest reports') lives in the schema, not the description.

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 at all, the description carries the full burden. It usefully notes the operation is free and requires the caller's claimSecret, which hints at an authorization requirement, but it says nothing about state changes, reversibility, or what happens to the job after delivery.

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 short and front-loads the action, but the trailing '(free)' appears twice, which is redundant noise in an otherwise single-line description.

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

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

For a mutation tool with no annotations, no output schema, and 0% parameter coverage, this description is far too thin. An agent cannot tell what delivery does to the job state or how the note parameter is used.

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

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

Schema coverage is 0% and three parameters (id, note, claim_secret) are entirely undocumented. The description only gesturally references the secret, and even then uses 'claimSecret' while the schema field is 'claim_secret', leaving id and note with no explanation.

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+resource ("mark a claimed job as delivered") and clearly ties to the claim workflow among siblings like claim, close, and jobs. It is understandable without opening the schema, though it does not distinguish itself from the similarly-scoped 'close' sibling.

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 call this versus 'close' or other job lifecycle tools. The parenthetical about needing a claimSecret is a precondition but not a when-to-use rule, and no alternatives are named.

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 hints at a behavioral trait by labeling the listings '(free)', but does so twice, sloppily, and never states that the operation is read-only, whether it needs auth, or whether results are paginated. For a zero-annotation tool this is a thin behavioral profile.

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 short, but the duplicated '(free) (free)' fragment reads as an editing artifact and wastes the closing slot where scope or usage information should sit. The remaining content is front-loaded enough, but not polished.

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 annotations and no output schema, the description is the only source of information about what the agent gets back, yet it never describes the return shape (e.g. listing objects, categories, pagination). For a simple zero-arg tool it should at minimum say what fields or listing structure the agent can expect.

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

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

The tool takes zero parameters, so the baseline is 4. The description doesn't need to explain parameter syntax, and schema coverage is moot at 100% with an empty object.

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 identifies the resource (a curated DE/EU marketplace of external x402 services returning approved listings) but is a bare noun phrase with no verb, so it's unclear whether the tool fetches, authenticates against, or administers the directory. It also fails to differentiate from the nearby siblings directory_submit, directory_status, and directory_activate, which share the 'directory' namespace.

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 when-to-use guidance and no mention of alternatives. An agent cannot tell from the text whether this is the lookup step before directory_submit or a separate browsing endpoint, nor under what conditions it should be preferred over service_search.

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

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

With no annotations, the description carries the behavioral burden and does so well: it discloses a one-time listing fee, the exact cost (3 USDC), the chain/payment rail (Base via x402), and the result (listing goes live). It omits other material traits such as irreversibility of payment and what happens on payment failure, keeping 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?

A single front-loaded sentence pairing the action with its cost and outcome. Every clause earns its place; nothing is padded or repeated.

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 payment-gated mutation with no annotations and no output schema, the description covers the essential facts an agent needs: the precondition, the fee, and the resulting state. It stops short of describing payment-failure or idempotency behavior, though the schema's confirmNewPurchase note partially covers retries.

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 fully documents both 'id' and 'confirmNewPurchase' with rich guidance. The description adds no parameter-level meaning beyond that, 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+resource (activate an accepted directory listing) and adds the outcome ('your endpoint is live in the curated DE/EU marketplace'), so the agent understands what calling it accomplishes. It does not explicitly name the sibling tools it differs from (directory_submit/directory_status), so it stops short of a 5.

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

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

The precondition 'accepted directory listing' implies usage (a human review has already passed), which points the agent at the submit→status→activate flow. However, it never names alternatives or an explicit when-not, and the guidance about checking status and avoiding duplicate purchases lives in the schema, not the description.

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 a useful behavioral fact — the call is free — and the phrasing implies a non-mutating read, but it says nothing about auth requirements, polling behavior, or what a 'status' value can be. The doubled '(free) (free)' also suggests the field was appended mechanically rather than authored with care.

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?

One short, front-loaded sentence with the key constraint (id) placed where the agent reads first. It loses a point for the duplicated '(free) (free)' trailing tag, which is dead weight.

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

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

For a single-param read tool with no output schema and full schema coverage, the essentials are present. It still omits the practical context an agent needs — whether the review is async and needs re-polling, and what statuses to expect — so it is adequate 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 coverage is 100% and the schema itself tells the agent the id comes from directory-submit. The description only restates 'by id', adding no format, examples, or constraints beyond the schema. 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 verb (Check) and resource (review status of a directory submission), with the lookup key (id). It is distinguishable from its closest siblings directory_submit and directory_activate, though it never names them 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?

Usage is only implied: you check status after a submission. There is no statement of when to poll, how often, or why one would use this instead of directory_activate or status_json, so the agent must infer the workflow.

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 largely fails it: it does not disclose whether submissions are reviewed/moderated, how long listing takes, whether the listing is public, or whether an activation step (sibling directory_activate) is required afterward. It only implies a public, free listing, which is thin for a write/submission operation.

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

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

The single sentence is short and front-loaded, but the duplicated '(free) (free)' is wasted text and the brevity comes at the cost of omitting anything useful about the submission flow.

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 5-parameter submission tool with no output schema and no annotations, the description should explain what happens after submission and how it relates to the directory_status/activate siblings. None of that is present, so an agent cannot predict the outcome of calling it.

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

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

Schema description coverage is 100%, so the schema already documents url, price, contact, category, and description, including the 'never shown publicly' note for contact. The description adds no parameter-level meaning of its own, 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 (submit) and resource (x402 endpoint) plus the destination (curated directory), which is clearly distinct from read-oriented siblings like traffic_estimate or domain_rank. However, it does not differentiate itself from the closely-named siblings directory, directory_status, and directory_activate, leaving the submission-vs-activation relationship unstated.

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 indication of when to call this versus the related directory/directory_status/directory_activate tools, nor any prerequisites such as the endpoint needing to be live and answering HTTP 402. The only eligibility clue lives in the URL parameter's schema text, not in the description.

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 usefully discloses the cost and payment rail ('costs 0.05 USDC on Base via x402') and the response content, but stays silent on rate limits, whether repeated calls re-charge, and permission/auth needs. The cost signal is genuinely valuable, but a paid read operation warrants more 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?

A single dense sentence that front-loads the purpose and trails the cost as a parenthetical. Nothing is wasted, though cramming scope and billing into one sentence slightly blurs the reading priority.

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, no-annotation, no-output-schema tool, the description should say more: it omits the return shape, the meaning of the position buckets, and any routing against the many sibling ranking/traffic tools. It covers purpose and price adequately but leaves real 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 coverage is 50%: target and confirmNewPurchase are documented, while language_code and location_code are not described in either schema or description. The description's phrase 'of a domain' loosely maps to target but adds no syntax or format detail, so it fails to compensate for the coverage gap. 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 gives a specific verb+resource framing: 'Organic visibility overview of a domain', and enumerates the payload ('keyword counts by position bucket plus estimated traffic'). This is clear enough to distinguish it as a summary/overview tool, though it never names related siblings like ranked_keywords or traffic_estimate that an agent might confuse it with.

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 named alternatives, despite several overlapping siblings (ranked_keywords, traffic_estimate, keyword_metrics, competitors). The only usage-adjacent detail is the pricing note, which tells the agent nothing about when this tool is the right choice.

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 usefully discloses the paid nature (0.05 USDC on Base via x402) and the graded finding output, but it never states read-only status, whether the call mutates anything, or any rate/auth constraints.

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?

A single dense but front-loaded sentence that leads with the value proposition ('Security posture of a domain in one call') before enumerating coverage. No filler, though the comma-heavy list is somewhat dense.

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 must carry the return contract, and it does by specifying the A-F grade, prioritised findings, and the full menu of checks. For a read-style posture tool this is nearly complete; only permission/auth and read-only confirmation are unstated.

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 fully documents both parameters (bare domain format, confirmNewPurchase semantics). The description adds no parameter-level meaning beyond what the schema already provides; 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?

A specific verb+resource ('security posture of a domain') with an exhaustive enumeration of the checks performed (TLS, redirect, headers, SPF/DMARC, CAA, DNSSEC, RDAP, leak exposure) and the output shape (graded A-F). It clearly conveys what the tool does, but it never distinguishes itself from closely related siblings like trust_check, exposure_check, whois, or domain_tech.

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 never states when to reach for this tool versus the many overlapping siblings (trust_check, exposure_check, whois, domain_tech). The only usage-adjacent text is the cost note and the schema's purchase-confirmation guidance, neither of which routes the agent between 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?

No annotations are provided, so the description carries the full burden. It does disclose genuinely useful behavioral context: the call costs 0.05 USDC on Base via x402, which signals a paid, non-free operation. It stays silent on permissions, rate limits, latency, and failure behavior, and does not tie the payment disclosure to the confirmNewPurchase parameter.

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?

A single front-loaded sentence with the return payload first and cost last. Every clause earns its place except the slightly redundant 'Full technology stack' plus the enumeration, which is acceptable as detail rather than padding.

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 tool with no output schema and 100% schema coverage, the description covers what is returned and the payment requirement, which is adequate. It falls short on when to use it versus domain_rank and on what happens on repeated/paid invocations, leaving gaps for a paid tool nested among many lookalike siblings.

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 (target and confirmNewPurchase) are already documented with meaning and guidance in the schema. The description adds no additional parameter semantics, which is the expected baseline when the schema does the work.

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 (technology stack of a domain) and enumerates the categories returned (analytics, frameworks, CMS, servers, payment, ads) plus domain rank. That is clearly distinguishable from generic siblings like whois or site_audit. It does not, however, distinguish itself from the sibling domain_rank even though it also returns domain rank, leaving a routing 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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives. The closest relational cue is the cost note, which tells the agent this is a paid call but not when to prefer it over domain_rank, whois, or traffic_estimate.

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 privacy behavior (no training on inputs, content excluded from usage logs, temporary redelivery cache), the payment model and exact cost, and OpenAI compatibility with tool use. It omits failure/error behavior and rate limits, so not 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?

A single information-dense sentence, front-loaded with the core purpose (LLM chat completion in Germany) before privacy, compatibility, and pricing details. The heavy parenthetical nesting is slightly cluttered but every clause adds real information.

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

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

For a 12-parameter tool with nested conditionals and no output schema, the description covers privacy, pricing, and compatibility well. However, it leaves a large fraction of parameters and the payment/retry semantics unaddressed in prose, so it is adequate 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 coverage is 50%, so the description does not need to fully compensate but should add some value. It implies OpenAI-style messages/tools and JSON response format, which maps loosely to tools, tool_choice, and response_format, but it says nothing about model selection, max_tokens, or the thinking-toggle constraint, leaving half the surface undocumented anywhere.

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 ('LLM chat completion'), names the hosting location (Germany), and identifies OpenAI compatibility with tool use. This is clearly distinguishable from siblings like eu_llm_info and eu_embed, though it never explicitly contrasts itself with 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?

The description conveys that the tool is paid and costs 0.005 USDC, which is useful context, but it gives no when-to-use guidance versus siblings such as eu_embed or eu_llm_info, and no prerequisites or exclusions. There is only the schema-level note about confirmNewPurchase, which the description itself does not surface.

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 disclose meaningful traits: cost (0.005 USDC), payment rail (Base via x402), and data residency (processed in Germany). It falls short on the ambiguous 'temporary redelivery cache' phrase and says nothing about rate limits or what the response contains. Full behavioral disclosure is not achieved, but the payment and residency facts are genuinely valuable.

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

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

It is a single compact sentence with no filler, and the region and cost facts come early. The stacked parentheticals '(paid) (costs 0.005 USDC...)' read as an afterthought rather than structured 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 and no annotations, the description should be doing more: it never says what an embedding call returns (dimensions, format) or what the 'redelivery cache' means for repeat calls, leaving the schema's confirmNewPurchase flag to carry the repetition semantics alone. Cost and residency coverage is good; result-shape coverage is absent.

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 'input' and 'confirmNewPurchase' are fully documented in the schema itself and the description adds no parameter-level detail. 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 identifies the resource clearly ('Text embeddings') and adds a distinguishing qualifier ('processed in Germany'), so an agent can tell it apart from eu_chat and the other EU-region siblings. It never uses a verb, and the trailing 'temporary redelivery cache' clause muddies rather than sharpens the 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?

There is no when-to-use guidance at all — nothing says when to pick this over eu_chat or eu_llm_info, nor whether the tool is for one-off embedding calls versus batch pipelines. The '(paid)' note hints at a cost tradeoff but never turns into actionable selection 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, the description carries the full burden, and it does disclose that access is free and that output covers limits and data-handling policy. It says nothing about auth requirements, rate limits, caching, or freshness/stability of the model list.

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?

A single front-loaded noun phrase covers the whole tool with no filler. The duplicated '(free) (free)' suffix is sloppy noise that should have been cleaned up.

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 no-argument, no-output-schema informational tool, the description states the scope of returned content adequately. It is missing only the connective guidance about its relationship to the EU inference siblings eu_chat and eu_embed.

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, so the baseline is 4; there is no argument syntax for the description to explain. Nothing misleading is present regarding inputs.

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 set — models, limits, and data-handling policy — scoped to the 'EU inference lane', which distinguishes it from nearby siblings like eu_chat and eu_embed. It lacks an explicit verb ('returns'/'lists'), but the content an agent would receive 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?

There is no statement of when to call this versus eu_chat, eu_embed, or the non-EU inference path. The agent must infer that this is a metadata/introspection call to run before or alongside the EU inference tools; no preconditions or alternatives 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 burden. It discloses the core outcome (a free call credit worth up to $0.15) and implies a one-time limit ('one free call'), which is useful behavioral context. However, it omits auth requirements, whether the offer is per-agent or per-account, and the return format.

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?

A single front-loaded sentence with the 'Trade:' mechanism leading. Slightly cluttered by the redundant reward phrasing ('<= $0.15) in return (free)'), which repeats the same idea twice, but overall compact.

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 a required nested object, no output schema, and no annotations, the description explains the exchange but leaves gaps: no return format, no limit semantics, no guidance on the nested 'agent' fields. It is minimally viable but not 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% and the nested agent object is already documented. The description loosely maps to the 'agent' and 'seeking' parameters ('tell us about your agent and what you are looking for'), adding no syntax or meaning beyond what the schema provides. 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 states a concrete action pair: submit your agent info and what you're seeking, and receive one free call (<= $0.15). The 'Trade:' framing makes the give-and-get mechanism clear. It does not differentiate this tool from any sibling, but the verb+resource mechanics are specific enough to stand alone.

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, when-not-to-use, or alternative named. The sentence implies the action but gives no context for when an agent should invoke this versus other tools, nor whether it is a one-time onboarding step or repeatable.

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 at all, the description carries the full behavioral burden and does well: it discloses that results are aggregates only, never passwords or personal records, and that the call costs 0.03 USDC on Base via x402. It does not cover failure modes, caching, or rate limits, 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?

A single sentence, densely front-loaded with the core purpose before the data details and cost parenthesis. It earns its length by packing in return contents and payment terms, though the long dash/parenthesis structure makes it slightly harder to parse at a glance.

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 must describe returns itself, and it does: credential entries with last-seen dates and malware families, leak records, and official breaches, with the aggregate-only privacy guarantee. Cost is also disclosed. What remains thin is error/failure behavior, but for a lookup tool this is nearly 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 (domain and confirmNewPurchase) are already fully documented in the schema, including the 'target'/'url' aliases and the purchase-confirmation warning. The description adds no parameter-level information 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 operation (leak/infostealer exposure check) on a specific resource (a domain), then enumerates the concrete data categories returned (stealer-log credentials, leak records, official breaches). This is clearly distinguishable from the sibling exposure_check_email, which operates on an email rather than a domain.

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

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

Usage is implied by the purpose statement: an agent can infer to call this when it needs domain-level exposure data, and the domain-vs-email sibling split is inferable but never stated explicitly. There is no explicit when-to-use, when-not-to-use, or alternative-tool 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 behavioral burden and does so well: it discloses the output is aggregates only, that passwords/logins/devices/IPs are never returned, that the address is echoed only as SHA-256, plus the cost and payment rail. Missing only secondary traits like rate limits or error/retry 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?

Front-loads purpose, then layers scope, privacy constraints, and pricing in a compact two-clause structure. Dense but every clause carries information; no filler sentences.

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 tells the agent what is returned and what is deliberately excluded, plus cost and authorization. Only the return-value shape/format is left unspecified, which is minor here.

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 in the schema, and the description adds no syntax or format detail beyond the authorization notion already present on 'email'. The confirmNewPurchase repurchase semantics live entirely in 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?

States a specific verb+resource ('Leak and infostealer exposure of one e-mail address') and enumerates what the result covers (infection counts, leak records/sources). The 'one e-mail address' scoping implicitly distinguishes it from the sibling exposure_check (domain variant), though it never names that sibling 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?

Gives an authorization precondition ('addresses you own or are authorised to check') and a price (0.05 USDC on Base via x402), which is useful context. However it offers no explicit when-to-use vs when-not guidance relative to exposure_check or other search tools, so routing 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 behavioral burden. It usefully discloses payment cost (0.03 USDC on Base via x402) and the return format, but omits idempotency/caching behavior, auth requirements, and error handling — the confirmNewPurchase re-purchase semantics live only in the schema, not the 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?

A single front-loaded sentence with zero filler: resource, scope, return shape, and cost in one pass.

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 rightly explains the return values (weekly timeline plus per-term average). Scope, cardinality, and cost are covered; only edge-case behavior (failures, re-run/caching) is absent, which is minor for a simple read-style lookup.

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 keywords, location_code, and confirmNewPurchase are already documented. The description restates the 5-keyword cap and the per-term average but 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 resource (Google Trends interest), scope (last 12 months), and cardinality (up to 5 keywords), plus the exact return shape (weekly timeline plus per-term average). No sibling is a trends tool, so it is unambiguously distinguishable from the keyword/SEO tools in the list.

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 never says when to reach for this versus keyword_metrics, keyword_ideas, or ai_search_volume. It describes the output and cost but gives no selection criteria, prerequisites, or exclusions, leaving the agent to infer usage.

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 a real behavioral trait beyond the schema – the 0.03 USDC on Base via x402 cost – and sketches the return shape, but says nothing about pagination, rate limits, or the payment flow beyond a price tag.

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?

A single tight sentence, front-loaded with the resource and keyword trigger, then cost and return fields. No filler, though the parenthetical cost clause slightly crowds the return-field list.

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 5-parameter, paid tool with no annotations and no output schema, the description is thin. It partially offsets the missing output schema by listing return fields, but leaves param semantics, pagination, and error/payment behavior unexplained.

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 only 40% (limit, language_code, location_code are undocumented). The description only references 'keyword', which the schema already covers, and adds no meaning for the remaining parameters. With a sub-50% coverage gap, it fails to compensate.

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

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

States a specific resource ('Google Images results') and a trigger ('for a keyword'), and even names the return fields (image URL, page URL, alt text). It is clearly distinguishable from the other search siblings like news_search or maps_search, though it does not name an alternative 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?

There is no when-to-use guidance and no alternative named. An agent must infer that this is chosen for image lookups over the sibling search tools; the description never states the condition that selects it or 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?

No annotations are provided, so the description carries the full burden. It does disclose real behavior: posting is free and listings are 'reviewed before it appears' (moderation), and delivery/charge happen via the fulfiller over x402. It omits auth requirements, escrow/charge timing guarantees, and reversibility.

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

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

Single front-loaded sentence that mostly earns its place, but '(free)' is duplicated at the end, showing sloppy editing and wasting tokens.

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 no-annotation write tool with no output schema and 5 parameters, the description covers the core action and payment path but leaves undocumented the two undescribed params (category, deadline) and what lifecycle steps follow posting.

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 60%: task, budget_usd and x402_callback carry descriptions, while category and deadline are silent. The prose adds meaning only for budget and the callback ('delivers and charges you'), which is close to a baseline 3 given partial schema coverage.

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

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

A concrete verb+resource: 'Post a task with a budget and your x402 callback', plus the mechanism that another agent claims and delivers. It does not explicitly distinguish itself from the closely related jobs_get/claim/deliver siblings, so sibling differentiation is missing.

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

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

The description implies usage (publish work for another agent to fulfill) but gives no when-to-use vs alternatives such as jobs_get, claim, deliver, or close, and states no prerequisites or exclusions beyond the callback format.

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 discloses that the call is free and that results include budget and an x402 callback, but says nothing about authorization, pagination, result limits, or how 'open' vs other states behave by default.

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 short and front-loaded, but the trailing '(free) (free)' is a literal duplication that wastes space and slightly muddies the message. Otherwise efficient for a single-purpose read tool.

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

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

For a no-annotation, no-output-schema, one-param tool, the description covers what the tool returns and its cost, but omits the filter semantics and any listing/pagination behavior. Adequate but with a clear gap on the status parameter.

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

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

Schema description coverage is 0% and the single 'status' parameter (enum open/claimed/delivered/all, default open) is never explained in the description. The description mentions returned fields instead of the filter, so it fails to compensate for the coverage gap on the one parameter that matters.

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 (Read) and resource (the job board) and clarifies what it exposes: tasks other agents posted, with budget and their x402 callback. This is far more informative than the bare name jobs_get, though it doesn't explicitly differentiate itself from the sibling tool 'jobs'.

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 only usage signal is the '(free)' marker, which implies cost rather than explaining when to call this versus alternatives like jobs, claim, or deliver. No when-to-use or prerequisite guidance is 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 present, the description carries the full burden and does disclose the critical behavioral trait: a paid call costing 0.05 USDC on Base via x402. It also implies a compute/read operation rather than a mutation. It does not mention latency, caching of repeat requests, or rate limits, which is a modest 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?

A single front-loaded line: purpose first, scope second, cost last. No filler, nothing to trim.

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, no-output-schema tool the description covers what it produces (a 0-100 score per keyword) and the payment requirement, which is the main thing an agent could get wrong. Output shape beyond the score, and the retry/billing nuance hinted at by confirmNewPurchase, are left to 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 75% and the description reinforces two key semantics — the 1000-keyword cap and the 0-100 output scale. The one gap is language_code, which has no description in either the schema or the description; otherwise parameter meaning is well covered.

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?

Specific verb+resource (SEO ranking difficulty score) with an explicit numeric scale (0-100) and scope (up to 1000 keywords), plus a plain-language restatement ('how hard it is to rank on Google page one') that separates it from sibling metric/volume tools like keyword_metrics and ai_search_volume.

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

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

No explicit when-to-use or when-not-to-use statement, and no alternatives named among the many keyword siblings (keyword_metrics, keyword_ideas, keyword_gap). The cost disclosure (0.05 USDC per call) is useful practical context that implicitly frames it as a deliberate, paid lookup, but the agent must still infer selection 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, the description carries the full behavioral burden, and it does disclose a key trait: the call costs 0.05 USDC on Base via x402. However, it omits other behavior an agent needs — read-only nature, pagination/limit behavior, error or payment-failure handling, and the fact that a paid purchase may need explicit confirmation.

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?

A single compact sentence with the core purpose front-loaded and the cost appended parenthetically. The em-dash pricing clause is slightly awkward but earns its place by disclosing payment.

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, paywalled tool with no output schema and no annotations, the description covers purpose and pricing but leaves meaningful gaps: it doesn't explain the return shape beyond 'each position', the undocumented limit/language/location parameters, or the locale defaults. Adequate but not 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 only 50%: limit, language_code, and location_code have no schema descriptions at all, and the description never mentions them, so it does not compensate for the gap. Notably the German-market defaults (language_code 'de', location_code 2276) are invisible to an agent unless it opens the raw schema.

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

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

Specific verb+resource: it returns keywords that two domains BOTH rank for, plus each position, framed as 'the competitive overlap'. That scope ('BOTH rank for') inherently distinguishes it from single-domain siblings like keyword_metrics and ranked_keywords, 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?

Usage is only implied by the nature of the output ('competitive overlap' between two domains) and by the required target1/target2 inputs. There is no explicit when-to-use statement, no when-not-to-use, and no named alternative such as keyword_metrics or competitors.

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 burden and does disclose the key trait: this is a paid call (0.03 USDC on Base via x402), which is genuinely useful behavioral context. It omits permission/idempotency behavior and the fact that limit/language/location shape the result, so coverage is partial 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?

A single tight sentence with the core purpose front-loaded and the cost caveat appended. No filler, though the parenthetical about pricing could be structured more clearly.

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 partially compensates by naming the return fields (search volume, CPC), and it flags the cost. But five params at 40% coverage, an unexplained default locale, and no sibling routing leave it only minimally adequate for a paid mutation-adjacent tool.

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

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

Schema coverage is only 40%: only the 'keyword' and 'confirmNewPurchase' params are documented in the schema, and the description adds meaning to neither. It says nothing about limit, language_code, or location_code (defaults de/2276), leaving half the surface undocumented anywhere.

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 ('keyword suggestions for a seed keyword') and enumerates the returned fields (search volume, CPC). This is clear enough to separate it from metric lookups, but it never names or contrasts the close siblings (keyword_metrics, keywords_for_site, keyword_gap), so differentiation is left to inference.

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 when-to-use or when-not-to-use guidance and no alternatives named. The description implies you supply a seed keyword, but an agent choosing between keyword_ideas, keyword_metrics, and keywords_for_site gets no routing help.

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 a real behavioral trait — a 0.15 USDC cost on Base via x402 — which is valuable for an agent deciding whether to call it. However, it says nothing about rate limits, caching, failure modes, or whether repeat calls are billed, and the confirmNewPurchase purchase semantics are documented only in the schema.

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

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

Three tightly packed sentences, front-loaded with the capability and return fields, with the disambiguation clause and cost caveat placed after. 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?

With no output schema and no annotations, the description usefully names the returned fields and the billing model, which covers the biggest gaps. It falls short only on the undocumented language_code/location_code parameters and their defaults, which an agent must infer from the schema alone.

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

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

Schema description coverage is 50%, and the description only echoes what the schema already states ('up to 1000 chosen terms'). It adds nothing for language_code or location_code, which have no descriptions in either place, so it does not compensate for the gap. 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 the exact metrics returned (search volume, CPC, advertising competition, monthly history from Google Ads), and explicitly disambiguates from keyword_difficulty by noting competition is not organic SEO difficulty. An agent can tell this apart from sibling tools without opening the 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?

The disambiguation sentence ('Advertising competition is not organic SEO difficulty') gives useful negative context, but there is no explicit when-to-use guidance versus keyword_metrics_multi, keyword_ideas, or ai_search_volume, nor any stated prerequisites beyond the price hint.

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 a real behavioral trait: the payment model (0.15 USDC on Base via x402) and that one call replaces N per-location purchases. It omits auth requirements, rate limits, and return format, 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?

A single sentence with zero waste, front-loaded with the resource and scope before the cost detail. Nothing to trim.

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 the description compensates by covering scope and the cost model an agent needs to reason about spending. It leaves the return shape and auth unaddressed, but for a read-style metrics lookup that is a minor gap.

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

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

Schema coverage is 75%, so the schema already documents keywords, location_codes (with per-location pricing), and confirmNewPurchase. The description only corroborates "one keyword set" and the per-location cost, adding little syntax or meaning beyond the structured fields, 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 concrete resource (search volume, CPC, competition) with a precise scope: one keyword set across up to 30 locations in a single call. The multi-location/single-payment framing distinguishes it from the keyword_metrics sibling notionally, but it never names that sibling, so differentiation is implied 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?

"One payment instead of one per location" implies when this is preferable to a per-location alternative, giving implied usage guidance. However, no alternative is named, no when-not conditions are given, and no prerequisite for setting location_codes is 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?

No annotations are provided, so the description carries the full behavioral burden, and it does disclose one genuinely important trait: the tool costs 0.05 USDC on Base via x402, i.e. it is a paid call. That is real value beyond the schema. It still omits return shape, latency, or what happens on a repeat request, so with zero annotation coverage the picture is only partially 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?

A single front-loaded sentence with the core purpose first and the cost caveat trailing. The nested parentheticals ("(Google Ads data)", "(costs 0.05 USDC on Base via x402)") are slightly cluttered but 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 5-parameter paid tool with no annotations, no output schema, and only 40% schema coverage, the description should carry much more: return contents, what the pricing/permission model means for callers, and clarification of the undocumented locale/limit params. It covers only purpose and cost.

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

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

Schema description coverage is only 40%: target and confirmNewPurchase are documented, but limit, language_code, and location_code are not. The description adds nothing about any parameter, so it fails to compensate for the coverage gap, landing below the baseline-3 threshold that high coverage would have justified.

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?

"Keywords a website SHOULD target, derived from its content (Google Ads data)" names the specific resource (target keyword suggestions) and the derivation method, which is more than a tautology. However, it does nothing to distinguish itself from keyword-adjacent siblings such as keyword_ideas, keyword_metrics, or ranked_keywords, so an agent cannot tell which sibling to pick from the text alone.

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

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

The description states what the tool produces but gives no when-to-use guidance, no exclusions, and no reference to alternatives like keyword_ideas or ranked_keywords. The only implied usage cue is "derived from its content", which is a data-source note rather than 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 burden, and it does disclose two meaningful traits: the tool is a paid request costing 0.1 USDC on Base via x402, and the data is first-party measurement rather than a crawl. It omits permission/auth requirements, idempotency and retry behavior, and failure modes, so the disclosure is partial.

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?

A single front-loaded sentence puts the metric first and relegates cost to a trailing parenthetical, which is the right ordering. It is dense but every clause carries information; only the wording is slightly elliptical.

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, parameterized data tool with no output schema and no annotations, the description covers purpose, methodology and cost adequately but leaves out return shape and purchase/retry semantics. An agent can invoke it, but not without ambiguity about the payment flow.

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% (days, category, confirmNewPurchase all documented, with an enum and default), so the schema already does the heavy lifting. The description adds no syntax or format detail beyond that, 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?

The description names a specific resource and metric: share of answers and average rank per brand for vendors that LLMs name when asked for a tool, measured daily across six models and eight questions. That is far more concrete than a restated name. It does not explicitly distinguish itself from the sibling llm_share_of_voice_info, 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?

There is no guidance on when to call this versus the info sibling or other research tools, and no stated prerequisites. The confirmNewPurchase parameter implies purchase/retry semantics, but the description never explains when re-buying is appropriate.

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, but it does disclose the return content (categories, models, questions, amount of available data) and flags that access is free. It omits any indication of whether the underlying data is live, cached, or gated, and says nothing about what an empty result means.

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?

One short sentence that front-loads the resource name, which is good. But '(free)' is duplicated verbatim at the end, which is plainly a structural artifact and wastes the only remaining token budget.

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

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

For a zero-parameter informational tool with no output schema and no annotations, the description is nearly sufficient: it enumerates what information is returned, which is the main thing an agent needs. Slightly more on when to reach for it would make it fully self-contained.

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, so there is no parameter semantics to explain; the baseline of 4 applies. The schema trivially covers 100% of the (empty) surface.

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 communicates the resource ('LLM-Share-of-Voice measurement') and its scope (categories, models, questions, data volume), which lets an agent separate it from the sibling llm_share_of_voice that performs the measurement itself. However it has no verb and never says outright that this is an informational/metadata lookup, so the action is only implied.

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?

Nothing states when this should be called versus the sibling llm_share_of_voice. The only usage cue is the parenthetical '(free)', which hints at cost but not at call conditions or prerequisites. An agent must infer that this is a pre-flight discovery 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 must carry the full behavioral burden, and it does disclose a critical trait: the call 'costs 0.05 USDC on Base via x402'. That is genuine value beyond the schema. It still omits other behavior an agent needs (return shape, whether the purchase is idempotent/one-shot, rate limits), so it lands at a middling 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?

A single front-loaded sentence: it names the resource and its fields first, then appends the payment caveat. No filler or redundancy, though the dash-appended pricing clause slightly bends the 'one idea per sentence' ideal.

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, and the description helpfully enumerates the returned fields and the cost, which is what an agent most needs. But for a paid, 5-parameter tool it omits pagination/limit behavior, idempotency semantics, and sibling routing, leaving 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 80%, so the schema already documents query, categories, confirmNewPurchase, and location_coordinate. The description reinforces that results are geo-scoped and tied to a payment, but adds no syntax meaning beyond the schema. 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 verb+resource ('Business listings around a coordinate') and enumerates the returned fields (name, category, address, phone, website, rating), so the agent knows exactly what resource it retrieves. It does not name or distinguish itself from lookalike siblings such as maps_search or local_market_check, which keeps it short of a 5.

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

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

The phrase 'lead lists for local outreach' implies the intended use case, giving a hint of when to reach for this tool. However, there is no explicit when-to-use/when-not guidance and no mention of alternatives like maps_search, leaving the agent to 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 disclosure burden and does well: it states the price (0.1 USDC on Base via x402), the quote-first flow, and that missing or partial results remain explicit rather than silently degraded. It does not cover retry/idempotency behavior, which the schema's confirmNewPurchase hint partly shoulders.

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 front-loaded: the core purpose and deliverables lead, followed by the quote prerequisite and the pricing clause. Every sentence contributes; length is justified by the multi-part output and payment model.

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 correctly characterizes the return (one JSON report containing competitor domains, optional own-domain presence, and action tips) and the pricing model. It is complete enough to invoke correctly, though the combined anyOf requirement structure is left to 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 the schema already documents every parameter including aliases and the confirmNewPurchase semantics. The description adds only the notion of a single keyword/location and optional own-domain presence, which is baseline-level value over structured fields.

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 compound action: comparing organic Google results and Maps listings for one keyword and location, and enumerates the deliverables (competitor domains, optional own-domain presence, 3-5 tips). This composite scope inherently separates it from single-purpose siblings like serp_report, maps_search, and competitors.

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 read the quote endpoint first (local_market_check_quote) before buying, which is a concrete prerequisite rather than implied guidance. It stops short of stating when NOT to use this versus serp_report or maps_search, so it does not reach the top of the range.

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

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

With no annotations provided, the description carries the full burden and does little: it implies a read-only pricing lookup but never states that it is non-destructive, has no side effects, requires no auth, or what exactly is returned. The only behavioral signal, '(free)', is stated twice and only covers cost.

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 short and front-loads the resource, but the redundant '(free) (free)' repetition is wasted text and the sentence is fragment-like rather than a complete statement of what the tool does.

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

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

For a zero-parameter, no-annotation, no-output-schema tool, the description gives the minimum needed to guess intent, but leaves the relationship to the sibling local_market_check and the shape of the returned quote 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?

The tool takes zero parameters, so there are no parameter semantics to explain; the schema is empty and coverage is 100%. Baseline 4 applies, and the description introduces no conflicting parameter expectations.

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 identifies the resource (Local Market Check package price) and implies a quote-retrieval action, but never uses an explicit verb and does not differentiate itself from the sibling 'local_market_check'. The trailing '(free) (free)' duplication adds noise rather than clarity.

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

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

'before you pay' implies the usage phase (quote prior to purchase), which is useful but unspecified as an explicit when/when-not rule. No alternative tool or condition for choosing this over local_market_check or the other *_quote tools is named.

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, yet it only discloses that the call is free (stated twice). It does not say whether the lookup is a read, whether it requires auth, rate limits, or what the returned code lists look like, so an agent gets little beyond the obvious.

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 a single short sentence and front-loads the purpose, which is good. However, the duplicated '(free) (free)' is pure noise and the sentence never develops the lookup context it gestures at.

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 explain the return shape; it names the two returned fields but not their structure or how to feed them into downstream endpoints. For a simple three-parameter lookup with full schema coverage this is minimally adequate 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 q, limit, and country are already fully documented in the input schema. The description adds no format, default, or interaction detail beyond what the schema provides, which is the baseline 3 case.

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 verb ('look up') and the exact resources returned ('location_code and language_code'), which is more specific than a tautology. It does not distinguish itself from siblings such as maps_search or local_businesses, and the phrase 'for the paid SEO endpoints' is vague about which endpoints actually consume these codes.

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, no prerequisites, and no named alternatives. The parenthetical '(free)' hints that it is a helper lookup preceding paid SEO calls, but that inference is left entirely to the agent.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses that this is a purchase with a real financial cost (0.5 USDC on Base via x402), a fixed 7-day lifetime, and a capability limit (receive-only, so no sending). It omits what the purchase returns and any refund/idempotency behavior beyond what the parameter description already states.

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

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

A single front-loaded sentence with the verb and resource first and cost details trailing in parentheticals. The stacked parentheses ('(paid) (costs 0.5 USDC ...)') are slightly awkward but nothing is wasted.

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 purchase tool with no annotations and no output schema, the description covers what it is, what it costs, and its lifetime, but not what the agent receives after purchase or how the resulting inbox is consumed (the mail_messages path). Adequate but leaves a real gap around post-purchase workflow.

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 the single parameter's own description already explains duplicate-purchase semantics, so the description adds nothing parameter-specific. 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?

States a specific verb+resource ('Buy a receive-only email inbox') with concrete scope (7 days, receive-only, paid). The closest sibling, mail_messages, is presumably the read side of this inbox, but the description never names or contrasts against it, so an agent must infer the relationship.

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 cost and payment rail but no when-to-use guidance: nothing says to use this when a disposable inbox is needed, nor how to proceed afterward (e.g., via mail_messages). The confirmNewPurchase parameter carries the only behavioral guidance, and it lives in the schema, not the description.

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 that 'orderId acts as the secret', i.e. an auth/access mechanism, and that the call is free. It still omits what the mail payload looks like, volume, or pagination 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?

Very short and front-loaded, but the trailing '(free)' is duplicated verbatim, which is sloppy and wastes one of only two clauses. The core fact is stated first, which is good.

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 minimal one-param, no-output-schema tool this is thin. A reader cannot tell how it relates to 'mail_inbox', what constitutes a valid orderId, or what the response contains.

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

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

Schema coverage is 0%, so the schema only names 'orderId' as a string with no meaning. The description compensates by explaining that orderId serves as the secret, adding real semantic value beyond the bare schema, though it doesn't specify the identifier's source.

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 ('Read') and resource ('mail an inbox received'), so the basic action is discernible. However, it fails to distinguish itself from the sibling 'mail_inbox', leaving ambiguity about which of the two mail tools to pick.

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

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

No when-to-use guidance, no prerequisites, and no mention of when to prefer this over 'mail_inbox'. The parenthetical 'free' hints at cost, but no explicit selection guidance is offered.

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 full behavioral burden. It does disclose the pricing model and payment rail (0.03 USDC on Base via x402) and hints that calls are billable, which is valuable. However it says nothing about latency, rate limits, caching, or the repeat-purchase semantics beyond the parameter text.

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?

A single sentence, but it bundles three unrelated ideas (result contents, cost, payment protocol) with no front-loaded structure. It is not wasteful, yet the parenthetical pricing coda is harder to parse than a separate sentence would 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?

A paid, non-idempotent search tool with 5 parameters, no annotations, and no output schema. The description never explains return shape, result ordering, pagination via limit, or what happens on repeat calls, leaving major gaps for an agent deciding whether to spend money.

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 only 40%: keyword and confirmNewPurchase are documented, but limit, language_code, and location_code have no descriptions anywhere. The description itself adds no parameter detail, so the geographic and language defaults (de, 2276) remain opaque.

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 ('Google Maps results for a search') and enumerates the returned fields (rating, address, phone, website), which is more specific than most siblings. Sibling set is huge and contains adjacent tools like local_businesses and service_search, but the description never distinguishes itself from them, keeping it out of 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?

No when-to-use context, no mention of when a sibling like local_businesses would be the better choice. The only conditional guidance is buried in the schema for confirmNewPurchase, not in the description.

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 it does disclose the notable behavioral trait that each call costs 0.03 USDC on Base via x402. However, it says nothing about auth requirements, rate limits, failure modes, or what the paid/confirmNewPurchase flow does beyond what the schema already states.

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

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

A single dense sentence that front-loads the resource and outcome, with the cost caveat appended in parentheses; nothing is wasted. It is efficiently sized, though the parenthetical pricing clause is easy to skim past.

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 sketches the return shape (headlines with source, URL, snippet, timestamp) and flags the per-call cost. It remains incomplete on the language/location parameters and on the purchase-confirmation mechanics, which are non-obvious for a paid endpoint.

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

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

Schema description coverage is only 50%: keyword and confirmNewPurchase are documented in the schema, but language_code and location_code appear as bare defaults with no explanation of their accepted values or meaning. The description adds no parameter-level detail at all to compensate for that gap.

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

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

Names a specific verb and resource ('Google News results for a keyword') and enumerates the returned fields, so the agent knows exactly what it gets. It does not, however, distinguish itself from adjacent SERP-style siblings such as bing_serp, serp_report, or image_search, so sibling differentiation is missing.

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 statement of when to use this tool rather than bing_serp, serp_report, or maps_search, and no prerequisites or exclusions are given. Usage must be inferred entirely from the tool name and the mention of news headlines.

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 nature and price (0.03 USDC on Base via x402), the speed profile, and the no-crawl behavior. It omits auth/payment mechanics context and any rate-limit or idempotency traits that would matter for a paid call. Solid but not exhaustive.

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?

A single dense sentence with the key discriminator ('ONE page', 'no crawl') and the notable behavioral detail (cost) front-loaded. No filler words; 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 paid, no-annotation, no-output-schema tool the description covers scope, speed, cost, and returned artifacts. It leaves the payment/confirmation flow (the unusual confirmNewPurchase param) to the schema, which is defensible, but a hint about the x402 purchase lifecycle would round it out.

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 fully documents url, enable_javascript, and confirmNewPurchase, including the non-obvious purchase-confirmation semantics. The description adds nothing about parameters, which is acceptable given full coverage but is the baseline rather than added value.

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

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

States a specific verb and resource (technical audit) with an explicit scope limiter ('ONE page') and distinguishes itself from crawl-based site audits by saying 'no crawl'. An agent can separate this from siblings like site_audit and site_audit_onpage immediately. It also enumerates the outputs (OnPage score, meta, timings, failed checks).

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

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

Clearly frames when to use it: single-page, instant, seconds instead of minutes, and explicitly not a crawl. However it never names an alternative sibling tool (e.g., site_audit for multi-page) by name, so the routing decision is implied rather than explicit. No when-not guidance beyond 'ONE page'.

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, but it does disclose that this is a read operation and that it is free, and that results are 'evidence-bound'. It omits auth requirements, rate limits, and how to identify which conformance runs exist.

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

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

A single front-loaded sentence with no filler. It is efficient, though the parenthetical '(free)' is the only added signal and the sentence is quite terse for its scope.

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

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

For a zero-param read tool with no output schema and no annotations, the description is minimally adequate but leaves open what a 'conformance run' is and how one is identified, which matters given the adjacent 'conformance' sibling.

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, so there is nothing for the description to disambiguate. Baseline of 4 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 (Read) and resource (evidence-bound summaries of completed conformance runs), which is far clearer than the opaque name 'prose'. However it does not differentiate itself from the sibling 'conformance' tool, so an agent cannot tell how the two relate.

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

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

No when-to-use guidance, no prerequisites, and no alternatives named. The '(free)' tag hints at cost considerations but says nothing about when this tool should be chosen over 'conformance' or other 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 behavioral burden. It does disclose two genuinely valuable traits: the cost ('0.05 USDC on Base via x402') and the fact that it is a snapshot with no automatic monitoring. It omits permission/auth requirements, rate limits, and any error or failure behavior, which is a meaningful gap for a paid, un-annotated 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, front-loaded with the returned payload and followed by the usage constraint and cost. Every clause carries distinct information with no padding or redundancy.

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

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

There is no output schema, so the description reasonably explains the returned fields, and it supplies the cost/one-shot constraints. However, for a 5-parameter paid tool it leaves the limit parameter undocumented and never clarifies its relationship to near-identical siblings, leaving the agent with residual ambiguity.

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

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

Schema coverage is only 40% across 5 parameters. The description adds meaning for target/location/language ('one domain and selected location/language'), but says nothing about the limit parameter (default 50, max 100) or confirmNewPurchase, whose semantics live only in the schema. Partial compensation, so 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?

States a specific verb/resource pair ('Domain ranking snapshot') and enumerates the payload (keywords, positions, ranking URLs, search volume) scoped to one domain with location/language. It does not, however, distinguish itself from the closely-named sibling keywords_for_site or keyword_metrics, so an agent must guess which ranking tool is appropriate.

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 line 'Save the JSON for a later, separately requested comparison; no automatic monitoring' tells the agent this is a one-shot snapshot rather than a monitoring subscription, which is useful context. But it gives no explicit when-to-use-vs-alternative guidance against keywords_for_site, keyword_metrics, or domain_rank, leaving the sibling choice 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the paid nature and price range ('costs 0.03-0.5 USDC on Base via x402') and the return formats, but says nothing about auth prerequisites, rate limits, or the significance of the confirmNewPurchase re-purchase flag beyond what the schema states.

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

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

A single dense sentence with nested parentheticals; the core purpose is front-loaded but the price and SERP-feature details are crammed into trailing clauses. It is not bloated, but structure is a run-on rather than cleanly segmented.

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, and the description compensates by enumerating the returned payload (organic results, SERP features, JSON and Markdown formats) plus the payment cost. For invocation it is nearly complete, missing only usage routing and permission details.

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

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

Schema coverage is 75%, and the description only names 'keyword and location', echoing schema fields rather than adding format, defaults, or code semantics. The confirmNewPurchase meaning lives entirely in the schema. Baseline 3 is appropriate given the schema does most of the 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?

States a specific verb+resource ('Google SERP snapshot for a keyword and location') and enumerates the returned organic fields and SERP features. An agent can distinguish it from sibling serp-style tools like bing_serp or news_search without opening the 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?

The description explains what the tool returns but gives no when-to-use, when-not-to-use, or alternative guidance. With siblings like bing_serp, news_search, and local_businesses present, the agent gets no explicit routing rationale.

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 behavioral burden. It does convey that the index is local and bounded (implying no external network fetch, reinforced by the schema note that the query is never forwarded), but it omits rate limits, pagination behavior for offset/limit, and what a result or empty result looks like.

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 sentence is short, but it contains a duplicated "(free) (free)" fragment, which is pure waste and suggests an unpolished definition. The single clause is front-loaded, but the redundancy undercuts the structure score.

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

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

For a 5-parameter tool with no annotations, no output schema, and only 60% schema description coverage, this one-line description is not sufficient. An agent cannot determine return shape, pagination semantics, or how this differs from the numerous other search and directory siblings.

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 60%, and the description adds no parameter meaning whatsoever. The limits on q (12 distinct words), offset, and limit are only discoverable from the schema, and the description does not clarify filter semantics like network normalization or category exact-match.

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 provides a verb ("Search") and a resource ("a bounded local index of public x402 catalogues"), so the basic action is identifiable. However, "x402 catalogues" is niche jargon and the description does nothing to distinguish this tool from the many other search-style siblings such as maps_search, news_search, or image_search.

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

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

There is no statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. The repeated "(free)" tag hints at a cost advantage over paid siblings but does not explain when the free local index is preferable to a live source search.

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

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

With no annotations, the description carries the full burden and handles the important non-obvious traits well: it is a paid, one-off purchase costing 0.5 USDC on Base via x402, hosted in Germany (a data-residency signal relevant to analytics), and it lists exactly what the buyer receives. What is missing is the irreversibility/refund picture of the charge and any auth prerequisites.

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?

A single front-loaded sentence that puts the verb, the product and the term first, then qualifications. The trailing stack of parentheticals — '(paid) (costs 0.5 USDC on Base via x402)' — is slightly redundant since 'paid' and the explicit price say the same thing, but it is compact overall.

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 provisioning tool with no annotations and no output schema, the description covers what is bought, for how long, where it is hosted, what it costs, and which deliverables come back. It lacks only failure/refund semantics and auth requirements, which is a modest gap for this complexity.

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

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

Schema description coverage is 100%, including a detailed warning on confirmNewPurchase about intentional repurchase vs retries, so the schema already does the heavy lifting. The description adds nothing about any of the three parameters, 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 concrete action (buy) and resource (cookieless website analytics for 30 days) and enumerates the deliverables: snippet, read-only dashboard link, stats API. That makes it distinguishable from siblings like site_stats (read stats) or site_renew (renew). It stops short of explicitly naming those siblings, and the bare tool name 'site' does no work 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?

Usage is only implied: the word 'Buy' and the 30-day term suggest this is for provisioning a new subscription rather than reading or renewing. There is no explicit when-to-use, no exclusion, and no pointer to site_renew for existing sites or site_stats for retrieving data, which are the obvious alternatives in the sibling list.

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 a major behavioral trait: the call costs 1 USDC on Base via x402, which an agent must know before invoking. It also bounds the crawl at 20 pages. It stops short of stating payment/idempotency semantics, whether a partial crawl still charges, or any rate limits — though confirmNewPurchase in the schema hints at repeat-purchase 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?

A single dense sentence, front-loaded with the highest-value framing ('Complete SEO picture of a domain in one call') followed by the enumerated deliverables and the cost. Every clause carries information, though the run-on structure and the parenthetical cost clause make it slightly harder to scan.

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

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

There is no output schema, so the description usefully enumerates the return payload (traffic, keywords, competitors, backlinks, on-page score, duplicates, broken links, non-indexable pages, SSL) and states the pricing model. The main gap is the completely unexplained localization parameters, which no structured field covers.

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

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

Schema description coverage is 50%, and the description adds nothing about parameters at all — language_code and location_code have no descriptions anywhere, and their defaults (de, 2276) are never explained. The only numeric detail in the description ('up to 20 pages') is not a parameter. The description fails to compensate for the coverage gap.

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

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

The description enumerates the concrete outputs (traffic estimate, ranked keywords, organic competitors, backlink profile, on-page crawl up to 20 pages), so an agent knows exactly what this composite tool returns. It signals bundling with 'in one call' but never names the sibling alternatives (traffic_estimate, ranked_keywords, backlinks_report, site_audit_onpage) it overlaps with, so differentiation is left to inference.

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 only implied: the phrase 'Complete SEO picture ... in one call' suggests reaching for this instead of assembling the individual keyword/backlink/competitor tools, and the on-page crawl overlaps with site_audit_onpage. There is no explicit when-to-use, when-not-to-use, or routing statement against any of the many siblings.

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

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

No annotations are provided, so the description carries the full burden. The only behavioral signal is the '(free)' tag, oddly duplicated, hinting at no credit cost; there is nothing about auth requirements, rate limits, failure modes, or what the crawl summary contains.

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 tool's purpose is front-loaded in a single sentence, but the trailing '(free) (free)' duplication is clear waste and the nested parentheticals make the sentence harder to parse than it needs to 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?

For a one-parameter fetch with no output schema and no annotations, the description covers where the input comes from but says nothing about the shape or completeness of the returned summary, nor about how it differs from the completed-audit result.

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

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

Schema coverage is 0% for the single taskId parameter, but the description compensates by explaining its provenance (returned by the audit response). It does not describe the expected format or validity conditions of the id, so it only partially fills the gap.

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

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

It names a specific verb (fetch) and resource (on-page crawl summary) and scopes it to a paid audit that was still crawling at delivery, which implicitly separates it from the full site_audit tool. However, the phrasing is convoluted and it never names the sibling it complements, so the agent must infer the relationship.

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 parenthetical '(taskId from the audit response)' implies this is a follow-up call after site_audit, which is useful routing context. It does not state when not to use it or what to do instead if the audit completed normally, so guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the operation is paid (0.5 USDC on Base via x402) and auth-gated via siteId + secret, which is real behavioral value. Gaps remain: no failure/reversibility behavior, and it never mentions the confirmNewPurchase idempotency guard that the schema hints at.

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?

A single compact parenthetical that front-loads the core action and appends cost/auth details. Efficient with no wasted sentences, though the telegraphic style leaves some meaning implicit.

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 mutation with no annotations and no output schema, it covers the essentials (cost, chain, payment protocol, auth) but leaves out failure handling, idempotency guidance tied to confirmNewPurchase, and parameter formats. Adequate but with clear 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 coverage is only 33%: confirmNewPurchase is well documented in the schema, but siteId and secret are bare strings. The description merely names (siteId + secret) without adding format or meaning, and omits confirmNewPurchase entirely, so it does not compensate for the low coverage.

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

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

States a specific verb (extend/renew), resource (analytics site), and scope (30 days), so an agent knows exactly what the tool does. However, it draws no explicit contrast against related siblings like site or site_stats, so differentiation is left to inference.

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

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

The description implies renewal context but gives no when-to-use vs alternatives, no prerequisites beyond the payment note, and no exclusions. An agent has no guidance on when to call this instead of other site-related tools.

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

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

With no annotations, the description carries the full behavioral burden. It hints that 'secret acts as the key' (an auth requirement) and that the tool is 'free,' but says nothing about rate limits, what a missing/invalid secret does, or the shape of the response for a read operation.

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

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

It is a single, front-loaded sentence with no filler, which is good. However, the parenthetical '(free)' is duplicated pointlessly and the auth/scope notes are crammed into awkward nesting rather than structured order.

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 3-parameter tool with no annotations, no output schema, and 0% schema coverage, the definition does far too little. An agent is left guessing what siteId accepts, what days controls, and what the metrics response contains.

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

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

Schema description coverage is 0%, so the schema documents none of the three parameters. The description partially compensates by explaining that 'secret' is the key, but leaves 'siteId' (what a 'bought analytics site' identifier is) and 'days' (the lookback window, bounded 1-90) entirely unaddressed.

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 specific return values (pageviews, visitors, visits, bounces, top pages) and scopes them to a 'bought analytics site,' so an agent knows it is an analytics-metrics reader rather than a crawl/audit tool. It is dimly distinguished from siblings like site_audit or traffic_estimate, but the phrase 'bought analytics site' is idiosyncratic and unexplained.

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 when-to-use or when-not-to-use guidance and no named alternatives, despite many adjacent siblings (traffic_estimate, site_audit, site, site_renew). The only implicit signal is that the site must be a 'bought' analytics site, which the agent cannot resolve on its own.

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 genuinely useful behavior: the operation is free and the refund arrives as panel credit rather than a cash refund. It omits whether cancellation is reversible, what happens on failure, and any auth/rate-limit context.

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

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

Single sentence, front-loaded with the verb and eligibility condition, which is good. But '(free)' is redundantly repeated twice, indicating sloppy composition.

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

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

For a one-parameter mutation with no annotations and no output schema, the description covers eligibility cost and refund destination, which are the essentials. It still leaves the parameter undocumented and the post-cancellation state undescribed.

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

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

Schema description coverage is 0% and the single required parameter orderId has no description. The description says nothing about where orderId comes from or its format, so it fails to compensate for the schema gap.

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

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

States a specific verb ('Cancel') and resource ('an order') with a scoping condition ('that has not started yet'). The smm_ prefix distinguishes it from the sibling sms_cancel even though the description text itself does not name alternatives.

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

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

The eligibility condition ('has not started yet') implies when the tool applies, which is useful routing signal. However, it names no alternative for cancelling a started order and gives no prerequisites, so guidance is only implicit.

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 it does describe the shape of the returned data, which is valuable since there is no output schema. However, it never states that this is a read-only/free lookup versus a mutating call, gives no pagination or rate-limit context, and the parenthetical '(not order-type support)' plus the duplicated '(free) (free)' are ambiguous enough to obscure meaning.

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