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

Annotations already declare the safe read-only/idempotent profile, and the description adds substantial non-schema behavior: strict validation that rejects invalid/unknown arguments naming the field rather than silently adjusting, and disclosure that the response includes assumptions, fee table version/date and source URLs. This is meaningful context beyond the annotations, though error/edge behavior is not exhaustive.

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, but it is front-loaded with the core purpose and requirements before the fee breakdown and return details. Every clause carries information, though the length is near the upper bound for readability.

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 14 parameters with an output schema, the description covers the required inputs, dependencies, return contents and validation behavior, while annotations carry the safety profile. An agent has everything needed to invoke it correctly without opening other tools.

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 each parameter is already documented (defaults, enums, FBA/FBM conditions), so the baseline is 3. The description mostly restates these requirements and adds only light cross-parameter semantics (peak/non-peak by ship date, apparel/dangerous fee cards) rather than details that go beyond 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 ('Calculate Amazon.com (US) fees for one unit, FBA or FBM') and then enumerates the exact fee components computed (referral, closing, per-item/subscription share, fulfillment, surcharge, storage). This is unambiguous against sibling fee tools like ebay_fees/etsy_fees (US Amazon scope) and amazon_profit (fees, not profit).

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: FBA requires length_in, width_in, height_in, weight_lb, and routes the agent to list_amazon_categories for category ids. It does not name alternatives to use instead (e.g., amazon_profit, compare_marketplaces) or state explicit when-not conditions, 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 already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context: strict input validation that rejects invalid or unknown arguments with a message naming the field and never silently adjusts, plus disclosure that it shares the fee engine with shoptrueprofit.com calculators and returns assumptions and a fee-table version/date. This is exactly the kind of beyond-annotation detail the 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?

Three sentences, each doing work: purpose and inputs first, then what is returned, then validation behavior. The middle sentences are dense but front-loaded and free of filler; only the fee-engine branding sentence is near-optional.

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 complex 18-parameter, four-enum, conditionally-branched FBA/FBM calculator with an output schema present, the description covers the split between fulfillment modes, the conditional input requirements, the date-driven rate effects, and the return contents and validation contract. An agent has everything needed to call it correctly without reading the schema end to end.

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 all 18 parameters thoroughly, including conditional 'FBA (required)' markers. The description restates the input groups (price, category, item cost, inbound vs label cost, ad spend) but adds no syntax, format, or conditional logic the schema does not already carry, 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 and resource (calculate profit, margin and break-even price for one unit sold on Amazon.com US) and enumerates the cost inputs, so the agent knows exactly what the tool produces. It does not explicitly differentiate itself from siblings like amazon_fees or amazon_target_price, and its promise of a 'break-even price' actually overlaps the apparent territory of amazon_target_price, which leaves a small selection ambiguity.

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

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

The description gives conditional context (FBA requires package dimensions and weight; FBM uses label cost; inbound cost is FBA-only; ship_date drives peak/surcharge/storage), which implies usage. But it never says when to prefer this tool over amazon_fees or amazon_target_price, and no exclusions are stated, so the routing decision 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 already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds genuine behavior beyond that: strict input validation that rejects unknown/invalid fields by name rather than silently adjusting, FBA price-band and whole-price referral-band handling, and the fallback to highest reachable margin when the target is impossible.

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 purpose, then behavior, then inputs. Four dense sentences with little waste, though the trailing validation sentence and the source-URL/calculator mentions run slightly long for what they convey.

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

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

