QuickBuild agent tools (x402)

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

Goes well beyond the annotations: discloses the x402 pricing model ($0.001 USDC per call), that errors are never charged, the data source (public Base RPC), the oracle used for USD conversion (Chainlink ETH/USD on Base), the 4 s cache, and even the composition of the cost estimate (L2 execution + OP Stack L1 data-fee upper bound). This is exactly the operational context an agent needs before paying for a call.

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

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

Front-loaded with the two things that most affect an agent's decision: the price and that errors are free. The remainder is one long enumerative sentence listing returned fields; it is dense but nearly every clause maps to a concrete output, so little is wasted.

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

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

With no output schema, the description carries the full burden of describing return values and does so comprehensively, field group by field group. Combined with the pricing, caching and read-only annotation context, an agent has everything needed to call this 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 takes zero parameters, which is the baseline-4 case. The description confirms this explicitly ('No params'), so nothing is left ambiguous, though there are no parameters whose meaning could be enriched further.

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 ('Live gas snapshot for Base mainnet (chain 8453)') and enumerates exactly what is returned: block number/time/utilization, base fee, eth_gasPrice, priority fee, fee history, percentile-based slow/standard/fast suggestions, and transfer/swap cost estimates. That level of specificity distinguishes it from siblings like base_token_info or base_tx_status without opening any 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?

Usage is implied by the content (gas estimation for ETH transfers, ERC-20 transfers and swaps on Base mainnet chain 8453), and 'No params' plus the 4 s cache tell the agent it can call it blindly and repeatedly. However, there is no explicit when-to-use/when-not guidance and no routing to or from sibling tools, so an agent must infer the 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 cover read-only/idempotent/non-destructive, but the description adds substantial undisclosed-by-annotation behavior: per-call x402 pricing ($0.002 USDC), that errors are free, 1-hour metadata caching, live reads from public Base RPC, invalid input returning 400 without charge, and a spoofed-symbol guard. This is exactly the behavioral context an agent needs before invoking.

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

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

The pricing/scoping note is front-loaded and each clause carries information (proxy standards, bytes32 symbols, caching, error handling). It is dense and long for a single paragraph, but essentially every sentence earns its place, leaving only minor trimming opportunity.

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 must convey return values, and it does so thoroughly (contract-vs-EOA, bytecode size, metadata, proxy impl, well-known flag, balance). Payment, caching, defaults, and error semantics are all covered, leaving nothing an agent needs missing.

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

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

Schema coverage is 100%, so the schema already documents both params and their defaults. The description reiterates that all params are optional and default to USDC, which is helpful but largely redundant with the schema; it adds little new per-parameter meaning beyond what is already structured. 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 (Inspect) and resource (token or any address on Base mainnet), then enumerates exactly what is returned: contract vs EOA, bytecode size, ERC-20 metadata, proxy implementation, well-known-token status, and optional holder balance. This is precise enough to distinguish it from siblings like base_wallet_balances and base_tx_status.

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

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

Gives clear context for when to reach for it (inspecting any Base address, contract or EOA, defaulting to USDC) and notes the pricing/error conditions that govern use. It stops short of explicitly naming alternatives or stating when NOT to use it, so it falls short of a 5.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing pricing ($0.002 USDC via x402), that errors are free and unknown/invalid hashes are never charged, the specific 404/400 error semantics, and that data is read live from a public Base RPC. These are operationally critical traits an agent cannot infer from annotations or schema.

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

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

Front-loads the pricing/error bracket, then the purpose, then the return fields, then the defaults and error codes — well ordered with no filler. It is dense and reads as a long run-on, so slightly below ideal, but each clause carries distinct information.

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

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

With no output schema, the description compensates by enumerating the return fields (status values, fee split, decoded ERC-20 events capped at 20) and covers error behavior and the default request. An agent has everything needed to call it correctly and interpret results.

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

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

Schema coverage is 100%, so the hash format is documented, but the description adds meaning the schema lacks by explaining that the default value is a confirmed USDC x402 payment (the schema only shows the raw hex). That clarifies why the parameter can be omitted and what result to expect.

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 ('Look up one transaction on Base mainnet by hash') and enumerates exactly what is returned (status, block, confirmations, fee split, decoded Transfer events). This clearly distinguishes it from siblings like base_gas_price or base_wallet_balances, which cover different resources.

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

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

