AgentPay — Pay-per-call AI Microservices

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

Annotations already disclose the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds a genuinely useful behavioral fact not in annotations: the per-call cost ($0.10 USDC). It does not describe latency, rate limits, or what a 'brief' should contain.

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

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

Front-loaded with the tool's function, then the deliverable, then cost. Mostly tight, though the "15+ yrs media/ad-sales expertise baked in" clause is marketing puffery that consumes space without guiding invocation.

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 generative tool with no output schema and 0% param coverage, the description usefully enumerates the return components, but leaves the required 'brief' input and 'count' undefined. An agent knows roughly what it gets but not how to shape the request.

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% across 3 params. The description compensates partially for 'platform' by naming concrete values (Google/Meta/LinkedIn), but leaves 'brief' (required) and 'count' entirely unexplained. Given the low coverage, it should do more.

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 ("Ad copy generator") and enumerates the deliverable (headlines, descriptions, CTAs, A/B variants) plus target platforms (Google/Meta/LinkedIn). No sibling tool overlaps this space, so differentiation is moot, but the purpose is unmistakable.

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

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

The description never says when to use this tool vs. alternatives, nor any precondition for invoking it. It implies a marketing-copy use case but gives no explicit context, exclusions, or 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?

Annotations already declare idempotent and non-destructive behavior, so the description need not restate safety. It does add a genuine behavioral fact beyond the structured fields: the call costs $0.01 USDC, signaling a paid operation. It does not explain the readOnlyHint=false or what the returned score 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?

A single terse line with no filler, and the core purpose is front-loaded before the pricing detail. Appropriately sized for a one-parameter lookup, though it verges on under-specification.

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, the description conveys what is returned (a trustworthiness score) and the cost of the call. The main missing piece is guidance on output shape or failure modes, but the low complexity keeps this adequate.

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 the single required parameter (endpoint_url) carries no description, so the description must compensate. 'Endpoint trustworthiness' clarifies that the parameter is the endpoint being scored, which adds meaning, but it omits format expectations (URL scheme, host only, etc.).

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 ('agent reputation score' for 'endpoint trustworthiness'), making the tool's function clear. It implicitly distinguishes itself from sibling risk tools like wallet-risk and token-safety by scoping to endpoint trust. A retrieval verb is only implied, but the resource is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives such as wallet-risk, token-safety, or sanctions-screen, which occupy adjacent trust/risk domains. The only usage-relevant fact disclosed is the per-call price.

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

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

Annotations cover safety (readOnly=false, destructive=false, idempotent=true, openWorld=true), and the description adds genuinely useful non-annotation context: the 10-call cap and $0.05 USDC per-call pricing. It does not, however, explain failure semantics (what happens if one of the 10 calls fails or if payment/repeat invocation recharges) or how results are returned, leaving the idempotentHint=true interaction with a paid operation unaddressed.

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 sentence, front-loaded with the core purpose and the call cap before the pricing detail. Minor redundancy in 'Cheaper and faster than paying per call ($0.05 USDC per call)' but 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 single opaque string parameter with 0% schema coverage and no output schema, the description should specify the request format and the return shape. It supplies the service list and cost, but an agent still cannot construct a valid 'calls' value from the definition 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 coverage is 0% and the sole parameter 'calls' is an undocumented string, yet the description never explains its format (JSON array, delimited list, etc.) or how each entry names a service and its arguments. It conveys the allowable service types and the count limit, but not the syntax required to actually populate the 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 action (run up to 10 paid service calls in one request and one payment) and enumerates the batchable services (summarize, sentiment, extract, translate), which are exactly the sibling tools it consolidates. An agent can distinguish this aggregator from the individual single-call siblings 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?

It gives a selection rationale ('cheaper and faster than paying per call'), which implies you should prefer it when issuing multiple calls. However, it never states an explicit when-not (e.g. for a single call, use the individual tool) and the cost comparison is stated as a benefit rather than a decision rule.

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

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

Annotations already declare it is non-read-only, open-world, non-destructive and idempotent, so the description adds real value by disclosing the payment rail (x402 USDC), the minted amount (600 credits), the credit value ($0.01), the auth token (X-AgentPay-Token) and the cost saving. The only gap is it does not reconcile the idempotentHint with a per-call payment.

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

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

The purpose is front-loaded, but the single sentence is crowded with two parentheticals and repeats the '$5 USDC' cost at both the start ('one $5 USDC x402 payment') and the end ('($5 USDC per call)'). That trailing price is redundant and costs 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?

With no parameters and no output schema, the description carries the load and does so reasonably: pricing, credit conversion, spending scope and token are all covered. It leaves only minor ambiguity about how repeated purchases behave given the idempotency annotation.

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 the schema fully documents the (empty) input contract and the description is not expected to add parameter meaning. The pricing detail it supplies is extra, not required.

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 ('prepaid credit pack') and the exact effect ('one $5 USDC x402 payment mints 600 call-credits'), so the agent knows precisely what this tool does. It is trivially distinguishable from all read-only analysis siblings, none of which are payment tools.

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

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