An output schema exists, so return values need no prose explanation, and the description still notes key output elements (itemized fees, assumptions, fee-table version/date). For an 18-parameter tool with conditional FBA/FBM requirements, the description covers the complexity and edge cases adequately.

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 18 parameters are documented in the schema itself, giving a baseline of 3. The description adds only generic semantics (FBA vs FBM, price bands) rather than clarifying individual fields, so it neither compensates for a gap nor adds much beyond 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+resource ('Find the lowest Amazon.com (US) item price that breaks even and the lowest that reaches target_margin_pct'), scopes it (US, FBA or FBM), and implicitly distinguishes itself from the sibling fee/profit tools by being the inverse price solver. An agent can tell it apart from amazon_profit and amazon_fees without opening a 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 description explains what it computes and that it shares the fee engine with the free calculators, but never states when to pick this over amazon_profit (known-price) or amazon_fees (fee lookup). Usage context is implied by the tool's nature rather than stated, and no alternatives are named explicitly.

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 and non-destructive, so the bar is low, yet the description adds real behavioral context: strict input validation that rejects unknown arguments by name rather than silently adjusting, the guarantee that results come from the same fee engine as the site's free calculators, and the unit conventions for money and percents. It also discloses what the response contains (fee breakdown, assumptions, fee table version and date, source URLs).

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

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

Four sentences, zero filler, with the comparison scope and the amazon prerequisite front-loaded before unit conventions and return contents. Every sentence carries distinct information that affects either selection or correct invocation.

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

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

For a 10-parameter nested tool with an output schema and full annotation coverage, the description supplies the essentials: required inputs, unit semantics, validation behavior, and the target_margin_pct inversion. The residual gap is the cents-vs-USD wording ambiguity around monetary inputs, which a careful agent could trip on.

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 cross-cutting meaning the schema cannot: all *_pct values are percents where 8.25 means 8.25%, and the amazon object's category/fulfillment plus dimensions/weight requirement for FBA. One note of ambiguity: 'Money is in whole cents' sits alongside schema fields documented as 'USD', which an agent could misread as the input unit for price.

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 (compare) and resource (the same product across Etsy, eBay and Amazon), and enumerates the outputs: fees, profit, margin and break-even price. This clearly distinguishes it from the twelve single-marketplace siblings such as amazon_fees and ebay_profit without the agent needing to open a 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 context for use (one product, three marketplaces, 'One call, one charge') plus the prerequisite that the amazon object is required. However it never explicitly names the single-marketplace siblings as the alternative it replaces, so the routing decision is left mildly implicit.

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, closed-world), so the bar is lower. The description still adds real behavior: strict validation that names the offending field rather than silently adjusting input, the no-Store-subscription rate assumption, and the fact that the result carries a fee-table version/date and official source URLs. Return-content detail is largely redundant with the output schema, keeping it off a 5.

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: the core action and scope lead, then the guidance pointer and unit conventions, then validation behavior. Every sentence carries information, though the enumeration of rate components makes it longer than it strictly needs to be for a single-purpose tool.

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 9-parameter calculator with full schema coverage, annotations, and an output schema, the description supplies everything else an agent needs: category-id sourcing, percent/cent conventions, tax-vs-income caveat, optional-surcharge mechanics, and strict-validation expectations. No material gap remains.

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 cross-parameter semantics the schema only implies: that the final value fee applies to item + shipping + sales tax, that fee tiers apply per item while the per-order fee applies once, and that *_pct arguments are plain percents (8.25 = 8.25%) with money in whole cents. That is meaningful disambiguation beyond the field-level 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 (calculate eBay.com US seller fees) plus the exact scope: one order, tiered per item, no paid Store subscription. The fee components listed (final value fee, per-order fee, Promoted Listings, international, seller-performance surcharge, insertion fee) let an agent distinguish this cleanly from ebay_profit and ebay_target_price without opening a 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 routes the agent to list_ebay_categories for category ids and states the eligibility condition (sellers without a paid Store subscription). It does not, however, say when to prefer this over sibling tools like ebay_profit or ebay_target_price, so the alternative-selection guidance is partial rather than complete.

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, closed-world), and the description adds substantial context beyond them: strict input validation that names the offending field rather than silently adjusting, the exact margin formula (profit / seller revenue, tax excluded), the fee engine's provenance, and the fact that the response carries an itemized breakdown, assumptions, fee-table version/date and source URLs. That is unusually rich behavioral disclosure.

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 sized appropriately for a 12-parameter financial calculator; nearly every sentence carries information (validation behavior, output contents, fee-engine provenance). It is delivered as a single dense block, so the input-convention and output-contents material is harder to scan than it could be, but there is little true waste.

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

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

