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

No annotations are provided, so the description carries the full behavioral burden. It hints at the scout-then-add workflow and the merchant-review implication of source_url, but says nothing about duplicate handling, required permissions, what happens on failure, or what the call returns for this 10-parameter mutation.

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 sentences, no filler. The core action and payload come first, and the source_url directive follows as an actionable constraint rather than preamble.

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, 5-required mutation tool with no annotations and no output schema, the description covers only a subset of the parameters and none of the failure or return behavior. The schema is rich, which limits the damage, but the definition is not fully self-sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all ten parameters and a baseline of 3 applies. The description adds mild emphasis by calling out price, curator_note, delivery guarantee and source_url, but it adds no format, range, or default information 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 ('Add a new scouted item ... to your store') and names the salient payload fields. It is distinguishable from update_store_item/delete_store_item by the 'new' qualifier, though it never explicitly contrasts itself with those 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?

'Always specify source_url so the merchant can review supplier information' gives a concrete precondition for calling it. However, there is no guidance on when to use this versus update_store_item, nor any exclusion or prerequisite (e.g. whether the store must exist first).

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 does disclose two important traits: it is a mutating tool that unlists items, and it costs 1 Auto-Credit. It does not state whether unlisting is reversible, what happens to items only temporarily down, or whether the operation is idempotent, but the side effect and cost are the highest-value disclosures and they are present.

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 sentences, front-loaded with the core action and its side effect, followed by the cost. No filler or repetition of the tool name; every clause earns its place.

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

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

For a mutating, credit-consuming tool with no annotations and no output schema, the description covers what happens and the cost, but omits reversibility of the unlisting, scale/rate considerations, and what the agent gets back. Adequate but with clear gaps.

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

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

Only one parameter (store_id) with 100% schema description coverage, so the schema already fully documents it. The description adds no format or syntax detail beyond the schema, which is the expected baseline when the schema does the work.

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 (check), resource (active external supplier/source links in a store), and the resulting action (automatically unlist 404/dead items). An agent can tell what it does without opening the schema. It does not explicitly contrast itself with siblings such as run_inventory_sweep or run_pricing_audit, which is the only missing piece.

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?

"Check all active external supplier/source links" implies the context (link hygiene auditing), and the credit cost hints at budgeting, but the description never states when to prefer this over other audit tools like run_inventory_sweep. Usage is inferable rather than stated, and no exclusions are given.

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 that this only 'prepares' a payment intent rather than charging, and that the upgrade is a recurring $19.99/mo subscription via Stripe. It omits what the caller must do with the intent (redirect URL? next step), whether the tier changes immediately, and any auth requirements.

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 sentence that front-loads the operation, then embeds the exact scope and price. No filler, no redundancy with the title or 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 one-parameter tool this covers the essentials, but with no annotations and no output schema there is no structured place left to learn what the tool returns. The description should have said what the prepared intent gives back (e.g., a checkout URL to hand to the user) and what happens after payment succeeds.

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

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

There is a single parameter with 100% schema description coverage ('The ID or slug of the store to upgrade'), so the schema already fully documents it. The description adds no syntax or format detail beyond what the schema provides, which matches the baseline 3 for high-coverage schemas.

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 ('Prepare Stripe checkout payment intent'), the exact resource ('store catalog from 50 to 500 items'), and the commercial terms ($19.99/mo Large Store Pass). This clearly separates it from the sibling checkout_store_fleet_tier (fleet-level upgrade vs. single-store catalog tier).

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 name and description — call it when a store needs to move from the 50-item tier to the 500-item tier. However, it never states prerequisites (store ownership/auth, that the store must currently be on the lower tier) or explicitly routes the agent away from checkout_store_fleet_tier, which is the closest alternative.

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 behavioral burden. 'Prepare' is the only hint that nothing is charged immediately, but the description does not state whether this creates a session, whether payment completes elsewhere, whether it is idempotent, or what the caller must do with the resulting intent. For a money-touching mutation tool this is a substantial gap.

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 front-loaded sentence with no filler; every clause (action, target limit, price, tier name) earns its place.

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

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

For a payment-initiating tool with no annotations and no output schema, the description should say what the agent gets back and how to proceed with the payment intent. It states the commercial terms well but leaves the post-invocation flow and any confirmation/safety notes unstated.

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 per the rubric the baseline is 4. The description has no parameter surface to explain, and none is missing.

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

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

