Forthcast Inventory

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

Annotations already cover read-only, idempotent, non-destructive and closed-world behavior. The description adds genuinely new behavior: it mirrors Forthcast's PO-line sizing and returns the list of rules that changed the quantity, plus that it works without a connected store — useful for an agent reasoning about a no-store setup.

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 dense sentences with the trigger front-loaded and no redundant restatement of the name or title. Every clause adds routing or behavioral information.

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

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

With a full output schema and annotations present, the description only needs to orient the caller, which it does by explaining the sizing model and the rule-change output. Minor gap: it doesn't hint at precedence among inputs (e.g. daily_demand vs average_daily_demand), though the schema partly covers this.

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% across 12 parameters, so per-field meaning (including that min_order_value needs unit_cost, and case_pack rounding) is already documented. The description gestures at the same inputs without adding new semantics, 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?

Names a specific verb and resource ('how many units to order') and immediately enumerates the inputs that size the line (demand, lead time, stock on hand/on order, supplier rules). This is clearly distinguishable from siblings like calculate_reorder_point or get_reorder_recommendations.

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 opening clause 'Use this when someone asks how many units to order' gives an explicit trigger condition. It does not, however, explicitly exclude the sibling reorder-point or recommendation tools, so an agent must infer which one to pick in overlapping cases.

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 profile is covered. The description adds real context beyond that: a deterministic formula with stated assumptions, which outputs are produced, and that no connected store is required. It stops short of noting rate limits or how assumptions can be overridden.

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, zero filler, and the triggering condition is front-loaded before the input guidance and the return-value note. Every sentence carries distinct information: when to use, what to supply, what comes back.

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 needn't be enumerated, yet the description still names the three key figures and flags formula/assumption transparency. Combined with annotations covering side effects and the fully documented 5-parameter schema, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it marks the daily demand history as the preferred input ('best') and the average-plus-variability path as the fallback, a preference the schema itself does not express. It also names lead time and service level as required ingredients, though without format detail.

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

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

Names a specific verb (calculate) and the concrete outputs (safety stock, lead-time demand, reorder point), and frames the question it answers ('how much safety stock to hold or at what stock level to reorder'). It implicitly separates itself from calculate_order_quantity by focusing on the reorder threshold, but never names a sibling 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?

'Use this when someone asks...' gives a clear triggering condition, and 'Give a daily demand history (best) or an average daily demand with its variability' steers input choice. It adds the useful environment note 'Works without a connected store,' but gives no explicit when-not or named alternative for cases this tool can't cover.

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

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

The annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context not present in annotations: 'Works without a connected store,' telling the agent no store connection or live data 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?

Two sentences, front-loaded with the usage trigger, followed by a compact but relevant list of supported metrics. Every sentence earns its place and 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 single-parameter read-only lookup tool with an output schema, the description covers what the tool does, when to use it, what terms are supported, and that no store connection is needed. Nothing an agent needs to call 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% and the metric parameter is already documented with examples. The description adds a much broader list of accepted terms (safety stock, urgency bands, ABC class, EOQ, fill rate, etc.), effectively serving as an example inventory without needing an enum. That adds meaning beyond the schema's two examples.

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 specific verb ('explain') and resource ('inventory planning term' / 'how Forthcast calculates it') and lists concrete metric names. This clearly separates it from calculation siblings like calculate_reorder_point and calculate_order_quantity, which perform math rather than provide definitions.

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

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

It gives an explicit trigger: 'Use this when someone asks what an inventory planning term means or how Forthcast calculates it.' It also clarifies that it 'Works without a connected store,' which helps an agent know it can be used in unauthenticated contexts. It does not explicitly exclude calculation siblings, which keeps it from 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 declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new context: a connected Forthcast store is required and the assistant will prompt for sign-in, which is exactly the kind of prerequisite an agent can't infer from structured fields.

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 redundancies, with the use case and examples front-loaded before the auth prerequisite. Every clause carries information.

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

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

With an output schema present, return values need no explanation, and the description covers purpose, filters, and the auth prerequisite. The only gap is any hint about result ordering or how the bounded limit interacts with the merchant's request, which is minor for a read-only list tool.

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

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

Schema description coverage is 100%, so the schema already documents limit, vendor, urgency, and supplier, including the urgency enum values. The description only restates the filter axes and adds no syntax, ordering, or defaulting nuance beyond the schema — the baseline 3 applies.

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

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

The description states a specific verb+resource ('bounded list of their items') and enumerates the three filter dimensions (urgency, supplier, Shopify vendor). It implicitly distinguishes itself from singular/aggregate siblings like get_inventory_item and get_inventory_overview via the word 'list', but never names an alternative 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?