For a 12-param tool with full schema descriptions and an output schema, the description is nearly complete: it covers purpose, validation posture, unit/percent conventions and what the response contains. The remaining gap is sibling routing — nothing tells the agent when to pick this over ebay_target_price or ebay_fees.

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 still adds value by fixing the percent convention ("8.25 means 8.25%") and defining margin. One caveat: "Money is in whole cents" sits awkwardly against the schema, which describes money arguments as USD with multipleOf 0.01 — an agent could read a $10 price as 1000, so the unit statement introduces ambiguity rather than resolving it.

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+scope: "Calculate profit, margin and break-even price for an eBay.com (US) order." An agent immediately knows it is the eBay profit calculator and can distinguish it from amazon_profit/etsy_profit by the stated marketplace. However, it never differentiates itself from the closest siblings (ebay_fees, ebay_target_price), which overlap with its fee-breakdown and break-even outputs.

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

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

Usage is only implied: the description enumerates the cost inputs an order can have, from which an agent infers "use this when pricing an eBay order." It gives one concrete cross-reference ("See list_ebay_categories" for the category id), which is genuinely helpful routing. But there is no explicit when-to-use vs. ebay_target_price (also mentions break-even) or ebay_fees, and no stated prerequisites or exclusions.

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

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety bar is low. The description adds real behavioral context beyond that: strict input validation with field-naming rejection messages and no silent adjustment, plus it names the shared fee engine and the fee-table versioning. It stops short of documenting pagination or failure modes, but the validation contract is genuinely useful.

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 purpose is front-loaded in the first clause, and each following sentence carries distinct information (fee-step handling, unit conventions, fee engine, return contents, validation). It is dense at six sentences but nearly all of them earn their place; the return-contents sentence is somewhat redundant given the output schema.

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 12-parameter computation tool with full schema coverage, an output schema, and safety annotations, the description supplies the remaining essentials: unit conventions, fee-step handling, and the strict-validation contract. It does not explain the return shape, but the output schema already covers that, so nothing critical 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. The description does add unit meaning (percent inputs like '8.25 means 8.25%'), but its claim that 'Money is in whole cents' sits awkwardly against the schema's per-parameter 'USD' wording and multipleOf 0.01, which could mislead rather than clarify. Net value over the schema is marginal.

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?

Starts with a specific verb and resource — 'Find the lowest eBay.com (US) item price that breaks even and the lowest that reaches target_margin_pct' — which precisely describes the inverse-pricing computation. This is clearly distinguishable from sibling ebay_profit (which computes profit at a known price) without opening either schema, even though that sibling is not named.

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 defines the scenario ('breaks even / reaches target_margin_pct') which implies when to reach for this tool, but it never explicitly routes the agent between this and the siblings ebay_profit, etsy_target_price, or amazon_target_price, nor states when-not to use it. Usage is inferable but not spelled out.

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

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