The description gives a concrete verb ('prepare Stripe checkout payment intent') plus the exact resource being changed (store limit 5 -> 50 storefronts) and the price. The numeric limits inherently separate it from checkout_large_store_tier, though that sibling is never named, so the differentiation is implicit 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?

There is no statement of when to use this tool versus checkout_large_store_tier, or what precondition (e.g. current limit of 5) must hold. The agent must infer the routing entirely from the pricing detail. No when-not guidance or alternatives are given.

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 behavioral burden. It usefully reveals a constraint ('unpinned' notes only), but omits that this is an irreversible destructive operation, whether it requires ownership/permissions, and what happens if the note is pinned or absent.

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 front-loaded sentence with zero filler; the verb and the 'unpinned' constraint both land immediately, and nothing needs trimming.

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 simple two-parameter mutation this is minimally adequate, but with no annotations and no output schema, the definition should at least say the removal is destructive/permanent and note the pinned-note failure case. As written, an agent has the 'what' but not the operational context.

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

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

Schema description coverage is 100%, so both parameters (note_id, store_id) are already documented in the schema. The description adds no format, ID-source, or slug-vs-ID detail beyond that, so the baseline 3 applies.

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

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

States a specific verb ('Remove') and a specific resource ('note from the store bulletin board'), which cleanly separates it from siblings post_bulletin_note and get_bulletin_board. It stops short of explicitly naming those siblings, so it earns a solid 4 rather than a 5.

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 offers no guidance on when to use this tool versus siblings like post_bulletin_note or get_bulletin_board, and no preconditions (e.g., needing the note to be unpinned first, or how to obtain note_id). Usage must be inferred entirely from the name and verb.

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 hints that the item may be removed OR merely unlisted, but never clarifies which occurs, whether the action is reversible, whether it requires store ownership, or what happens to the item's orders/inventory records. For a destructive mutation with zero annotation coverage, this is a substantial gap.

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 front-loaded sentence with no wasted words. It is arguably under-informative rather than over-long, so brevity is not the problem.

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 destructive two-parameter tool with no annotations and no output schema needs to explain the permanence/reversibility of the operation and any auth requirements; the description covers neither. The one useful hint it gives ('or unlist') is left unresolved.

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

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

Schema description coverage is 100%, so both store_id and item_id are already documented in the schema; the description adds no format, slug, or ID-syntax detail beyond it. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb ('Remove or unlist') and resource ('an item from your store'), which distinguishes it from add_store_item and update_store_item in the sibling list. The hedge 'or unlist' leaves the exact operation ambiguous, but the target object is 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?

No guidance on when to use this versus update_store_item (which could also unlist) or add_store_item, and no prerequisites or exclusions stated. The agent must infer usage purely from the tool name.

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 of behavioral disclosure. It never states that this is a read-only appraisal, whether results are persisted, what permissions are needed, or how the estimate is derived, so an agent cannot infer side effects from the text alone.

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

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

A single, front-loaded sentence with no filler; the appraised outputs come first. It is somewhat run-on due to the trailing category list, but nothing is wasted.

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

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

With no output schema, the description usefully enumerates the returned fields (rarity 1-100, tier, desirability, valuation), covering the return-value gap. However, it omits any behavioral or usage context for a tool with zero annotations, leaving a meaningful hole even though the schema is fully documented.

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 four parameters. The description's category enumeration roughly restates the schema's category field and adds no new meaning for condition or provenance_notes, making the baseline 3 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 (Appraise) and resource (item collectibility) and enumerates the four outputs it produces: rarity score, collectible tier, desirability, and secondary valuation. An agent can tell this is an evaluation/valuation tool rather than a store-management or matching tool, though it never names a sibling to differentiate itself explicitly.

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

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

The description provides no when-to-use guidance, no preconditions, and no routing to alternatives such as search_collection_matches or inventory_collection_batch. The category list hints at scope but is not usage 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 full behavioral burden, and it does disclose the critical side effect ('releases escrow payout'), which is genuinely valuable for a mutation tool. However, it says nothing about permissions, idempotency/duplicate-submission behavior, reversibility of the payout release, or error handling.

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

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

Two tight sentences with no filler; the action and precondition are front-loaded and the side effect closes the statement. Every clause earns its place.

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

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

