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

Beyond the annotations it discloses the real cost and payment rail, that scripts on the page do not execute, that robots.txt is respected, that the result is not a conformance certification, and how duplicate requests within 10 minutes are handled. This is exactly the operational context the annotations do not carry.

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 output shape and caveats are front-loaded, then the cost, then the input instruction, so the most decision-relevant facts come first. It is dense rather than padded, though the payment sentence packs several clauses into one line.

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, single-purpose scanner with no output schema, the description covers what is returned, what is not done, and what it costs. The only real gap is the lack of explicit guidance on when another tool (e.g. page_metadata) is the better choice.

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; the description adds meaning on top by constraining url to a single public page on standard ports and confirming the result is JSON. The other parameters (standard, viewport, save_to, overwrite, allow_repeat, max_price_usdc) are left entirely to the schema.

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

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

The description names a specific verb and resource: an automated WCAG check of one public web page, with the engine (axe-core) and the JSON contents spelled out. It is unmistakably different from every sibling in the list, though it never names a sibling to route against.

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 states the input constraint (one public web page, http or https, standard ports) and the payment prerequisite (0.05 USDC on Base via x402 after spending limits are checked). It also sets expectations with 'not a certification of WCAG or ADA conformance', but gives no explicit when-to-use-vs-alternative routing.

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

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

Discloses behavior the annotations cannot: a real 0.03 USDC charge per call on Base, paid via x402 from the buyer's wallet only after spending limits are checked, plus the repeat-purchase caching rule (allow_repeat=false returns the earlier result and charges nothing). It also states no JS execution and robots.txt compliance. Nothing here conflicts with readOnlyHint=false / destructiveHint=false / idempotentHint=false.

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 what the tool returns, then cost/safety behavior, then the single required input, then output placement. Dense but every sentence carries information; the only slight redundancy is restating that the result is JSON in both the first and last sentence.

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 spells out the return shape, and it covers pricing, caching and input eligibility. It stops short of failure behavior an agent would want — what happens when the page is unreachable, not HTML, or the wallet/price check fails, and how max_price_usdc and the save_to/overwrite options interact with a paid call.

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

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

Schema coverage is 100%, so the schema already documents all five parameters and the baseline would be 3. The description adds value beyond it by pinning the url contract (public page, http or https, standard ports) and by explaining the practical consequence of allow_repeat in money terms, which the schema only states mechanically.

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

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

Names a specific verb and resource (reads one public web page, returns the brand it publishes about itself) and enumerates the exact return fields: name, description, logo image URLs, colours, fonts, social profiles. That is enough to separate it from siblings like image_palette (which extracts colours from an image) or quote (which prices a call).

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

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

Gives concrete applicability conditions: the target must be a public page over http/https on standard ports, no JavaScript is executed, and robots.txt is respected. It never names an alternative sibling tool or states a when-not, but the input constraints effectively communicate where the tool will and won't work.

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?

Adds substantial context beyond the annotations: a fixed 0.01 USDC real-money charge on Base, the x402 payment path, that spending limits are checked before charging, accepted formats and size/pixel caps, and the 10-minute dedup behavior that returns a prior result without charging. This also explains why readOnlyHint is false for a non-mutating 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?

Front-loaded with the purpose, then cost, then input constraints, then output format. Four dense sentences with no filler; each clause carries a fact the agent 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?

With no output schema, the description still tells the agent what comes back (JSON with hex values, share, neutral flag), how it is delivered (tool result), what the call costs, and the input constraints. Nothing an agent needs to invoke it 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 baseline is 3, but the description adds meaning the schema lacks: the returned colours are the most common first, capped by count, and each carries its share and a neutral flag, which ties the output back to include_neutrals. That is modest but real added value over the schema.

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

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

States a specific verb and resource ('Returns the colours one image is mostly made of'), and the schema/description together make it clearly distinct from sibling image tools like remove_background, optimize_image and brand_from_url. An agent can tell what this tool produces without inspecting anything else.

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 operational constraints ('Give exactly one of image_url or image_path') and discloses cost, but never says when to prefer this tool over siblings or in what scenario it is appropriate. Usage is implied by the description of what it returns rather than explicitly 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?

With no annotations the description carries the full burden, and it does disclose useful behavior: the listing is free, live/current, and reports per-installed-package runnability. It stops short of stating read-only nature or any freshness/pagination caveats, but for a zero-param listing the safety profile is unambiguous and the cost disclosure adds real value.

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

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