Usage is only implied via the value proposition 'saves 20% vs pay-per-call', which hints at when this is preferable, but there is no explicit when-to-use/when-not statement or named alternative. Adequate but leaves the agent to infer the purchasing context.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true and openWorldHint=true, so the mutation/idempotency profile is covered. The description usefully adds the price, the credit yield, the +30% bonus and the X-AgentPay-Token mechanism, but says nothing about auth requirements or what happens on a repeated purchase (despite idempotentHint=true).

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 front-loaded sentence with no filler; the key offer (price, credits, bonus) leads. The trailing '($20 USDC per call)' parenthetical sits awkwardly against the '$20 USDC mints 2600 call-credits' claim and reads as confusing rather than clarifying.

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 tool with a full annotation safety profile and no output schema, the description covers the essentials. The critical omission is sibling differentiation from buy-credits and buy-credits-starter, which an agent needs in order to choose the right pack.

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 and there is no parameter semantics for the description to supply or omit. Nothing here is missing.

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

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

States a specific resource (a 'Pro credit pack') and its concrete output (2600 call-credits for $20 USDC), so the agent knows exactly what buying this does. It does not, however, distinguish itself from the near-identical siblings buy-credits and buy-credits-starter, which is the most important differentiation here.

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 pick this pack over buy-credits or buy-credits-starter, even though those siblings share almost the same name. The agent must infer selection from price/bonus numbers alone, with no stated conditions or 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?

Annotations already declare non-read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context: exact price, credit amount, bonus, and that credits work on every endpoint via X-AgentPay-Token, which helps an agent understand the purchase outcome.

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 is front-loaded with the pack name and price, then efficiently adds credit amount, bonus, usability, and token header. Every phrase earns its place.

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

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

For a zero-parameter purchase with rich annotations and no output schema, the description covers cost and outcome well. It could be more complete by stating what the call returns or how it relates to sibling credit packs, but enough is present to invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it adds no misleading or missing parameter information.

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

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

The description states a specific resource (starter credit pack) and action (mints 115 call-credits for $1 USDC), making the tool's purpose clear. It does not explicitly differentiate from siblings like buy-credits or buy-credits-pro, 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?

No explicit guidance on when to use this starter pack versus buy-credits or buy-credits-pro. The word 'starter' implies a default entry option, but no conditions or alternatives are 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?

Discloses the per-call cost ($0.02 USDC), which is meaningful context beyond the annotations (readOnlyHint=false, idempotentHint=true, openWorldHint=true). However, it says nothing about what "text" should contain, latency, or failure modes.

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 compact line, front-loaded with the resource and outputs, cost tucked at the end. No waste.

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 classification tool with no output schema, the description should describe the shape of the classification result (e.g., label sets, confidence scale). It only lists field names, leaving an agent unable to interpret or route the output.

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 the description provides no information about the single required "text" parameter — not its format, length limits, or expected content. The 1-param baseline of 4 is not earned because the description adds zero parameter meaning.

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

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

States a specific verb+resource ("Insurance lead classifier") and enumerates the outputs (intent, urgency, line of business, confidence). Sibling 'insurance-analysis' is not differentiated, so 4 rather than 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 guidance, no prerequisites, no mention of when to prefer this over insurance-analysis. The only added detail is pricing.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds useful context by disclosing a $0.05 USDC per-call cost, but it does not explain payment mechanics, auth requirements, or why readOnlyHint is false for a review operation.

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

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

The description is a single front-loaded sentence with no filler; the price is appended efficiently. It is appropriately concise, though its brevity contributes to the overall documentation gaps.

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

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

For a simple two-parameter paid tool, the description covers purpose, review scope, and cost. However, with no output schema and 0% schema description coverage, it leaves parameter meanings, language optionality, and payment/return behavior undocumented.

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%, with two parameters (`code`, `language`) and no descriptions. The tool description does not mention either parameter, so it adds no semantic meaning beyond the bare schema property names.

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

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

The description names a specific verb and resource: 'code review,' and lists concrete review categories (bugs, security, performance, quality score). It is clear enough to distinguish from most siblings, though it does not explicitly compare itself to any alternative tool.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternatives. It states what the tool does and its cost, but an agent gets no routing help beyond the obvious code-review intent.

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

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

The description adds a pricing detail ($0.02 USDC per call) which is useful behavioral context not present in annotations. Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description does not contradict these, but it also doesn't elaborate on what happens during the scan or what the output 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?

Single concise sentence that front-loads the core purpose and includes a pricing detail. No wasted words.

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

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

For a content scanning tool with no output schema and no annotations on output, the description provides minimal information about what the scan returns (e.g., scores, labels, explanations). It also omits any prerequisites like API key or USDC balance. This is inadequate for an agent to understand the tool's full behavior.

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

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