Covers the essentials for a mutation tool with no output schema: action, precondition, and financial side effect. It leaves gaps on permission requirements and the digital_code fulfillment path, and its phrasing ('submit carrier and tracking number') implies carrier is required when the schema marks it optional.

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, giving a baseline of 3. The description reinforces carrier/tracking and adds ordering context, but it does not clarify the optional carrier field, the fulfillment_type default, or the notes parameter.

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 action (submit carrier/tracking) against a specific resource (a paid, shipped order), which is unambiguous and easy to distinguish from inventory/pricing siblings. It does not name any sibling, but none of the siblings overlap enough to require routing guidance.

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

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

Provides a clear usage precondition: use it 'once an order has been paid and shipped,' which tells the agent when this tool is applicable. It stops short of naming alternatives or exclusions (e.g., what to do if the order is unpaid), so it falls just below the top band.

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 behavioral burden. It doesn't state whether results are paginated, how many notes are returned, whether alerts expire, or ordering. For a list tool with no annotations this is a significant gap.

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 efficient sentence that front-loads the verb and resource and adds the content categories without 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 single-purpose, single-parameter read tool this is close to sufficient, but with no annotations and no output schema the description should disclose basic return behavior (e.g., list shape, ordering) that an agent would otherwise need to discover.

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% for the single store_id parameter, so the baseline of 3 applies. The description adds nothing about the parameter's semantics beyond what the schema documents.

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

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

States a specific verb (Read) and resource (bulletin board) and enumerates the content types (notes, announcements, restocking alerts). It clearly distinguishes itself from post_bulletin_note and delete_bulletin_note by being the read-side tool, though it doesn't name them explicitly.

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

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

Read-only intent is implied by 'Read' and the sibling set makes the read/write split obvious, but there is no explicit when-to-use guidance or mention of alternatives such as the get_store_message_receiver tools.

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 behavioral burden. It implies a read-only listing and scopes the result set to paid, unshipped orders, but says nothing about pagination, sorting, result caps, or whether the response is a snapshot. For a list tool with zero annotation coverage this is a substantial gap.

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 efficient sentence with the scope constraint front-loaded and no filler. It is appropriately sized, though slightly terse for the behavioral context it omits.

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 simple one-parameter read tool with no output schema, the description adequately conveys what is returned. However, it omits return shape, pagination, and any relationship to the fulfillment workflow, leaving the agent with a 'minimum viable' understanding.

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

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

There is a single optional parameter with 100% schema description coverage ('Optional store ID filter'), so the schema already does the work. The description does not add format, default, or multi-store behavior beyond what the schema states, warranting the baseline score.

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 well-scoped resource ('paid customer orders awaiting shipping and fulfillment for your store') makes the purpose immediately clear. It implicitly contrasts with the write-oriented sibling 'fulfill_order', but it never names or explicitly differentiates itself from that or other 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 description states what the tool returns but gives no guidance on when to reach for it versus alternatives like 'fulfill_order' or 'get_store_inventory'. The 'awaiting shipping' qualifier hints at a workflow stage, but no prerequisites, ordering, or exclusions are 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 full burden, and it does add genuine behavioral value: it enumerates what is returned (balance, allowance) and even the concrete allowance values (7 standard vs 21 AI Co-Manager) plus the refill schedule (Sunday 00:01 UTC). However, it omits read-only/auth expectations and any rate-limit or failure behavior.

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

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

A single front-loaded sentence listing the three return elements with zero filler. It is dense but every clause maps to a returned datum, so nothing is wasted.

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

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

For a one-parameter read tool with no output schema and no annotations, the description adequately conveys what the caller receives (balance, allowance, refill time). It is complete enough to invoke correctly, though it could note read-only semantics.

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 store_id is already documented in the schema; the description only echoes 'for a store' without adding format or accepted-value detail. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb ('Inspect') and resource (automation credit balance, weekly allowance, refill time), making the tool's job unambiguous. It does not explicitly differentiate from the nearest sibling get_store_limits, but the credit domain is distinct enough that confusion is unlikely.

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?

There is no statement of when to use this tool, when not to, or which alternative applies (e.g., get_store_limits vs this credit inspector). Usage must be inferred entirely from the name and resource described.

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. It discloses the filter (active and listed items) and returned fields, which is useful, but omits pagination behavior, permission requirements, and whether the inventory is real-time, leaving significant gaps for an unannotated read 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?

A single sentence with no wasted words, front-loading the core action and resource. It is appropriately sized for a simple read 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?