Gives clear context ('Useful to confirm a payment landed') and notes the notable default behavior (all params optional; defaults to a confirmed USDC x402 payment). It stops short of stating explicit when-not-to-use or naming an alternative sibling, but the usage context is unambiguous.

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 readOnly/openWorld/destructive, and the description adds substantial context beyond them: per-call x402 pricing ($0.002 USDC), errors are free, invalid input returns 400 and is never charged, data is read live via Multicall3 and cached 10 s. This is rich behavioral disclosure an agent needs before paying.

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

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

Dense but front-loaded: pricing/error terms lead, then scope, then data source and failure mode. Every sentence carries information, though the single paragraph is somewhat packed.

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, yet the description fully enumerates the return contents (balances, nonce, account type, USD total) plus the data source, cache window, default address, and error semantics. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so all three params are already documented. The description restates that `tokens` are read on-chain (symbol/name/decimals) and that includeZero lists zero-balance tokens, adding only marginal value over the schema. Baseline 3 applies.

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

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

States a specific verb+resource (fetch balances of one address on Base mainnet) and enumerates exactly what is returned: native ETH, named tokens, up to 10 extra ERC-20s, nonce, account type, USD total. It is clearly distinguishable from siblings like base_token_info (token metadata) and base_gas_price.

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?

Explains when to use includeZero=true (list zero-balance well-known tokens) and the `tokens` param (up to 10 extras), plus that all params are optional with a default address. Lacks explicit routing against alternatives, but the context for invoking it correctly is clear.

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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint. The description adds meaningful context: free tier, rate limit, exact scope (homepage meta/OG/canonical, security headers, HTTPS, up to 20 broken-link checks), and routes to the paid alternative. It does not describe return format or error behavior, but the annotations carry the safety profile.

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

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

Front-loads the free/rate-limit signal, then the purpose, then the paid alternative. Two compact sentences with 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 must convey what the tool returns; it lists the checked areas (meta/OG/canonical, security headers, HTTPS, link breakage). It stops short of describing return structure or failure modes, but this is sufficient for a simple one-parameter check tool.

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

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

Schema description coverage is 100% and the single url parameter is fully documented in the schema. The description adds no syntax or format details beyond what the schema provides, so baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb ('check') and resource ('one public website'), enumerates the exact checks performed, and explicitly names the sibling website_audit as the deeper paid alternative. An agent can distinguish it from 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?

Explicitly states the free rate limit (10 calls/hour per IP) and directs deeper 3-page audits with leaked-key scanning to website_audit (paid). It gives both the condition for using this tool and the alternative when that condition is not met.

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?

Goes well beyond the annotations (readOnlyHint/openWorldHint/idempotentHint/destructiveHint) by disclosing the paid x402/Base pricing model, that failed content-policy calls are not charged, expected latency (2-5 s), the HTTP 400 failure mode, the full content policy, and the two possible response encodings. This is exactly the behavioral context an agent needs before spending money.

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

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

Dense but front-loaded: pricing, purpose, output shape, policy, and defaults each arrive in a logical order, and every clause carries usable information. It is a single long block rather than a run-on sentence, but the semicolon-chained style is slightly heavier than necessary.

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

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

With no output schema, the description correctly carries the return contract itself (JSON with image_base64 + mimeType, or raw bytes with format=jpeg), plus cost, latency, and policy failure behavior. An agent has everything needed to decide, call, and interpret the result.

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

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

Schema description coverage is already 100%, so the schema carries the parameter burden and 3 is the baseline. The description mostly restates schema defaults ('all params optional', the no-prompt lighthouse fallback) rather than adding new syntax or format detail. It does reference a 'format=jpeg' switch that does not exist in the input schema, which is extra information but also a mild inconsistency an agent could trip on.

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 (generate an image from a text prompt), names the model and resolution (FLUX.1 [schnell], 1024x1024), and describes the output shape. No sibling tool does image generation, so there is nothing to confuse it with, and the closest neighbor (text_to_speech) is clearly distinct.

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 makes the trigger condition explicit (a text prompt, optional) and clarifies the degenerate case ('with no prompt a sample watercolor lighthouse is drawn'). It also states cost and content-policy gating, which affect whether to call it. It stops short of naming alternatives, but no competing image-generation sibling exists to route away from.

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

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

With readOnlyHint/openWorldHint already covering safety, the description adds substantial non-schema context: $0.003 USDC per call via x402, errors never charged, a 503 'capacity' response when the daily budget is exhausted, a Llama Guard 3 safety check, and concrete caps (512 max_tokens, 24000 input chars). These are behavioral traits an agent cannot infer from annotations alone.

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 paragraph that front-loads the paid-call caveat before the functional summary, and every clause carries information (return shape, model list, limits, failure mode). It is long but not padded, with only mild redundancy around the free-errors notice.

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

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