A single dense sentence, front-loaded with the verb and resource, with every clause (price, network, output, limits, runnability, free) carrying distinct information. 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?

With no output schema, the description compensates by enumerating the returned fields (price in USDC, network, output, input limits, tool mapping) and the cost. For a simple discovery tool with no inputs, this is sufficient for an agent to call and interpret 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 takes zero parameters and the schema describes none, so there is nothing for the description to clarify. Baseline of 4 applies per the no-parameter rule.

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 (Lists) and resource (Bacon Services catalog) and enumerates exactly what each entry contains: USDC price, network, output, input limits, and runnability. The mention of 'as which tool' implicitly ties entries back to the sibling tools, so an agent can distinguish it from quote or the task-specific siblings.

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 catalog-discovery intent is implied ('Lists what Bacon Services sells... right now'), and 'Free' hints at a cost-free probe, but there is no explicit 'use this before X' or named alternative. The agent must infer that this is the entry point for discovering available services.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true), the description discloses the paid x402 flow, that spending limits are checked before charge, the exact price, that metadata is dropped, that transparency is preserved, and that images are never upscaled. These are material behaviors an agent cannot infer from the schema or 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?

The core operation is front-loaded in the first sentence, followed by cost, constraints, and output. It is dense but every clause carries load; the single run-on paragraph with mixed input/output/cost facts costs it a point on 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 an 8-parameter, no-output-schema tool this covers what an agent needs: accepted formats, size and pixel limits, required parameter exclusivity, output MIME type and delivery mode, and the payment model. Nothing essential 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: the mutual exclusivity constraint 'give exactly one of image_url or image_path', the never-enlarge semantics of max_width, and the download-link/save_to output pairing. It does not clarify quality or max_price_usdc behavior beyond what the schema already says.

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 first sentence states a precise verb, resource and transformation: resize so the longest side is at most max_width (never enlarging) and re-encode as WebP at the given quality. This is clearly distinguishable from siblings like remove_background, brand_from_url, and image_palette, which perform different image operations.

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 strong context for deciding to call it: real-money cost of 0.01 USDC, accepted input formats and size limits, and the exactly-one-of image_url/image_path rule. It never names an alternative tool or an explicit 'do not use this when' condition, so it stops short of full routing guidance.

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

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

Strong on economics and mechanics: real-money cost, x402 payment on Base, spending-limit check before charging, and the 10-minute dedupe that returns the earlier result for free (echoed in the schema). It does not explain what happens on failure (refund, partial charge) or how save_to interacts with the paid call, which matters for an irreversible spend; the readOnlyHint=false annotation already signals side effects, so a 3 fits.

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 purpose and output shape, then constraints, then cost, then a short usage instruction. The closing "Output: JSON, returned in the tool result" restates what the first sentence already said, a small redundancy in an otherwise tight block.

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?

Since there is no output schema, the description carries the return-shape burden and does so with a field inventory. Missing edge is failure/refund behavior and how save_to/overwrite interact with the charged call, which an agent needs for safe invocation of a paid 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 100%, so all five parameters are already documented, and the description mostly repeats that. It does add one real constraint the schema lacks — standard ports and http/https scheme for url — plus the spending context for max_price_usdc, but not enough to lift it above the baseline.

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

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

States a concrete verb and resource ("Reads one public web page and returns what it tells search engines and link previews") and enumerates the returned fields (title/description lengths, canonical, redirects, robots rules, OG/Twitter cards, headings, JSON-LD types, SEO issues). That output inventory makes it clearly distinct from siblings like accessibility_check, brand_from_url and image_palette.

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 usable preconditions: one public page, http or https, standard ports, no JavaScript execution, robots.txt respected, and 0.01 USDC per call. It never explicitly names a sibling to use instead (e.g. accessibility_check for audits or brand_from_url for branding), so routing guidance 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.

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

With no annotations, the description carries the burden and does well: it discloses that it is free, that nothing is signed, and that it reports whether spending limits and wallet allow the call — real behavioral value beyond a bare 'quote'. It doesn't cover return format, but that is minor for a preview tool.

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

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

Two short sentences, front-loaded with the verb and resource, then the key behavioral guarantees. Nothing wasted.

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

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