One parameter with 0% schema description coverage. The description does not explain the 'text' parameter, but with only one obvious input (text to scan), the baseline is 4 per the rule for 0 parameters (or near-zero complexity). The parameter name itself is self-explanatory.

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 capability: content security scanning for PII, toxicity, and bias. The named categories distinguish it from generic tools like 'sentiment' or 'classify-insurance', though it doesn't explicitly name a sibling alternative or dataset 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?

No guidance on when to use this tool versus alternatives (e.g., 'sanctions-screen', 'threat-intel'). The description simply states what it does without indicating appropriate contexts or 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?

The description discloses a concrete behavioral trait the annotations don't: a per-call cost of $0.005 USDC. However it never explains the curious readOnlyHint=false (presumably because calls incur payment) nor states anything about latency, rate limits, or return shape. With annotations covering openWorld/idempotent/destructive hints, this is a modest add.

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; the price is appended compactly. It is efficient, though arguably too terse to give the agent everything it needs.

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, 0% parameter coverage, and zero required params, yet the description explains neither the input contract nor the response. For a tool with two undocumented parameters and no schema help, it leaves significant gaps an agent must guess at.

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% for two parameters (symbols, vs_currency), so the description must carry the load but doesn't. It names BTC/ETH/SOL as examples but never maps them to the symbols parameter, says nothing about array formatting, and never mentions the vs_currency quote-currency option.

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 (real-time crypto prices) with concrete examples (BTC, ETH, SOL), so an agent immediately knows it fetches market prices. It doesn't explicitly distinguish itself from lookalike siblings like defi-yields or token-safety, but the verb+resource are 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 when-to-use, when-not-to-use, or alternative guidance. The description merely asserts what the tool returns, leaving the agent to infer context from the sibling list 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?

Annotations already declare openWorldHint=true, idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds important behavioral context beyond that: the operation is premium and costs $0.25 USDC per call, and it produces a cited markdown report. It does not contradict the annotations, though it leaves auth or rate-limit behavior unstated.

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 definition is a single front-loaded sentence that communicates the core activity, output format, and price efficiently. It is appropriately sized, though 'PREMIUM' is promotional rather than functional. No explanatory sentence is wasted because there are so few.

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

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

For a tool with no output schema and 0% schema description coverage, the description omits too much. It states the output format and cost but does not explain the depth parameter, expected research scope, latency, or when to prefer this over lighter siblings. An agent cannot confidently invoke it beyond providing a topic.

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% for both parameters, and the description mentions neither 'topic' nor 'depth.' The required topic is only implicit in the research concept, and the optional depth parameter is completely unexplained. With low schema coverage, the description needed to compensate and does not.

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

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

The description states a specific research activity and output: 'multi-source web research into a cited markdown report.' This distinguishes it from siblings like web-search or summarize, though it does not explicitly name an alternative. The 'PREMIUM' label is marketing framing rather than a functional distinction.

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 guidance on when to use this tool versus web-search, web-scrape, or summarize. The only implied usage cue is 'deep research,' but the description does not state conditions, exclusions, or alternatives. An agent must infer when a multi-source cited report is preferable.

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

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

Annotations already carry the safety profile (openWorldHint=true, destructiveHint=false, idempotentHint=true), so the bar is lower. The description usefully adds the per-call price ($0.01 USDC), which is genuine behavioral context for a paid tool, but says nothing about rate limits, auth, or what the response 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?

A single front-loaded line with no filler; the data fields come first and the cost caveat is appended last. It is appropriately sized, though it is terse to the point of under-specification rather than efficiently concise.

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 lookup tool with no output schema and no annotation-level parameter detail, the description leaves both inputs entirely unexplained. An agent knows the topic but not how to actually call it.

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

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

Schema description coverage is 0% for both parameters (chain, protocol), so the description must compensate and does not. 'protocol info' refers to returned data, not to the protocol parameter's accepted format or values, and chain is never mentioned at all.

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

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

The description names the resource ('DeFi yield data') and enumerates the returned fields (APY, TVL, protocol info), so an agent can tell it apart from crypto-price or market-intel by topic. However, it uses a bare noun phrase with no verb (get/list/filter), leaving the operation type implicit.

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

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

No when-to-use guidance, no exclusions, and no named alternatives among the many sibling data tools. The only auxiliary information is a cost note, which does not help an agent decide whether this is the right tool.

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

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

Annotations only cover the safety/idempotency profile, and the description usefully adds the per-call cost ($0.003 USDC), which is genuine context an agent needs before invoking. However it says nothing about authentication, rate limits, or output format, and it never addresses the readOnlyHint=false declaration, which is surprising for a pure data-fetch 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?

A single front-loaded sentence with no filler: the resource is stated first and the returned tiers follow. The cost detail is tucked into a trailing parenthetical, which slightly buries pricing that an agent arguably needs early, but the phrasing is dense and efficient.

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

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

For a no-parameter, no-output-schema tool, the definition does adequate work: it enumerates the data points returned and discloses the call cost. Without an output schema the description could say more about the response shape (single object? per-tier fields?), but nothing critical for correct invocation is missing.

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

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