No output schema exists, but the description explicitly documents the return shape {text, model, finish_reason, usage}, the input/output limits, the safety gate, and the 503 failure path. An agent has everything needed to call it correctly and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by clarifying the relationship between prompt, system, and messages (OpenAI-style history) and by enumerating the model aliases and the 512 token cap. It adds meaningful routing semantics over the structured fields.

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

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

States a specific verb+resource ('One-shot LLM completion on Cloudflare Workers AI') and names the default model plus the full model roster. It is clearly distinguishable from siblings like summarize, translate, generate_image, and text_to_speech by being a general-purpose completion endpoint.

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?

Explains both invocation styles (prompt/system vs OpenAI-style messages) and gives the condition for the OpenAI wire format via POST /v1/chat/completions, plus the note that calling with no params returns a sample answer. It stops short of explicitly contrasting when to prefer this over summarize/translate siblings, so no exclusions are drawn.

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 readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: per-call pricing (x402 USDC on Base), that errors are free, and a link-count cap of up to 100 each. It does not describe pagination or response shape, keeping it out of 5 territory.

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

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

Front-loads the cost signal, then the returned fields, then use cases. Dense but every clause is informative; the long field enumeration is justified because there is no output schema, though it is slightly list-heavy.

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 enumerates the return payload well and covers cost, error behavior, and the private-address refusal lives in the schema. Remaining gaps (pagination of the 100-link cap, rate limits) are minor.

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?

Only one parameter and schema coverage is 100%, so the schema already documents the URL, its public http(s)/hostname restriction, and the default. The description adds no syntax or format detail beyond the schema, so the baseline 3 holds.

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

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

Specific verb (Fetch) plus resource (one public web page) plus an enumerated return payload (title, meta description, canonical, OG/Twitter tags, favicon, feeds, JSON-LD, links). An agent can tell it apart from url_to_markdown, screenshot_url, and website_audit without opening any schema.

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

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

The tail sentence names concrete use cases (link previews, unfurling, quick site triage), giving clear when-to-use context. It stops short of naming alternatives or exclusions (e.g., versus website_audit or url_to_markdown), so it is not a full 5.

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 (readOnly, idempotent, non-destructive), but the description adds substantial behavioral detail beyond them: cost per call, free errors, model-specific scoring behavior, the 100-document and 4000-character limits, default model mapping, and all-params-optional sample ranking. This is far richer than the annotations alone.

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

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

It is dense and front-loads pricing and API shape before model details, with no filler sentences. Minor repetition ('errors are free' / 'Errors are never charged') and packed parentheticals keep it from a 5, but every clause carries real information.

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

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

There is no output schema, so the description supplies the return shape itself ({results: [{index, relevance_score, document?}]}). Combined with pricing, model limits, truncation behavior, and optional-parameter behavior, an agent has everything needed to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: bge-reranker-base scores 0..1 for English/Chinese, bge-m3 is multilingual, unknown model names map to the default, and documents are scored only on their first 4000 characters. These details help an agent choose parameters correctly.

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 exact operation (rerank documents for a query) and the specific mechanism (Cohere/Jina-style POST returning ranked relevance scores). It is immediately distinguishable from sibling tools like text_embeddings or llm_chat, so an agent knows this is a scoring/ranking endpoint, not generation or embedding.

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 explicitly says to use it 'after vector search to pick the best passages for an LLM,' which gives clear context for when this tool belongs in a pipeline. It does not state when not to use it or name alternative tools, but the usage context is unambiguous.

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 the safety profile (readOnly, openWorld, idempotent, non-destructive), and the description still adds a lot on top: per-call pricing with free errors, real JS execution with network-idle waiting, a 2-6s typical / ~25s busy latency range, an 8000px full-page cap, and DNS-based domain refusals. That is exactly the extra behavioral context this dimension rewards.

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?

Information-dense with essentially zero filler, and the operational facts (defaults, timing, output shape, refusals) arrive early. Leading with the $0.008 price is arguably the least useful first token for tool selection, but every sentence otherwise 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 carries the return contract itself: JSON containing image_base64 plus finalUrl/status/title, or raw bytes. Combined with latency expectations, size caps, and refusal behavior, an agent has everything needed to call this correctly on the first try.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, its range, and its default; the description largely restates defaults (1280x800 viewport, PNG/JPEG, dark mode, extra wait) and the example.com fallback. It also refers to a 'format=png|jpeg' selector, but the actual parameter is named 'type', a naming mismatch that could mislead an agent. Baseline 3 is appropriate for a fully documented schema.

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

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