It gives a clear triggering condition ('Use this when the merchant wants a bounded list...') and concrete examples ('all excess items or a supplier's critical SKUs'). It does not state when NOT to use it or which sibling to pick for aggregate/single-item questions, so a 5 isn't earned.

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 profile is covered. The description adds genuine value beyond that: it discloses return content (next periods, 80% interval, named model and rationale) and that no store connection 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?

Two sentences, front-loaded with the use case before mechanics, and every clause carries information an agent needs. No filler or redundancy.

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 low-complexity, three-parameter read tool with full schema coverage, an output schema, and complete annotations. The description's extra note about model selection and the disconnected-store capability covers the remaining operational questions an agent would have.

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 `sales`, `period` and `horizon` are all documented, including the min/max item counts and enum values. The description restates the 3–365 range and the monthly/weekly/daily choice already present in the schema and adds no format detail beyond 'oldest first', 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?

States a specific verb and resource (forecast a demand series from past sales totals) plus scope: 3–365 periods, monthly/weekly/daily, returning future periods with an 80% range and the model chosen. An agent can distinguish this from reorder-point or order-quantity siblings without opening any schema.

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

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

Gives a clear triggering condition — someone pastes historical sales and asks what to expect next month/quarter/season — and notes it works without a connected store, removing a prerequisite. It doesn't explicitly name which sibling to use instead when the question is about reorder points or order sizing, so it stops short of the 5 bar.

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, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: the auth/store-connection requirement and the sign-in prompt behavior, which the annotations do not express.

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, zero filler, with the triggering condition front-loaded ahead of the returned-field list and the prerequisite. Every clause carries information an agent needs.

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

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

An output schema exists so return values need no explanation, and the description still summarizes the key fields plus the auth prerequisite. Minor gap: no mention of what happens for an unmatched SKU (error vs empty), which matters for an exact-match lookup.

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

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

Only one parameter and schema description coverage is 100%, so the schema already documents 'sku' as the exact merchant SKU code. The description reinforces the exactness requirement ('names an exact SKU'), adding a little meaning, but nothing about format or case sensitivity beyond the schema — baseline 3.

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 resource and enumerates the exact data returned (live stock, forecast demand, days of supply, reorder point, suggested quantity, supplier, open-PO coverage). The phrase 'the merchant names an exact SKU' implicitly separates it from the search-style sibling find_inventory_items, though that sibling is never 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?

Gives a clear triggering condition ('when the merchant names an exact SKU') plus a prerequisite ('requires a connected Forthcast store; the assistant will prompt to sign in'). It does not explicitly say when not to use it or name find_inventory_items/get_inventory_overview as alternatives, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: a connected Forthcast store is required and the assistant will prompt for sign-in, which the agent could not infer from structured fields. It says nothing about response shape, but an output schema exists.

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, both load-bearing: the first lists the use cases, the second states the prerequisite. The trigger conditions are front-loaded, so an agent can decide quickly whether to call it.

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 an output schema present, the return payload does not need explaining, and with zero parameters there is no input surface to document. The auth requirement is the main extra piece of context, and it is covered; only minor gaps remain around scope limits (e.g., whether counts cover the whole catalog or a date window).

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 the baseline is 4. The description correctly implies no input is needed and instead spends its words on auth prerequisites, which is the right trade-off for a no-arg tool.

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 resource and scope: a broad inventory health check with urgent/excess/no-demand counts, valuation, and PO workload. This distinguishes it from item-level siblings like get_inventory_item or find_inventory_items, though it never names a sibling outright, so differentiation is implied rather than stated.

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 opening clause gives concrete trigger conditions (merchant asks for executive summary, health check, counts, valuation, PO workload), which is strong when-to-use guidance. It stops short of saying when NOT to use it or which sibling to prefer for a narrower question.

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, non-destructive; the description adds value beyond them by explaining that quantities are derived from live lead-time, MOQ, case-pack, open-PO, location and supplier MOV logic, and by disclosing the connected-store/sign-in prerequisite. It doesn't discuss result ordering, freshness, or what happens when no store is connected beyond a sign-in prompt, which keeps 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?

Three tight sentences, front-loaded with the triggering question, followed by computation provenance, the negative scope, and the auth prerequisite. No repetition of schema or annotation content; every clause carries 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 read-only recommendation tool with an output schema and fully documented params, the description covers intent, computation basis, non-mutation and auth requirement — enough to call it correctly. Minor residual gaps (ordering of results, behavior on an empty inventory, how the sign-in prompt surfaces) are not addressed.

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 limit, priority and supplier are already fully documented with defaults, enum values and nullability. The description adds no extra parameter meaning (e.g. what 'warning' vs 'critical' maps to operationally, or how supplier matching behaves), 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+resource ('reorder recommendations') and immediately names the merchant intents it answers (what to reorder, how much to buy, which critical/warning items need action). It also explicitly disclaims PO creation and points at the sibling territory of list_purchase_orders, so an agent can separate it from ordering tools 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?

Gives concrete trigger phrases and one explicit exclusion ('this tool does not create a PO'), which is real routing guidance rather than implied usage. It stops short of naming which sibling to use instead for single-item math (calculate_order_quantity / calculate_reorder_point), so it isn't fully closed-loop.

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, non-destructive, closed-world, so the safety profile is covered. The description still adds real value beyond them: the metric window is fixed at a rolling 24 months, and calling it without auth will trigger a sign-in flow rather than fail silently. It doesn't mention result truncation or how the 20-default/50-max limit behaves at scale.

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, both front-loaded: the trigger condition comes first, the returned metrics second, and the auth prerequisite last. The metric enumeration is dense but each item is a distinct capability, so it earns its space. A slightly tighter phrasing could have trimmed a few words.

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

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

With an output schema present, return-value structure needn't be explained, and annotations cover safety. The description completes the picture with the metric scope, the fixed 24-month window, and the auth prerequisite. The only gap is how limits and the supplier filter behave at the edges, which is minor for a read-only tool.

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

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

Schema description coverage is 100%, with both 'limit' (max 50, default 20) and 'supplier' (case-insensitive name filter) fully documented in the schema. The description adds no further parameter guidance, such as how the supplier filter matches partial names. 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?

The description names a specific verb+resource pairing ('get supplier performance') and enumerates exactly which metrics come back: rolling 24-month on-time rate, fill rate, actual vs. promised lead time, spend, invoice price accuracy, and open/overdue PO counts. None of the sibling tools cover supplier-level analytics, so the agent can distinguish it from get_inventory_overview or list_purchase_orders 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?

It gives an explicit trigger: 'Use this when the merchant asks how suppliers are performing.' It also flags the prerequisite (a connected Forthcast store, with a sign-in prompt). It stops short of naming when NOT to use it or pointing at an alternative for, say, raw PO listings, which would be needed for 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 declare this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful context beyond annotations: results are grouped by PO, the tool never modifies orders, and a connected Forthcast store with sign-in 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?

The description is two focused sentences with no wasted framing. It front-loads the usage condition, then adds the key behavioral and prerequisite constraints.

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 read-only list tool with full schema coverage, annotations, and an output schema, the description is complete. It covers scope, exclusions, result grouping, authentication prerequisites, and non-mutation behavior.

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 limit, status, and supplier semantics. The description reinforces status and supplier use cases but does not add parameter-level detail such as how the limit applies to grouped results.

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

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

The description gives a specific verb and resource: listing purchase orders. It enumerates the merchant questions it answers and clearly states results are grouped by PO, making the tool distinguishable from the inventory-analysis 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?

It explicitly says when to use the tool, covering ordered/drafted/open/partial/received/cancelled/overdue/expected and supplier-associated questions. It also states when not to use it by clarifying that it does not approve, receive, cancel, or otherwise modify orders.

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 profile is covered. The description adds genuinely non-schema behavior: the batch size ceiling, the fact that no connected store is required, and the specific decision bands and derived figures (reorder points, suggested quantities, inventory value) the scoring produces.

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, front-loaded with the trigger, followed by the size constraint and then the outputs. Efficient overall, though enumerating the urgency bands and derived values mildly duplicates the output schema and crowds the closing sentence.

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

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

With only three parameters at full schema coverage and an output schema in place, the description does not need to explain return values or field formats. It covers the trigger, the input ceiling, the no-store condition and the decision framework, leaving only the semantics of service_level and default_lead_time_days unaddressed.

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 items, service_level and default_lead_time_days. The description only echoes the row limit and never explains what service_level or default_lead_time_days do to results, so it adds little meaning beyond the schema. Baseline 3 applies.

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

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

The description gives a specific verb and resource ('score inventory health') plus the concrete input shape it operates on (a list or CSV of products with stock and sales rates) and the questions it answers (reorder, overstock, health). 'Works without a connected store' implicitly separates it from store-backed siblings such as get_reorder_recommendations and find_inventory_items.

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

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

It names the exact trigger condition — the user shares a list/CSV and asks which items need reordering or are overstocked — which is a clear when-to-use signal. It also states a hard applicability limit (up to 500 rows) and the no-store prerequisite, but it never names a sibling alternative for the case where data already lives in a connected store.

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