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

Adds substantial context beyond annotations: exact price ($0.04 USDC on Base), expected latency (5-16 s), and the existence of per-payment and per-session caps. This meaningfully complements idempotentHint=false by making clear each call spends real money, though it doesn't say whether a failed or slow call is still charged.

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

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

Four short sentences, front-loaded with purpose followed by cost and latency — the highest-value constraints for a paid tool. No filler.

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

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

For a one-parameter paid tool with no output schema, it covers purpose, price, latency, and spend limits. The gap is the payment mechanics (how authorization happens, whether a wallet must be pre-configured) and what a failed call costs.

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

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

Schema description coverage is 100% and already documents the single `input` parameter with its 1-3000 character bound. The description's 'Pass the question in `input` (max 3000 chars)' largely restates the schema, so baseline 3 applies.

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

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

States a specific verb+resource: 'Ask a question and get an answer,' which is clearly distinct from embed/summarize style siblings. It does not explicitly name those siblings, so the differentiation is implied rather than stated.

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

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

Gives strong decision-relevant context (cost, latency, spend caps) but never states when to choose this over `embed` or `summarize`, nor when not to call it. The agent must infer the boundary from the sibling 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?

The description adds real behavioral context beyond the annotations: monetary cost ($0.01 USDC on Base), that it spends real money, and that a per-payment and per-session cap applies. What it doesn't cover is what happens when a cap is hit or a payment fails, which leaves a meaningful edge case undisclosed for a paid write-flagged 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?

Three short sentences with the purpose and the cost front-loaded ahead of the input note — efficient and easy to scan. The trailing "(max 3000 chars)" partially duplicates the schema's maxLength, which is the only wasted material.

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 tool with annotations covering side-effect profile and with cost/payment constraints spelled out, the description covers what an agent needs to decide and call safely. The notable omission is the shape of the return value (e.g., vector dimensionality), which matters here since there is no output schema.

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

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

Schema description coverage is 100%, so the single `input` parameter is already fully documented with its 1-3000 character bounds. The description restates the 3000-character limit but adds no new semantics, so the baseline 3 applies.

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

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

"Compute a text embedding vector" is a specific verb plus resource that is clearly distinct from summarize, ask, health, and inspect. It doesn't explicitly name what differentiates it from the sibling summarize/ask tools, but the resource noun alone makes the distinction obvious.

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

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

Usage is only implied: an agent infers it should call this when it needs an embedding, and the stated $0.01 price plus spending caps give a decision input about whether the call is worth it. There is no explicit when-to-use versus summarize/ask guidance and no stated preconditions 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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds useful behavioral context beyond annotations: the call is free, requires no key, and surfaces local session spend. It does not discuss rate limits or response shape, but for a health probe the added context is meaningful.

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 three short fragments with no wasted explanation. It conveys cost, auth, the endpoint checked, and the local spend behavior efficiently.

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, annotations covering read-only/open-world behavior, and no output schema, the description supplies enough to invoke it: endpoint, cost, auth, and local spend display. It could clarify exactly what 'local session spend' returns, but that is a minor gap for a simple health/status 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?

There are zero parameters, so the schema imposes no parameter semantics burden; the baseline score of 4 applies. The description does not need to explain 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 concrete action: check GET /health on api.x402ai.dev, plus a secondary output of showing local session spend. The dual purpose is slightly unusual, but an agent can identify the tool as a health/status probe with spend visibility. Sibling differentiation is not critical because embed, summarize, ask, and inspect are unrelated.

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?

Provides some usage context with 'Free' and 'No key needed', implying a low-friction diagnostic call. However, it does not explicitly say when to use this versus inspect or other alternatives, nor does it state exclusions. Usage remains implied rather than clearly guided.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety bar is lower; the description still adds that no signature or payment ever occurs and that the URL is transmitted to api.cdp.coinbase.com, which is genuinely useful disclosure of external data flow. It does not describe the shape of the returned decode/validation 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?

Two tight sentences, with the most decision-relevant fact ('Free, never signs or pays') front-loaded, followed by the mechanism and the data destination. No filler.

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

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

For a two-parameter, read-only probing tool with full schema coverage, the description covers what it does, its cost/safety profile, and where data is sent. The main omission is what the response contains, which matters slightly since no output schema exists.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema, including the GET/POST enum and default. The description adds no semantics about the method parameter or URL constraints, so baseline 3 applies.

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

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

States specific verbs and objects: fetch an https URL unpaid, decode its x402 payment-required header, and validate via Coinbase CDP. The vague name 'inspect' is fully disambiguated, and none of the siblings (embed, summarize, ask, health) overlap with 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?

'Free, never signs or pays' gives clear selection context: use this to probe an x402 endpoint without spending or authenticating. It stops short of explicit when-not guidance (e.g., when to skip inspection and pay directly), but no sibling competes for this job.

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 flag non-read-only, open-world, non-idempotent; the description goes well beyond them by disclosing real-money spend, the payment rail, per-payment and per-session caps, and an expected 5–16 s runtime. These are exactly the operational facts an agent needs before committing to a paid, slow call, and nothing contradicts the annotations.

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

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

Three tight sentences: purpose first, then cost/latency, then the parameter constraint. Every clause carries decision-relevant information and nothing is padded.

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

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

For a one-parameter tool with no output schema, the description covers cost, timing, spend limits, and input bounds — enough to call it safely. It stops short of describing the shape of the returned summary, which matters slightly given there is no output schema.

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

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

Schema coverage is 100% and the single `input` parameter is fully documented in the schema, including the 3000-char bound. The description restates the max length but adds no new semantics, so the baseline applies.

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

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

The opening "Summarize text" states a concrete verb and resource, and the sibling set (embed, ask, health, inspect) makes the intended distinction reasonably obvious. It does not explicitly name an alternative, so differentiation is inferred rather than stated.

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

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

Cost ($0.02 USDC on Base) and latency (5–16 s) give strong signals for deciding whether to call this now, but the description never says when to prefer it over `ask` or `embed`, nor any preconditions. Usage is implied rather than stated.

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