The tool takes zero parameters, which sets the baseline at 4. The schema confirms an empty properties object, so there is no parameter semantics to clarify and the description neither misleads nor omits anything on this axis.

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 (Ethereum gas prices) and enumerates the exact data returned (rapid/fast/standard/slow tiers in gwei plus ETH spot price), so an agent can tell what it produces without opening any schema. It stops short of naming a verb or contrasting with the overlapping sibling crypto-price, so it is clear but not fully 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?

There is no when-to-use guidance, no conditions for calling it, and no reference to alternatives. The sibling crypto-price also returns ETH pricing, yet the description never explains which tool to prefer, leaving the agent to infer the boundary.

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

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

The description adds a genuinely useful behavioral fact the annotations do not carry: the cost of $0.03 USDC per call. Annotations already declare idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered; however, nothing is said about output shape, accuracy/confidence, or failure behavior on malformed input.

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 operation with its input sources; the pricing parenthetical is compact. Nothing is wasted, though the line is doing very little work 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?

With no output schema, no parameter documentation, and no usage guidance, this definition leaves the agent guessing about what the return value looks like (key-value object? JSON?) and how to shape the `fields` argument. A structured-extraction tool needs more than one line to be callable with confidence.

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 description does not explain either parameter. In particular, the role of the optional `fields` array (a list of field names to extract?) is left entirely ambiguous, and the expected format of `text` is unstated, so 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?

States a specific operation and resource: structured field extraction producing key-value pairs from emails, forms, and documents. It is clearly distinguishable from siblings like summarize, classify, and sentiment, though it does not name any 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?

There is no statement of when to use this tool versus alternatives such as summarize or classify, no prerequisites, and no exclusions or input-type limits. Usage must be inferred entirely from the one-line purpose.

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

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

The description adds a real behavioral trait beyond the annotations: the cost of '$0.005 USDC per call,' which explains why readOnlyHint is false for an otherwise read-like operation and warns the agent about a monetary side effect. It stops short of noting rate limits or what triggers failure.

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 core function and appends the cost. Zero filler, every clause earns its place.

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

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

With no output schema, the description ideally covers returns, but for a simple two-param utility it is nearly complete: purpose, both modes, and pricing are present. The return format and error behavior are the only 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 0%, so the description must carry the load. It conveys the two modes (place name input vs coordinate input) which maps to the query/reverse params, but never explicitly ties the 'reverse' flag to its effect, leaving some inference to the agent.

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

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

The description states a specific verb+resource pair and covers both directions: 'Geocode place names to lat/lon; reverse geocode coordinates to addresses.' An agent immediately knows what the tool does, and no sibling tool overlaps this capability.

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

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

It implicitly signals the two modes (forward vs reverse geocoding via the coordinate/place-name distinction), but offers no explicit when-to-use context, prerequisites, or alternatives. Usage is inferable but not spelled out.

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

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

Annotations already cover safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description adds a key behavioral detail: pricing ($0.03 USDC per call). However, it does not explain what the output looks like (since no output schema exists) or any rate limits/auth needs.

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 concise sentence with key info: purpose and cost. Front-loaded with the main capability. No wasted words.

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

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

Given no output schema and 0% schema coverage, the description should explain return format and the 'detail' parameter. It omits both, making it incomplete for correct invocation. Pricing is valuable but insufficient to cover the missing behavioral and parameter context.

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

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

Schema coverage is 0%, so neither parameter is documented in the schema. The description only clarifies that image_url is a URL, but says nothing about the 'detail' parameter (which likely controls description granularity). This leaves a significant gap for the agent.

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: 'describe any image from URL'. Clearly distinguishes from siblings like extract or web-scrape. However it doesn't specify the nature of the description (e.g., caption, detailed analysis) leaving the output format ambiguous.

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

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

Implies usage for any image URL but provides no explicit when-to-use or when-not-to-use guidance. No alternative tools named, though none are obvious among the 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?

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true — a rich set. The description adds only the pricing ($0.10 USDC per call), which IS useful behavioral context (cost before invocation). But it discloses nothing about what the 'summary' contains, output shape, latency, or the open-world/network behavior. Pricing alone is thin against a multi-step analysis 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?

A single em-dash-delimited clause that front-loads the bundle scope, enumerates the three operations, and appends pricing. No wasted words.

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

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

No output schema exists, so the description needs to convey what comes back — it says 'classification + field extraction + summary' but never describes the return format or field structure. For a composite analysis tool that costs money per call, the agent lacks enough to know what it will receive.

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

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

Schema description coverage is 0%, but there is only one parameter: 'text'. The description implies the text is the insurance document/content to analyze but never says so explicitly. With a single required param and zero schema coverage, the description should have clarified what 'text' should contain — a minor gap given only one 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 verb+resource ('Full insurance analysis bundle') and enumerates the three sub-operations (classification + field extraction + summary). It's distinguishable from siblings like classify-insurance or extract, which appear to be the decomposed versions of this bundle. Score 4 because it doesn't explicitly name those siblings as alternatives.

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

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