Annotations already declare the safe-read profile (readOnly, idempotent, non-destructive, closed-world), so credit goes to what the description adds: the output payload (itemized breakdown, assumptions, fee table version/date, source URLs), the fee engine's provenance, and non-obvious validation behavior ('invalid or unknown arguments are rejected with a message naming the field, never silently adjusted'). It does not disclose rounding behavior or how discounts interact with fee bases, which keeps it short of a 5.

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 usage before mechanics, and every clause carries information (fee rates, unit conventions, validation, output). It is dense to the point of being a run-on, and the shoptrueprofit.com provenance plus the trailing 'link to the matching free calculator' are mildly promotional, but nothing is filler-grade.

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, fully schema-documented, output-schema-backed tool, the description covers the remaining gaps an agent needs: when to use it, unit conventions, strict-argument-rejection behavior, and the shape of the response. Nothing required 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 coverage is 100%, so the baseline is 3, but the description adds a real convention not spelled out in the schema: '*_pct arguments are percents: 8.25 means 8.25%', which prevents a decimal-vs-percent call error. The 'money is in whole cents' statement is ambiguous and arguably sits oddly against schema fields using multipleOf 0.01 (which reads as currency units), so the added value is real but not clean.

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 ('Calculate Etsy seller fees for one order') and immediately distinguishes itself from the sibling etsy_profit by scope ('what Etsy takes from a sale' vs. 'when you also know your costs'). The fee components named (listing, transaction, payment processing, Offsite Ads) further pin down exactly what is computed.

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?

Explicit routing guidance: 'Use when you need what Etsy takes from a sale; use etsy_profit when you also know your costs.' This gives both the trigger condition and the named alternative with the condition that selects it, so an agent can choose between the two fee/profit tools without opening schemas.

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

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