The description gives a specific verb and resource (render a public page in headless Chrome and return a screenshot) plus the exact output artifacts (PNG/JPEG, viewport or full page). It is trivially distinguishable from siblings like page_metadata, url_to_markdown, and website_audit, which extract text rather than pixels.

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 names concrete use cases (visual QA, link previews, archiving, feeding a vision model, checking what a page really shows) and states the refusal boundary (adult/malware domains, private addresses). It never routes the agent to an alternative sibling for text-only needs, so the 'when not to use this' half is missing.

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

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

With readOnly/idempotent/destructive annotations already covering the safety profile, the description adds substantial operational context the annotations do not: per-call pricing with free errors, a 24,000-char analyzed limit, 2 MB HTML cap, 10 s fetch timeout, refusal of private addresses, and grounding guarantees ('no invented facts'). This is exactly the behavioral detail an agent needs before incurring cost.

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

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

Front-loads the critical cost signal and the core action in the first two clauses; every sentence carries information. It is a dense single paragraph with heavy parentheticals, slightly harder to scan than it could be, but not 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?

No output schema exists, and the description compensates by enumerating the JSON brief's fields (title, language, contentType, summary, keyPoints, entities, tags, facts, sentiment, audience) plus size/time limits. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents url/lang/text/focus/length/maxPoints boundaries and defaults. The description largely reinforces these (all optional, default URL, POST for long text) rather than adding new per-parameter meaning, so the baseline 3 applies.

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

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

States a specific verb and resource ('fetch a public web page or take raw text and return a structured JSON brief') and enumerates the exact output fields, which cleanly separates it from siblings like url_to_markdown, page_metadata, and website_audit. An agent can identify this as the LLM-backed structured-summary tool 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?

Gives clear operating context: all params optional, no-param default is https://example.com, and POST is preferred for long text. It does not explicitly name alternative tools (e.g., when to prefer url_to_markdown or page_metadata over this) nor state exclusion conditions, so routing among siblings is left to inference.

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

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

Annotations only cover the read-only/idempotent safety profile, and the description adds substantial context beyond that: per-call pricing ($0.001 USDC via x402 on Base), that errors are never charged, hard input limits (100 inputs, 8000 chars each, 60000 total), and that the GET form with no params embeds a sample sentence. This is exactly the operational detail an agent needs before invoking a paid endpoint.

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

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