The 'bundle' framing implies a use case (get everything in one call), which is implied usage guidance. But it doesn't state when to prefer this over calling classify-insurance, extract, and summarize separately, nor when it's inappropriate. No explicit when/when-not.

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

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

Annotations already declare non-destructive, idempotent, open-world behavior, so the safety profile is covered. The description adds useful cost context ($0.08 USDC per call) and outlines the output, but says nothing about the internal behavior of scoring or the required lead shape.

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

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

Two sentences, tightly front-loaded with the core action and the pricing/context tag at the end. No wasted words, though the signals list is slightly 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?

The output side (a 0-100 score with signals and next action) is described despite no output schema. However, with a nested required object and 0% schema coverage, the description should define what the lead/context inputs look like, 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 0% and the description only implies a 'lead' input. The 'context' parameter is never mentioned, and the required 'lead' object (additionalProperties: {}) is left totally undefined, so an agent cannot infer what to pass.

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 (score) and resource (inbound leads), plus the output range (0-100) and the signals produced. Clear enough to distinguish, though it does not name or contrast any 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?

'Built for insurance/ad-sales funnels' implies the intended domain, but there is no explicit when-to-use, when-not-to-use, or alternative routing. Usage is only inferred from the domain 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?

Annotations already disclose readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is largely covered. The description adds useful billing behavior ('$0.03 USDC per call'), but does not explain authentication needs, rate limits, or what the returned registration data contains. The added cost context is valuable but leaves notable behavioral 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?

The description is a single front-loaded sentence with no wasted words, and the cost is placed after the core purpose. It is appropriately concise for a simple tool, though its brevity reflects missing information rather than optimal economy.

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, open-world lookup with two undocumented parameters and no output schema, the description is not complete enough. It should explain query format, jurisdiction format, and expected return content. The annotations cover some safety aspects, but the description still leaves critical invocation details unspecified.

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

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

Schema description coverage is 0%, so the description must carry the full burden for both parameters. It only hints at the query subject via 'company registration' and says nothing about the optional 'jurisdiction' parameter or the expected format for either field. This provides minimal meaning beyond the schema's bare parameter names.

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

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

The description names a specific verb ('lookup') and resource ('Legal/regulatory', 'company registration'), making the tool's domain clear. It also distinguishes this tool from all siblings, none of which perform legal or company-registration lookups. It stops short of 5 only because the exact output or scope is not further specified.

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 offers no when-to-use, when-not-to-use, or alternative-tool guidance. It states what the tool is and its cost, but nothing about the conditions under which an agent should select it over the many sibling 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?

The description adds the cost ($0.02 USDC per call), which is genuine behavioral context the annotations do not carry. Beyond that it says nothing about data freshness, source, coverage, or the fact that country is optional and what happens when it is omitted. The annotations themselves (readOnlyHint=false, idempotentHint=true) are unusual for a snapshot-style read tool and are not explained by the 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?

One line, front-loaded with the resource and its contents, then the price. Nothing is padded. The hyphenated fragment style is terse but readable.

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 paid call, an optional undocumented parameter, no output schema, and no annotations explaining cost or data scope, the description is too thin. It should state what happens without `country`, the currency/units of the indicators, and whether the data is live or cached.

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 `country` parameter has no description in either the schema or the tool text. The description never mentions what format country takes (ISO code, name, default/global), so the only parameter the agent must reason about is undocumented.

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 (macro/economic snapshot) and enumerates its contents (GDP, inflation, rates), so an agent can tell it apart from crypto-price, defi-yields, or news-feed. It lacks an explicit verb (get/fetch), but the noun phrase is specific enough to identify the operation.

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, when-not-to-use, or alternative routing is given. The sibling list contains several finance-adjacent tools (crypto-price, defi-yields, news-feed), and the definition never says which one to pick for which question, leaving the agent to infer.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful non-schema context — persistence across runs and a per-call price ($0.005 USDC) — but says nothing about what mutations occur or how concurrent writes behave.

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 packs resource, scope, benefit, and cost with no filler. Slightly dense, 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 four-parameter, 0%-documented mutation tool with no output schema and an unexplained required 'action' parameter, the description is too thin. An agent cannot know valid actions, whether value is needed for reads, or how namespace scoping interacts with wallet scoping.

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 description explains none of the four parameters. Critically, 'action' is a required free-form string with no enum and no documented values, and 'value' is required even for what may be a read action; the description does not compensate for any of this.

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 and scope: 'persistent key-value memory scoped to your wallet', plus the differentiating benefit 'agents remember across runs'. No sibling tool does memory, so differentiation is implicit but the purpose is unambiguous.

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

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

The phrase 'agents remember across runs' hints at when it is useful, but there is no explicit when-to-use, when-not-to-use, or alternative. An agent gets no guidance on choosing this over simply passing state through its own context.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true – implying no persistent mutation, which sits oddly with readOnly=false for a 'real-time feed'. The description adds pricing ($0.005 USDC per call), which is genuinely useful behavioral context not in annotations. It does not explain freshness, rate limits, or response 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?

