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?

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?

Goes well beyond the annotations: it discloses a concrete 0.2 USDC real-money charge on Base via x402, that spending limits are enforced, that allow_repeat silently returns a prior result without charging, and that max_price_usdc can refuse the purchase. These are exactly the cost/auth side effects an agent needs before firing a non-readonly, non-idempotent 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?

Dense but front-loaded: purpose, then cost/payment, then input constraints, then output. Every clause carries information (cost, formats, size caps, exclusivity) and there is 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 still specifies the return (image/png as a download link, plus a file when save_to is used) and covers payment, constraints, and dedupe behavior. An agent has everything needed to call this safely 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 adds a constraint the schema does not encode: 'Give exactly one of image_url or image_path' (the schema shows zero required params and no oneOf). That mutual-exclusivity rule and the PNG/link vs save_to output distinction are genuine added meaning.

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

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

States a specific verb and resource ('Removes the background from one photo') plus the exact result ('subject on a transparent background as a PNG, at the photo's own size'). It is trivially distinguishable from siblings like optimize_image or image_palette, which transform rather than cut out subjects.

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 operating context: cost per call, that payment is checked against spending limits, and that exactly one of image_url or image_path must be supplied. It does not, however, name an alternative tool or an explicit 'don't use this when...' condition.

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.