Given a one-parameter read tool with no annotations or output schema, the description covers the essentials of what is returned. However, it leaves out pagination, permissions, and any indication of result scope, so it is only minimally complete.

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

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

Schema description coverage is 100% and the single store_id parameter is fully documented in the schema. The description adds no parameter syntax or format details beyond that, so the baseline of 3 applies.

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

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

States a specific verb (List), resource (items in a store), and returned fields (pricing, quantity, status). It does not differentiate from sibling tools such as scout_store_items or list_my_stores, so it is clear but not sibling-aware.

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

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

Provides no when-to-use or when-not-to-use guidance, nor any named alternative. An agent must infer from the name alone that this is for retrieving store inventory rather than, say, searching or auditing items.

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 behavioral burden; "Inspect" implies a safe read operation, but that is inference rather than disclosure. It does add genuine behavioral value by enumerating the tier thresholds, which tells the agent what values to expect. It omits auth requirements, whether results are cached, and what happens when store_id is omitted (account-level vs store-level).

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 sentence, no filler, front-loaded with the primary capability and parenthetically carrying the exact numeric thresholds. Every clause earns its place and nothing is repeated from structured fields.

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 simple read-only lookup with one optional parameter, no annotations, and no output schema, the description adequately conveys the two quantities returned and their tier values. The remaining gap is the no-argument behavior, which is left ambiguous.

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% for the single optional store_id parameter, so the baseline is 3. The description adds indirect meaning by distinguishing per-store catalog capacity from the account-wide store limit, which hints at how store_id scopes the result, but it never mentions the parameter explicitly.

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

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

States a specific verb ("Inspect") and resource ("store catalog capacity" and "account store limit"), and goes further by naming the concrete values for each tier (50 vs 500 items, 5 vs 50 stores). An agent immediately knows this is a read-only limits lookup. It does not differentiate itself from related siblings such as checkout_large_store_tier or checkout_store_fleet_tier, which is the only gap.

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 says what information is returned but never states when to call this tool, what prerequisite state is needed, or how it relates to the tier-checkout siblings. The likely use case (checking current limits before upgrading) must be inferred entirely by the agent.

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 provided, the description carries the full behavioral burden, but "Retrieve" at least establishes a read-only, low-risk operation and "current" implies live state. It says nothing about authentication requirements, whether the call errors or returns defaults when no receiver is configured, or about rate limits.

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 sentence, front-loaded with the verb and resource, with no redundant or filler text. Nothing could be trimmed without losing 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 one-parameter read tool with no output schema, the description names what is returned but does not characterize the response shape (e.g., what a message receiver is, what fallback routing contains, or what an unconfigured store returns). Adequate but with a clear gap given the absence of an output schema.

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

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

Schema coverage is 100% and the single store_id parameter is fully documented as "The ID or slug of your store." The description adds no additional meaning about accepted formats or resolution behavior, so the schema does all the work — the baseline 3 applies.

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

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

Uses a specific verb ("Retrieve") plus a concrete resource ("message receiver and fallback routing settings for a store"), so an agent knows exactly what comes back. It does not explicitly name its obvious counterpart set_store_message_receiver, so sibling differentiation relies on the reader noticing the get/set naming convention.

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 no when-to-use context, no prerequisites, and no exclusions or alternatives. An agent must infer that this is the read-side companion to set_store_message_receiver rather than being told.

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 behavioral burden. It signals a bulk write ('batch inventory and list'), but never discloses whether items are created or updated on conflict, what happens on partial failures, whether defaults (quantity=1, delivery_sla_days=4) apply, or what auth is required.

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 front-loaded sentence with no filler. It efficiently names the action, the batch nature, and the target catalog.

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 batch mutation with a nested item array, no annotations, and no output schema, the definition should explain conflict/update semantics, partial-failure behavior, and auth. None of that is present, leaving significant gaps for an agent to call 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?

Schema description coverage is 100%, so the schema already documents all top-level and nested fields. The description adds only the 'storefront catalog' framing and the types of source lots, not meaning 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 action (batch inventory and list) and resource (collection/estate haul/curated lot) onto a storefront catalog, which is distinguishable from add_store_item's single-item intent. However, 'inventory' as a verb is vague and the phrase blends reading stock with writing listings, leaving the precise operation somewhat ambiguous.

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?