One front-loaded sentence, zero waste. But it is arguably too terse for what it must convey, so not a 5.

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

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

No output schema and no annotations covering safety or auth, so the description should disclose return shape, freshness, and payment mechanics. It gives only a one-line purpose plus price – inadequate for an open-world paid data 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 0% and the description mentions only 'topic' (presumably query) and implies a count but never defines limit's units, default, or max. With two undocumented params, the description 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 (feed) and resource (news) with topic scoping and pricing. Distinguishes from siblings implicitly since no other news tool exists, but no explicit 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?

No when-to-use, prerequisites, or alternative guidance. An agent must infer from the name and topic parameter alone, with no help on when this beats web-scrape or sentiment.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable cost information ($0.01 USDC per call), which is a behavioral trait not in annotations, but it omits other details like authentication, rate limits, or return structure.

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

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

The description is a single, front-loaded sentence that efficiently conveys the resource, scope, and cost without waste. It could benefit from a clearer verb at the start, but every part earns its place.

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

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

For a tool with two parameters and no output schema, the description is minimal. While annotations cover safety and the description adds cost, the lack of parameter explanation and any detail about the 'decoded' output format leaves significant gaps for an agent to call it correctly.

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

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

Schema description coverage is 0%, and the description provides no information about the two parameters ('address' and 'chain'). It does not explain what an address represents, what chains are supported, or any format constraints, leaving the parameters entirely undocumented.

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

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

The description states a specific resource ('Decoded on-chain events') and scope ('recent transfers'), making it clear what the tool returns. It does not, however, differentiate itself from siblings like wallet-risk or token-safety, though none overlap directly.

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 guidance is given on when to use this tool versus alternatives. The description merely states what it returns and its cost, leaving the agent to infer appropriate contexts without any explicit conditions.

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

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

Annotations provide the safety profile (destructiveHint=false, idempotentHint=true, openWorldHint=true), and the description adds genuinely useful context: a per-call cost of $0.01 USDC. However, it never explains why readOnlyHint=false for what appears to be a data-fetch call, nor describes result shape or latency.

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 resource and cost front-loaded, no filler. Slightly under-specified rather than padded, but efficient for what it contains.

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, no annotations clarifying return content, and 0% parameter coverage. An agent still does not know what a result looks like (market names, prices, volumes?), how 'query' is matched, or what 'limit' bounds. Incomplete for a 2-param tool with a real cost per 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 description coverage is 0% for both parameters. The phrase 'for any topic' loosely implies what 'query' accepts but gives no format or syntax, and 'limit' is completely unexplained in both schema and description. 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?

States the resource precisely (Polymarket prediction market odds/live probabilities) and the source venue, which distinguishes it from generic siblings like market-intel or crypto-price. It reads as a noun phrase rather than a verb+resource, but an agent can still tell what it returns.

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 exclusions, and no mention of alternatives (e.g. market-intel for macro/market questions). The only context given is a price note, which is not usage guidance.

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

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

Annotations already declare idempotency, open-world reach, and non-destructiveness. The description adds genuinely new behavioral context by disclosing a per-call cost ($0.02 USDC), but omits what the call returns and why readOnlyHint is false for what sounds like a lookup.

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

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

A single front-loaded line with the resource, operation, and cost up front; no filler. Appropriate size for the information it does convey.

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 screening tool with no output schema, nothing is said about the result shape (match/no-match, hit counts, list coverage), and the meaning of the optional 'type' parameter is missing. An agent cannot reliably interpret the response or construct a well-formed call beyond the required name.

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 carries the full burden and contributes nothing: it never explains what 'name' should look like (individual vs. organization string) or what valid values 'type' accepts. This leaves both parameters effectively undocumented.

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 concrete operation (sanctions screening / entity check) against specific sources (OFAC/EU), which is unambiguous and clearly distinct from all siblings. It stops short of an explicit 'not for X' contrast, but no sibling overlaps enough to need one.

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 guidance on when to invoke this versus adjacent tools like wallet-risk or threat-intel, no prerequisites, and no indication of what constitutes a screenable entity. The agent must infer context entirely.

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

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

Annotations provide safety hints (readOnlyHint false, openWorldHint true, idempotentHint true, destructiveHint false). Description adds cost per call ($0.02 USDC), which is a useful behavioral trait not in annotations. However, it doesn't explain side effects or auth needs. With annotation coverage, a 3 is appropriate.

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-loads purpose, then features, then cost. No wasted words.

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

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

Given the simple tool, annotations provide safety profile, and schema specifies required parameter. Description covers purpose, output categories, and cost. Missing usage guidelines, but overall complete enough for invocation.

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

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

Schema has one required parameter 'text' with 0% description coverage. The description does not mention the parameter or its format, failing to compensate for the lack of schema documentation. While the parameter name is self-explanatory, the description adds no meaning.

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

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