Pricing is front-loaded in brackets, followed by the request/response shape, then models, limits, and use cases in a logical order. It is dense and long, but every clause carries information; the model enumeration is the only part that could be tightened.

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 compensates by spelling out the response object ({object: "list", data: [{embedding, index}], model, usage}). Combined with the documented limits, pricing, and model aliasing, an agent has everything needed to call and interpret results correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: `dimensions` 'truncates and re-normalizes' (more precise than the schema's wording) and any unrecognized model name silently maps to bge-m3 with the actual model reported in the response. The model-alias fallback is behavior no schema field conveys.

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 ('Drop-in OpenAI Embeddings endpoint') with the exact request/response contract, immediately distinguishing it from siblings like rerank_documents and llm_chat. An agent can tell what it produces (vectors) and in what format 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?

Names concrete use cases ('For RAG, semantic search, clustering and dedupe') and clarifies the default behavior when no params are given, so the agent knows when this is the right tool. It stops short of explicitly routing between this and rerank_documents or llm_chat, so no when-not/alternative 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 cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial non-derivable behavior: per-call pricing of $0.005 USDC via x402 on Base, free errors, the content-refusal policy with HTTP 400 and no charge, the 2000-char limit, and the default no-param sample behavior.

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

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

Dense but front-loaded: pricing and the core transform lead, then output formats, use cases, refusal policy and defaults. Every sentence carries information, though the parenthetical-heavy phrasing makes it slightly harder to scan than it could be.

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

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

There is no output schema, and the description compensates fully by specifying the return shape (JSON with audio_base64 + mimeType audio/wav, 44.1 kHz mono) or raw bytes with format=wav. Pricing, refusal behavior, defaults and transport are all covered, so an agent can call this correctly without further 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 100%, so baseline is 3, but the description adds real meaning: the 2000-char cap, the fact that both params are optional and default to a short English sample, and the GET-query-params vs POST-JSON-body invocation styles. It also references a 'format=wav' option that does not appear in the schema, a small inconsistency.

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 ('Turn text ... into spoken audio'), names the engine (MeloTTS on Cloudflare Workers AI) and the six supported languages. No sibling tool does text-to-speech, so the purpose is unambiguous at a glance.

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

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

Gives concrete use cases (voice replies, narration, accessibility, language practice) which tell the agent when this tool fits. It does not state when NOT to use it or point at an alternative, but no sibling overlaps, so the omission is minor.

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 a lot beyond the annotations: per-call cost ($0.005 USDC via x402 on Base, errors free), the underlying model and fallback, Markdown-preserving block translation, auto-detection with `from` override, and a 20,000-char cap (default 8,000). Annotations already cover the safety profile, and the description adds pricing, model, and limit context on top.

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

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

Front-loads the critical payment constraint before the functional description, which is the right priority. The long language list is bulky but earns its place since the schema exposes no enum; otherwise the prose is dense and waste-free.

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 should ideally state the return shape; it only implies it via 'translated in blocks, preserving Markdown formatting, URLs and code blocks.' Everything else an agent needs — cost, inputs, limits, languages, defaults — is covered.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the enumerated list of supported target languages (filling the gap left by zero enums in the schema), the auto-detect default for `from`, and the char limit semantics. It goes beyond restating what the schema documents.

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

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

States a specific verb+resource ('LLM translation (Meta Llama 4 Scout on Workers AI, M2M100 fallback)') and clarifies the two input modes (text vs. url main-content extraction). An agent can distinguish it from siblings like llm_chat, summarize, and url_to_markdown from the description alone.

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

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

Clearly explains the conditions selecting each input mode: give `text`, or a `url` whose main content is extracted, and notes that with no params it translates a short Spanish sample. It does not explicitly name alternatives (e.g., when to prefer llm_chat or url_to_markdown), so it falls short of a 5.

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 (readOnly, idempotent, openWorld, non-destructive), and the description adds substantial context beyond them: cost model ($0.005 USDC per call via x402 on Base, errors free), fetch limits (2 MB HTML, 10 s timeout), address restrictions, and exactly what is stripped/rewritten (scripts/nav/footer removed, links made absolute).

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 paragraph where every clause carries information: pricing, action, output format, limits, and the optional parameter. The pricing note leads, which is defensible for a paid tool, though it delays the core purpose by one clause.

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 must describe returns, and it does: main content as Markdown with absolute links, plus title and length. Combined with fetch limits, cost, and parameter defaults, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, and the description's maxChars detail (default 50000, max 200000) largely restates it. The non-parameter limits it mentions (2 MB HTML, 10 s timeout) add behavioral rather than parameter meaning, so the baseline 3 is appropriate.

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

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

States a specific verb+resource: 'Fetch one public web page and return its main content ... as clean Markdown with absolute links, plus title and length.' The output shape (main content extraction vs. raw HTML vs. metadata) implicitly distinguishes it from siblings like page_metadata and screenshot_url, but no sibling is named explicitly.

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

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

Gives real constraints on when it applies (one public page, hostname not IP, private/reserved addresses refused, 2 MB / 10 s limits), which implies the use case. However, it never states when to prefer this over page_metadata, website_audit, or summarize, nor any exclusions.

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

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

The description adds genuinely non-schema behavior: a $0.05 USDC x402 charge, errors being free, and hard caps of 3 pages and 30 links. It also notes that leaked secrets are masked in output, which is valuable disclosure. 'Read-only' merely restates annotations, and it doesn't explain output shape, but with annotations already covering safety, this is above the bar.

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 compact parts — a bracketed pricing/error preamble, then a single dense sentence enumerating checks and limits. Nothing is repeated and the cost, which drives agent selection, is front-loaded.

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 the audit returns (pass/fail structure, score, per-check results), and it is silent on that. It also omits the free_site_check relationship and any timing expectations. Limits and pricing are well covered, but the tool is only partially self-sufficient.

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

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

Schema coverage is 100%: the single url parameter already documents the http(s)-only, non-IP, private-address-refused constraint and the example.com default. The description contributes no additional parameter-level detail (e.g., whether the 3-page limit is configurable), so the baseline 3 applies.

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

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

The description names a specific verb-resource pair ('pre-launch website audit') and enumerates exactly what is checked: crawl depth, link count, meta/OG/canonical, headers, HTTPS, 404s, sitemap, and masked secret scanning. This is far more specific than the title alone. It does not, however, distinguish itself from the free_site_check sibling, which appears to overlap in scope.

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 'pre-launch' and by the disclosed cost and crawl/link limits, so an agent can infer this is the deep, paid version. But there is no explicit when-to-use vs when-not guidance, and the existence of a free_site_check sibling makes the paid/free decision the single most important routing question — and it is left unaddressed.

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