For a single-param preview tool with no output schema or annotations, the description supplies the essential safety and eligibility context. Return-value detail is missing but not critical.

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; the description adds that a 'service' is the target of the quote and ties it to the pricing check, reinforcing the schema's examples. No extra syntax detail, so not a 5.

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?

'Gets Bacon's current price for one service' names a specific verb and resource, and distinguishes it from siblings like wallet_status and remove_background by being explicitly a price query.

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?

'without paying' and 'Free; nothing is signed' clarify the safe read context and implicitly distinguish it from the actual paid execution sibling tools. It doesn't name an alternative explicitly, but the when-to-use context 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 only flag a non-idempotent open-world write; the description goes well beyond them by disclosing real monetary cost (0.05 USDC per call on Base), the x402 payment flow, and that spending limits are checked before charging. Combined with the explicit input limits (8 MB, 4096 px) and output format, an agent can predict cost and failure modes 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?

Front-loaded with purpose, then cost, then constraints, then output — a sensible order with little waste. It is dense and slightly run-on in the input-limits clause, but nearly every sentence 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?

For a 6-parameter tool with no output schema, the description covers purpose, cost, input constraints, mutual exclusivity, and return shape (download link plus optional save_to file). It omits only error/max_price behavior, which is a minor gap given the schema documents those parameters directly.

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 would be 3, but the description adds a cross-parameter constraint the schema cannot express: exactly one of image_url or image_path must be supplied. That constraint is meaningful and not repeated anywhere in 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 and resource (removes the background from a photo) plus the exact output contract: subject on a transparent PNG at the photo's own size. That is distinguishable from every sibling (optimize_image, vectorize_image, image_palette), which transform differently and produce different artifacts.

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 selection rules: 'Give exactly one of image_url or image_path' and accepted formats/size limits, which tells the agent when the tool is applicable. It does not explicitly route away from alternatives (e.g. optimize_image for compression) or state when not to call it, so it stops 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?

With annotations only covering safety hints, the description carries real weight: it discloses a 0.05 USDC charge on Base via x402, spending-limit checks, output dimension capping at 4096, and the 10-minute repeat-purchase short-circuit. These are exactly the non-obvious side effects an agent needs before invoking a paid, non-idempotent 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?

Front-loaded with the core action and use case, followed by a compact input/output block — nearly every sentence carries new information. It is dense and slightly long, but nothing is redundant enough to cut.

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 names the return type (image/svg+xml), the delivery form (download link plus optional saved file), and the payment/size constraints. An agent can decide, pay, and handle the result without further discovery.

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; the description adds the mutual-exclusion constraint ('Give exactly one of image_url or image_path') and input limits (8 MB, 8000 px) that the schema does not encode. That is genuine value beyond the per-parameter descriptions.

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 ('Traces ... image into an SVG of filled paths') plus scope (colour count, format). It is clearly distinct from siblings like remove_background, optimize_image and image_palette, which do different transformations on the same input types.

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

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

Gives an explicit fit statement — 'Best for logos, icons and flat artwork; a photo comes back as a stylised poster' — which tells the agent when the tool is appropriate and what quality to expect otherwise. It does not name which sibling to use instead for non-vector needs (e.g. optimize_image), 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?

No annotations are provided, so the description carries the full burden. It usefully discloses cost (free) and a non-obvious conditional behavior (balance hidden unless BACON_DISCLOSE_BALANCE is enabled), which explains a potentially confusing omission, but it says nothing about auth requirements, error behavior, or explicitly confirming it is a read-only 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?

Three dense sentences, each carrying distinct information (reported fields, cost, conditional balance disclosure), with the most decision-relevant content front-loaded. 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?

With no output schema and no annotations, the description does the job of enumerating the returned signals, so an agent knows what to expect. It stops short of covering failure modes or permission requirements for a tool whose results depend on configuration state.

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 optional parameter with 100% schema description coverage, so the schema already documents the 'service' filter. The description adds only mild context by implying that omitting it checks affordability across all services; no format or syntax detail is added.

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

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

The description names a concrete verb-and-resource (shows wallet status) and enumerates exactly what is reported: payment network, configuration state, spending limits and remaining amounts, and per-service affordability. Siblings (quote, list_services, image tools) are unrelated domains, so no differentiation is needed and none is missing.

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

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

It implies a pre-flight use case by reporting whether the wallet can afford each service, and 'Free' tells the agent this check costs nothing, but it never states when to call this versus the sibling 'quote', nor any prerequisites. Usage is inferable rather than stated.

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