States a specific verb 'sentiment analysis' and resource, with output categories (positive/negative/neutral) and additional features (emotions, keywords). Does not explicitly differentiate from sibling tools, but the purpose is clear.

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

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

No guidance on when to use this tool versus alternatives like content-safety or classify-insurance. Lacks context or 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?

Annotations cover the safety profile, so the description's job is to add context beyond them — and it does: per-call cost ($0.01 USDC), an input ceiling (20k chars), and a fixed output length (250 words). That price disclosure especially matters for a paid, openWorld tool. It still omits failure/truncation behavior for over-limit input.

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 what the tool does and appends the constraints that affect a call. 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 one-parameter, no-output-schema tool, the description supplies purpose, input bound, output length, and cost — enough to invoke it correctly. Only edge-case behavior (input over 20k chars, empty input, non-English text) is unaddressed.

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 the single 'text' parameter. It does partly by imposing the 20k-char limit, which the schema does not express (no maxLength). It says nothing about language handling or formatting expectations for the input.

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 ('AI text summarization'), plus the output shape ('crisp 250-word summary'). No sibling is similar enough to require differentiation — every sibling tool does an unrelated task — so 4 is appropriate rather than 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?

Usage is implied by the input bound ('any text up to 20k chars') and the price, but there is no explicit statement of when to prefer this tool, when not to use it, or what to do with text exceeding 20k chars. Minimum viable, no exclusions or 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?

The annotations already declare openWorldHint=true, idempotentHint=true and destructiveHint=false, and the description legitimately adds non-annotation behavior: the per-call charge. However, it never explains what a call returns (severity fields? remediation?) despite readOnlyHint=false implying something beyond a pure read, so the disclosure is only 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 fragment with the domain first and the cost last; nothing is padded. It is arguably too terse for a two-parameter paid tool, but there is no wasted text.

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, two undocumented parameters, and no annotations covering return shape, the description should at minimum say what a lookup yields and how the two inputs are used. It gives domain and price only, leaving the agent guessing about input selection and output.

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% for both cve_id and keyword, so the description carries the full burden and only gestures at cve_id via the word 'CVE'. It never explains the keyword path, nor whether cve_id and keyword are mutually exclusive, alternatives, or combinable — key ambiguity since neither is marked required.

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

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

The description names the domain (CVE/threat intelligence) and the action (vulnerability lookup) plus the payload (severity), so an agent knows this is a lookup-by-CVE or keyword tool. It does not differentiate against any sibling, but none of the listed siblings overlaps with vulnerability data, so the ambiguity cost is low.

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 contextual guidance is the price tag ('$0.02 USDC per call'), which tells the agent when to be cost-conscious but not when this tool is the right choice. There is no statement of prerequisites, no exclusions, and no alternative routing for CVE questions.

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

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

The $(0.02) cost per call is genuinely useful context not derivable from annotations. Annotations set readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false; the description neither contradicts nor elaborates on these. No mention of latency, rate limits, or that the check is external and non-cached.

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 capability front-loaded and the cost appended. No filler. Length is appropriate for the scope, though the cost could be a separate clause to improve scanability.

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 0% schema coverage, the description leaves the return shape unexplained. The agent does not know whether the response is a boolean, a risk score, sub-scores per check, or a list of findings. Given a mutation-flagged, open-world, paid tool, more behavioral and return information 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?

Schema description coverage is 0% with two parameters (chain and address). The description provides no information about what chain values are accepted, whether chain defaults, or what address format is expected. This leaves the agent to infer syntax for both parameters.

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

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

States a specific verb+resource ('Token safety check') and enumerates the checks it performs (rug pull risk, honeypot detection, liquidity analysis). It is distinguishable from the closest sibling wallet-risk, though the description does not explicitly name the distinction.

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 and no alternative named. The most relevant sibling, wallet-risk, is not mentioned, so the agent must guess whether to screen an address as a token or a wallet. Only the implied 'call this to check token safety' is present.

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

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

The description adds a concrete behavioral/cost detail missing from annotations: a $0.03 USDC per-call charge, which matters for an agent deciding to invoke. Annotations cover safety (readOnlyHint=false, openWorldHint=true, idempotentHint=true), so the bar is lower, but latency, quality, rate or size limits are absent.

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 clause with purpose and pricing; no wasted words. It is very short, but not padded, so it earns its brevity.

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 translation tool with no output schema, zero parameter documentation, and no annotations explaining cost or auth, the description leaves too much unspecified: parameter formats, input limits, and pricing mechanics for a paid USDC 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 description coverage is 0%, so neither parameter is documented anywhere. The description says 'to any language' but doesn't name the targetLanguage parameter, its format (ISO code? name?), or whether text length is constrained. 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+resource ('Text translation') and scope ('any language'), clearly distinguishing it from siblings like summarize or extract. It does not name an alternative tool, but the purpose 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?

No when-to-use guidance, no mention of when not to use it, and no named alternatives among the many sibling tools. The pricing note is a cost disclosure, not usage guidance.

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

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