Annotations already declare a safe, idempotent, non-destructive read. The description adds genuinely new behavioral facts: strict input validation that rejects invalid/unknown arguments naming the field, never silently adjusting them, and that output includes assumptions, fee-table version/date, and source URLs. It does not disclose rate limits or latency, but that is minor for a pure computation 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 the formula, units, provenance, and validation contract in a tight block with no filler sentences. The shoptrueprofit.com reference and 'matching free calculator' link are mildly promotional but still informative about the return payload.

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 11-parameter, 12-region calculator with an output schema, the description covers what it computes, the conventions for percent and cents inputs, the return shape (itemized breakdown, assumptions, fee-table version), and the error contract. 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 cross-cutting conventions the schema states only per-field: percent arguments are true percents (8.25 = 8.25%) and money is in whole cents. It also pins down the margin denominator (profit / seller revenue, sales tax excluded), which removes ambiguity in how inputs are combined.

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: 'Calculate profit, margin and break-even price for an Etsy order' plus the input factors it consumes. An agent immediately knows this is a profitability calculator, though the description never names or contrasts siblings like etsy_fees or etsy_target_price, so the differentiation is implied rather than explicit.

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 scenario ('for an Etsy order') and the listed inputs, and it names list_etsy_regions indirectly via the region parameter description. However, there is no explicit when-to-use / when-not guidance and no routing to etsy_fees or etsy_target_price, which overlap on fee breakdown and break-even price respectively.

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 (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description's job is to add context — and it does: strict input validation that rejects and names the offending field rather than silently adjusting, plus disclosure of the fee-engine provenance and version/date stamping of the fee table. It does not mention rate limits or latency, but that is minor for a local calculator.

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 purpose is front-loaded in sentence one and the remaining sentences carry real information (margin semantics, unit conventions, validation behavior). Minor waste in mentioning the free calculator twice and the shoptrueprofit.com branding, which does not help tool selection.

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 11-parameter tool with 100% schema coverage and an output schema, the description is close to sufficient: it explains the solve semantics, the fallback when the target margin is unreachable, the unit conventions, and the validation contract. The only real hole is the unresolved money-unit ambiguity, which an agent would need to resolve before calling 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?

With 100% schema coverage the baseline is 3, and the description genuinely adds the percent-vs-ratio convention ('8.25 means 8.25%'), which is easy to get wrong. However, its claim that 'Money is in whole cents' sits awkwardly against the schema's money parameters, which are typed as numbers with multipleOf 0.01 and described as 'in currency' — an agent following the description could scale dollar amounts by 100 and get a wrong result, so the added guidance is not unambiguously safe.

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

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

The description states a precise verb and resource: find the lowest Etsy item price per unit that breaks even and the lowest that reaches target_margin_pct. It distinguishes itself from siblings both by marketplace (Etsy, not amazon_/ebay_target_price) and by intent (it solves for price, whereas etsy_profit evaluates profit at a known 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?

Usage is implied rather than stated: 'target_margin_pct' with '0 = break-even' tells the agent this is the pricing-decision tool, but no sibling is named and no when-not condition is given (e.g., use etsy_profit when you already know the price). The agent must infer the split from the name alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low. The description still adds a genuinely useful behavioral fact absent from the annotations: the call is free while sibling fee tools presumably consume credits, which materially affects agent planning.

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 resource list and capped by the cost note. Nothing is redundant or 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?

A zero-parameter read tool with an output schema has little to disclose; the description covers what the tool returns, that it is read-only, and that it is free. Nothing an agent needs before calling 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?

Zero parameters, so the baseline is 4. The description's enumeration of returned fields (ids, rates, minimums, closing fees, size tiers) describes output rather than inputs, and no param clarification is needed or possible.

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 ('List') plus a precisely enumerated resource: Amazon referral fee category ids, rates, minimums, closing fees, and FBA size tiers. This clearly separates it from list_ebay_categories and from the fee-calculation siblings like amazon_fees.

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

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

The phrase 'accepted by the Amazon tools' implies these values feed the other Amazon fee tools, and 'Free (not charged)' tells the agent it costs nothing to call. However, it never explicitly says when to call this versus amazon_fees, nor that the returned ids are the inputs those tools expect, so usage is only inferred.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered without the description. The description adds one genuine extra trait, "Free (not charged)," which matters for agents tracking API cost, but it doesn't disclose that the result is a static reference set or how it should be consumed.

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, with the payload description front-loaded and the cost note appended. The main clause is slightly run-on ("...category ids and rules, and the seller performance options, accepted by...") but nothing is redundant.

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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. The description covers what the tool returns and that it is free, leaving only minor gaps such as whether the list is static and how frequently it changes.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. The schema also has 100% description coverage with additionalProperties: false.

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 uses a specific verb ("List") with a precisely scoped resource: eBay final value fee category ids/rules plus seller performance options. Because it names the eBay fee taxonomy specifically, an agent can immediately distinguish it from list_amazon_categories, list_etsy_regions, or the fee-computing siblings like ebay_fees and ebay_profit.

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?

"accepted by the eBay tools" clearly signals this is a reference-lookup tool whose output feeds the other eBay fee/profit tools, which is strong implied usage context. It stops short of explicitly naming the alternative tools or stating when not to use it, so it falls short of the top score.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds non-obvious value on top: that the call is free/not billed, and that the payload is a static rate/region reference set. It does not discuss caching or freshness, but the extra billing context is real disclosure beyond the annotations.

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

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

One dense sentence plus a short parenthetical about cost, with the resource named first and the returned fields enumerated after. Nothing is padded and there is no boilerplate.

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?

An output schema exists, so the return values need not be spelled out in prose, and the description caps off with the one behavioral fact an agent needs (the call is free). For a parameterless static-reference tool this is close to complete, missing only explicit sibling routing.

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 is empty with additionalProperties=false, so there is nothing for the description to disambiguate. Baseline for a parameterless tool applies; the description correctly does not invent argument details.

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 (List) and resource (Etsy Payments region ids) with an explicit inventory of the returned data: currency, payment processing rates, and Etsy's listing/transaction/Offsite Ads rates. It reads clearly as a reference/lookup tool distinct from etsy_fees or etsy_profit, though it never names a sibling to make the contrast unambiguous.

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

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

The phrase 'accepted by the Etsy tools' implies these region ids are inputs to other tools, and 'Free (not charged)' signals there is no cost to calling it, which is genuinely useful selection context. However, it never states when to use this versus etsy_fees or etsy_target_price, so the routing guidance is only implied.

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