No guidance on when to use this versus add_store_item or run_inventory_sweep, despite those being obvious alternatives. It also doesn't hint at any prerequisites such as store ownership or credit limits.

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. 'List' implies a read-only, non-destructive operation, but nothing is said about permissions, pagination, result size, or the shape/count of what is returned.

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 front-loaded sentence with no filler, and the scope qualifier is stated up front rather than buried. Every word earns its place.

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

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

For a zero-parameter read tool with no output schema, the description covers the essentials: what entity is listed and whose stores are in scope. It stops short of describing the general return contents, but the simplicity of the tool makes this a minor gap.

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 are no parameter semantics to document; the baseline for a parameterless schema is 4. The description adds nothing further because nothing is needed.

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 (List) and resource (stores) with a scope qualifier ('owned by or accessible to this agent account'). No sibling tool lists stores, so it is implicitly distinguishable, but there is no explicit contrast with alternatives such as get_store_inventory or get_store_limits.

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?

There is no statement of when to use this versus the many store-scoped siblings, nor any prerequisite context (e.g., whether it is the discovery step before calling get_store_inventory). Usage must be inferred entirely from the name.

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 behavioral burden and delivers almost none of it. It implies a write operation but says nothing about required permissions, whether posting notifies store members, whether it is rate-limited, or what happens on success. For a mutation tool with zero annotation coverage, this is a significant gap.

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 front-loaded sentence with no filler; the core action and target are immediately clear. It is not padded, though the loose use of "Pin" costs a bit of precision.

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?

Adequate for selection purposes.

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 every parameter (title, message, store_id, is_pinned, note_color) is already documented in the schema; baseline 3 applies. The description adds no syntax, format, or constraint detail beyond the schema, and its use of "Pin" does not clarify the is_pinned parameter.

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+resource: pinning/posting a note to the store bulletin board, with useful examples of content type (note, announcement, restocking alert). It is clearly distinguishable from get_bulletin_board and delete_bulletin_note, though it doesn't name those siblings. The verb "Pin" is slightly at odds with is_pinned defaulting to false, which introduces minor ambiguity about whether pinning is mandatory.

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 no when-to-use guidance: no prerequisites (store membership, permissions), no mention of when to prefer this over delete_bulletin_note or get_bulletin_board, and no exclusions. Usage is only implied by the tool's stated purpose. Content-type examples hint at scenarios but do not constitute 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?

No annotations exist, so the description carries the full behavioral burden. It usefully discloses a cost ('Consumes 1 Auto-Credit') and implies mutation via 'restocks' and 'optimizes', but says nothing about permissions required, reversibility, rate limits, or what happens to items it fails to restock.

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

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

Two compact sentences, front-loaded with the core action and its sub-tasks, followed by the credit cost. No filler, though the parenthetical list is dense and could be slightly tighter.

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 no-annotation mutation tool with no output schema, the description omits critical context: what the sweep returns, what gets modified, failure handling, and the prerequisite of sufficient Auto-Credits. It covers the 'what' but leaves the agent guessing about outcomes.

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 store_id, items_to_scout and min_inventory_target are already documented in the schema. The description adds no syntax, format, or interplay detail (e.g. how min_inventory_target drives restocking) beyond what the schema provides.

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 ('Perform an automated inventory maintenance sweep') and enumerates the three sub-operations (audits dead supplier links, restocks scouted finds, optimizes stale pricing). This distinguishes it from the narrower siblings run_pricing_audit and audit_source_urls, though it never explicitly says it is the composite of those.

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?

No when-to-use guidance and no exclusions. Siblings run_pricing_audit, audit_source_urls and scout_store_items overlap with the sub-tasks this sweep performs, yet the description never says when to prefer the sweep over those focused tools or how often to run it.

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. It does usefully disclose the cost ('Consumes 1 Auto-Credit'), which is real value beyond structured fields, but it omits whether recommendations are auto-applied, whether the operation is reversible, latency, and idempotency behavior.

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

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

Two short sentences, front-loaded with the action and its output, then the cost constraint. Nothing extraneous and no filler.

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

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

For a two-parameter tool with no output schema and no annotations, the description is only adequate. It never indicates what the audit returns, how long it takes, or whether it mutates prices, leaving the agent to guess at the post-call 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?

Schema description coverage is 100%, with both store_id and strategy (balanced/aggressive/conservative) documented in the schema itself. The description adds only the phrase 'for store inventory' and no strategy semantics, so baseline 3 applies.

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

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