Annotations already declare openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is largely covered. The description adds a genuinely useful non-schema detail — the $0.02 USDC per-call cost — but omits return format, latency, or accuracy caveats for a screening result.

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 that wastes no words and puts the resource and scope first. It is terse but every clause carries meaning; the brevity is efficient rather than padded.

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

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

With no output schema and zero parameter documentation, the description should explain what a screening result contains (risk score, flags) and clarify the 'chain' input, but it does neither. For a call that costs money, the omission of what is returned is a real gap.

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

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

Schema description coverage is 0% and there are two parameters. The description says nothing about 'address' or 'chain' (e.g., accepted chain values, format expectations), so it fails to compensate for the empty schema and leaves 'chain' entirely ambiguous.

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 ('Wallet risk screening') and enumerates concrete checks (OFAC sanctions, scam flags, tx patterns). However, it does not distinguish itself from the sibling 'sanctions-screen', which appears to overlap on the OFAC dimension.

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 or when-not-to-use guidance. Given overlapping siblings like 'sanctions-screen', 'token-safety', and 'threat-intel', the agent is left to infer whether this or a sibling should be called for a given screening need.

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

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

Annotations cover the safety profile (destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description need not restate that. It does add one genuinely useful behavioral fact beyond structured data: a per-call cost of $0.005 USDC, which signals this is a paid endpoint. However, it says nothing about rate limits, authentication/wallet requirements for payment, or the odd readOnlyHint=false on what is clearly 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?

A single short sentence with the cost front-loaded alongside the payload description; nothing is wasted. It is terse to the point of under-specification, but no filler is present.

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, no parameter descriptions, and only minimal annotations, the description leaves key agent-facing questions unanswered: location format, days semantics/defaults, response shape, units, and payment/auth mechanics. For a two-parameter paid tool, this is thin.

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 two parameters (location, days) are documented nowhere. The description mentions 'forecast' and 'current conditions' but never explains the format or expected values of location (city name, coordinates, postcode?) or the meaning and valid range of days. It does not 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 names the resource (weather data) and the two payloads it returns (current conditions and forecast), which is more than the title alone conveys. The opening 'Weather data' restates the name, and there is no verb, but the domain is unambiguous and no sibling tool covers weather, so distinctness is not an issue.

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 tool versus any alternative, no prerequisites, and no note about which parameter selects current conditions versus forecast. Usage must be entirely inferred from the field names.

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

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

Annotations already cover safety profile (openWorldHint=true, idempotentHint=true, destructiveHint=false). The description adds genuinely useful context the annotations lack: the $0.01 USDC per-call cost, which matters for an agent's tool selection. However it omits auth requirements, rate limits, and return/pagination behavior. Note the mild tension where a text-extraction tool carries readOnlyHint=false, presumably due to the payment side effect, but the description never claims read-only so this is not a contradiction.

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; the value proposition and price are packed efficiently. Adequately sized, though the price parenthetical slightly crowds the purpose statement.

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

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

No output schema exists, so the description should say more about what is returned (plain text? markdown? truncated?). It covers cost but leaves the return format and the 'max_chars' parameter unexplained, which is a real gap for an agent deciding how to call it.

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

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

Schema description coverage is 0% and there are 2 parameters. 'url' is self-explanatory, but 'max_chars' has no meaning anywhere — the description does nothing to explain its purpose, default, or truncation behavior, 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+resource: 'Extract clean text from any URL'. The agent can immediately tell this fetches and cleans page content. It doesn't differentiate from any sibling (e.g. 'extract'), but no sibling actually overlaps with web scraping, so the gap is minor.

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?

'agents read web pages' implies the usage context (fetching page content) but gives no when-to-use vs when-not guidance and names no alternatives. Usage is only inferable, not stated.

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

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

Annotations cover read/idempotency/open-world traits, and the description adds genuinely new behavioral context the annotations cannot convey: the $0.01 USDC per-call cost, which is critical for an agent deciding whether to invoke it. It does not describe latency, result freshness, or pagination behavior, so it misses the top score.

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 verb, scope, and return fields with no filler. The pricing parenthetical is informative but slightly tacked on, keeping it just short of ideal structure.

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

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

For a 2-parameter, no-output-schema tool the description is nearly adequate: it explains what comes back and what it costs. However, with 0% schema coverage it should have clarified max_results semantics, and it offers no routing guidance among the many similarly named 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 0% for both parameters. The description hints that a free-form query is accepted but says nothing about max_results — its default, allowed range, or effect on cost — leaving a required parameter's sibling wholly undocumented.

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 (search) and resource (web) and even names the return payload (title, url, snippet), so the agent knows exactly what it gets back. It does not explicitly differentiate itself from close siblings like web-scrape or deep-research, which keeps it out of the top tier.

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?

"for any query" implies a general-purpose lookup applicable whenever a search is needed, but there is no statement of when to prefer this over web-scrape or deep-research, nor any prerequisites or exclusions. Usage is only implied, not guided.

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