Specific verb+resource: 'Run an AI pricing audit' that 'generate[s] competitive pricing recommendations for store inventory'. This clearly separates it from siblings like run_inventory_sweep and evaluate_item_collectibility, though it does not name an alternative directly.

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: agents can infer it is for getting pricing recommendations on store inventory. There is no explicit when-to-use, no exclusion criteria, and no mention of prerequisites beyond the credit cost.

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 behavioral burden. It usefully discloses that the call 'Consumes 1 Auto-Credit', which is important for cost-aware agents, but it omits permissions, failure behavior, whether scouted items are automatically added to the store, and other side effects.

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 core action and followed by the cost. There is no filler, and the agent can extract the essential purpose immediately.

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 three-parameter tool with no output schema and no annotations, the description is minimal but not empty: it states the purpose and the credit cost. It still leaves important gaps, including return behavior and whether scouting affects store inventory.

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

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

Schema description coverage is 100%, and the schema documents all three parameters, so the description is not required to compensate. The description adds no parameter-specific syntax or format details beyond what the schema already provides.

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 ('Scout') and resource ('fresh commercial products from the web tailored to store niche'), so an agent can tell it is a product-sourcing tool rather than an inventory mutation tool. It does not explicitly distinguish itself from close siblings such as add_store_item or run_inventory_sweep, which limits it to a 4.

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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives among the many sibling tools. The only clue is the implied context of needing fresh products for a store niche.

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 behavioral burden. 'Search' implies a read-only operation, but the description does not disclose result scope, pagination, rate limits, permissions, or whether the catalog is global versus user-specific.

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

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

It is a single well-formed sentence with the action and purpose front-loaded. There is no redundant or filler text.

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 simple two-parameter search tool with full schema coverage, the description covers intended use cases adequately. It still omits return-value expectations and pagination behavior, and there is no output schema to compensate.

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

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

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description adds no query syntax, category semantics, or filtering behavior beyond what the schema provides.

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

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

The description gives a clear verb and resource: 'Search marketplace catalog.' It also names concrete collector-facing goals, but it does not explicitly distinguish this tool from siblings such as scout_store_items or evaluate_item_collectibility.

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 lists plausible usage scenarios: finding missing set pieces, tracking comparative valuations, and verifying market availability. However, it gives no when-not guidance, prerequisites, or alternative tools to use instead.

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 behavioral burden. It discloses the routing destinations (email or webhook) and a side effect (preventing platform-admin routing), but omits critical traits like required permissions, whether it overwrites existing settings, whether email and webhook are mutually exclusive, and what the operation returns.

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

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

The description is two sentences with no wasted words, and the core purpose is front-loaded before the supporting benefit. It is appropriately sized for the tool's complexity.

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?

The description states the core purpose and routing options, and the schema fully covers parameters. However, for a configuration mutation with no annotations and no output schema, it lacks important operational context such as permission requirements, overwrite behavior, and whether webhook is optional or replaces email.

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 four parameters thoroughly. The description adds no syntax, format, or constraint details beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description states a clear verb ('Configure') and resource ('where inbound buyer inquiries, store contact messages, and notices... are routed'), making the tool's function obvious. It does not explicitly name the sibling read counterpart (get_store_message_receiver), so it misses full sibling differentiation.

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 the tool does but offers no explicit guidance on when to use it versus alternatives, nor any prerequisites or exclusions. The mention that it 'prevents inquiries routing to platform admin' is motivational context, not usage 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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the mutation verb. It does not say whether omitted fields are left unchanged (partial vs full update), whether the change is reversible, what permissions are required, or what errors occur for invalid store/item IDs.

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 front-loaded sentence that gets to the point with no filler. It slightly duplicates field names already in the schema, which keeps it just short of ideal, but there is no wasted prose.

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 mutation tool with no annotations and no output schema, the description is minimally adequate but omits the two required identifiers (store_id, item_id) and the partial-update contract, both of which an agent needs before calling it safely.

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 all 8 parameters including store_id, item_id, name and is_active are already documented in the schema. The description restates four of those fields (price, quantity, description, curator_note) without adding format, validation, or constraint detail, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Update an existing item') and names the kinds of fields that can change, which implicitly separates it from the add_store_item/delete_store_item siblings in the list. It is clear but does not explicitly name those siblings or a scope boundary beyond 'existing'.

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: 'existing item' signals this is for modifying rather than creating or removing an item. There is no explicit when-to-use statement, no prerequisites (e.g. ownership/permission), and no named alternative for related tasks.

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