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

No annotations provided, so description carries full burden. Discloses required input format, dependency on caller-supplied data, and a blocking issue with CDS-view. Does not mention side effects or error conditions, but the core behavioral traits are covered.

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 main purpose and return format. The second sentence adds essential dependency and constraint context. No wasted 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?

Given no output schema and two complex parameters, the description covers inputs, output format, dependencies, and a known limitation. Could mention whether tool is read-only or requires permissions, but overall fairly complete for a classification 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 0%, so description must compensate. It explains that valueItems require {id, value} and demandItems require {id, demandSeries} with demandSeries being an array of numbers. Adds business context about ABC/XYZ and the blocking issue, significantly adding value 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?

Clearly states the tool classifies materials by ABC (value/Pareto) and XYZ (demand variability) and returns a combined 9-cell matrix label like 'AX'. This distinguishes it from sibling tools like calc_reorder_point or forecast_demand which focus on different inventory analyses.

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 context on when to use: requires caller-supplied valueItems and demandItems. Notes a limitation that demand series cannot be sourced automatically due to a blocked CDS-view, giving practical guidance. Does not explicitly list exclusions or alternatives but implies usage scenarios.

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, description covers the calculation and a blocker but lacks details on error handling or 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?

Concise single sentence with added note, but could be structured to list parameters and dependencies more clearly.

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 formula and a key dependency, but lacks return value hint; adequate for a straightforward calculator.

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?

0% schema coverage; description only explains safetyStock in context of dependency, not avgDemandPerPeriod or avgLeadTimePeriods beyond formula.

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?

Clearly states it calculates reorder point with the explicit formula, distinct from siblings like calc_safety_stock.

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?

Explains dependency on calc_safety_stock and notes a blocking issue with get_goods_movement_history, providing context on when to use.

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 description discloses the computation method and the data dependency (demand/lead-time statistics), which is good. However, it lacks details on side effects, assumptions (e.g., normality of demand), or what happens with inputs like z vs serviceLevel.

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 concise, consisting of two informative sentences. The key purpose is front-loaded, and the dependency note follows naturally. Minor improvement would be to structure parameter explanations.

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 tool has no output schema and requires detailed parameter input. The description does not mention the return value or formula, leaving the agent to infer what 'safety stock' means as an output. This omission reduces completeness.

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

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

With 0% schema description coverage, the description carries the full burden for parameter meaning. It only vaguely refers to 'demand/lead-time statistics' and does not explain parameters like avgDemandPerPeriod, demandStdDev, or the interplay between z and serviceLevel.

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 clearly states it calculates safety stock using the Z-score method, which is specific and actionable. However, it does not explicitly distinguish itself from the sibling tool 'calc_reorder_point', which likely has a different focus.

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 guidance on when to use this tool versus alternatives like calc_reorder_point or forecast_demand. It mentions a dependency on get_goods_movement_history but does not offer explicit usage context or exclusions.

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

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

With no annotations, the description carries full transparency burdens. It explains the tool's live dependency on get_stock_overview and the required input map. It does not mention side effects or destructive actions, but it is clear about its read-like nature and limitations.

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 covering purpose, dependency, and limitation. No fluff, all information is essential and well-structured.

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 the complexity (nested object, no output schema), the description covers the core behavior, inputs, and a critical limitation. It does not explain the output format, but the lack of output schema makes that less critical. It is sufficient for correct usage.

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 description adds value for two of four parameters (warehouse and movementAgeByMaterial) by explaining their role and constraints. The other two parameters (minOnHandQty, staleDaysThreshold) have only schema descriptions. Given 50% schema coverage, the description compensates well for the key parameters.

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 clearly states the tool's purpose: 'Flags slow-moving/dead stock by on-hand quantity vs. days-since-last-movement.' It distinguishes itself from siblings like get_goods_movement_history and get_stock_overview by noting its dependency on pre-calculated movement age and its live stock pull from get_stock_overview.

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

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

Explicitly tells the caller that movement age must be provided via a map and warns that get_goods_movement_history cannot be used as a source because it lacks a date field. This guides the agent on when to use this tool and what inputs are required.

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 full burden. It discloses the algorithms (sma, ses) and notes the blocked data source dependency, but does not mention aspects like idempotency, rate limits, or side effects. Behavioral coverage is moderate.

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 concise sentences with no redundant information. The purpose and key detail about the blocked dependency are front-loaded, making it efficient.

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 tool with 4 params and no output schema, the description covers the basic purpose and input requirements. However, it lacks details on parameter constraints (e.g., alpha range, windowSize meaning) and output format, leaving some 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?

Schema description coverage is 0%. The description adds meaning to the 'method' parameter by naming sma and ses, but fails to explain 'alpha' and 'windowSize'. It only partially compensates for the schema gap.

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 clearly states the tool forecasts next-period demand using two specific methods (sma and ses), which is specific and distinguished from sibling tools like calc_reorder_point and calc_safety_stock.

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 mentions a dependency on a historical demand series and advises to pass demandSeries directly. It does not explicitly state when to use vs alternatives or provide conditions for choosing between sma and ses, offering only implied usage context.

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 description discloses a critical behavioral nuance: the raw fields IsBlockedForOutbound and IsBlockedForInbound have inverted meanings (blocking putaways and stock removals respectively), and the tool provides semantically-named aliases to resolve ambiguity. This goes beyond mere functionality, though it does not cover other potential behaviors like data freshness or performance.

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 long, front-loaded with the main purpose, and includes a valuable note without redundant information. Every sentence contributes meaning, making it efficient and clear.

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 no output schema, the description adequately explains the return fields (block flags, material count, empty flag) and the alias feature. However, it does not mention pagination or limits of the 'top' parameter, but the tool is simple enough that this is not a critical 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?

Schema description coverage is 67% (two of three parameters have descriptions). The description does not add meaning to parameters beyond what is in the schema; it only mentions return fields. With moderate coverage, a baseline of 3 is appropriate as no parameter information is missing critically.

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 clearly states the tool returns EWM bin-level utilization data including block flags, distinct material count, and empty flag from a specific CDS view. The verb 'Returns' and the resource 'bin-level utilization' are specific and unambiguous, distinguishing it from sibling tools like get_stock_overview or get_goods_movement_history.

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 is provided on when to use this tool versus alternatives such as get_storage_type_capacity or get_stock_overview. The description does not mention use cases, prerequisites, or scenarios where this tool is preferred.

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 fully discloses the tool's current behavior: it raises an error due to missing date field and uncertain CDS view. This is highly transparent.

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 a single concise sentence that front-loads the critical information ('BLOCKED') and efficiently explains the reason, with no wasted 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?

For a blocked tool with 4 required parameters and no output schema or annotations, the description adequately covers the blocking reason and error behavior. However, it lacks parameter-specific details for material and warehouse.

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 0%, and the description only adds meaning for date_from/date_to (stating they are unsupported). Material and warehouse parameters lack any semantic explanation, so the description only partially compensates.

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 explicitly states the tool is BLOCKED and explains why, making the purpose clear despite the tool not functioning. It distinguishes itself from siblings by being a blocked tool.

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 clearly indicates that calling the tool currently raises an error, so agents should avoid using it. However, no alternative tools or explicit 'do not use' directive are provided.

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 fully discloses behavioral constraints: unsupported parameters that raise errors and missing fields. It covers the key error conditions and limitations.

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, each earning its place: the first states the purpose and returned fields, the second lists important exclusions. No wasted words and front-loaded with the core action.

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 no output schema and multiple parameters, the description is complete: it specifies what is returned and what is not. It lacks details on pagination or top parameter behavior, but that is minor.

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 schema already covers all parameters, but the description adds critical meaning: it clarifies that plant and storage_location are not supported and will raise errors, and it reinforces parameter mappings (MaterialId to Material GUID).

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 clearly states the tool returns EWM stock overview records with specific fields (warehouse/storage type/bin/quantity/batch/owner). It effectively distinguishes from siblings like get_bin_utilization and get_storage_type_capacity, which have different purposes.

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 explicit guidance on what the tool does NOT support: filtering by plant or storage_location will cause errors, and no age/last-movement timestamps are returned. It lacks mention of alternatives but effectively advises when not to use this tool.

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 provided, so description carries full burden. Mentions it returns data from a view (implying read-only) but no details on auth, rate limits, or 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?

One sentence, but slightly verbose with technical view name. No wasted words, but could be more concise.

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 tool with no output schema, description lists returned fields but not units, pagination, or ordering. Adequate but has gaps like explaining 'top' parameter.

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 50% and description adds no additional meaning. The 'top' parameter is undocumented in the description; only 'warehouse' is mentioned via 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?

Clearly states it returns per-storage-type capacity utilization for a warehouse, specifying the source view. Distinguishes from siblings like get_bin_utilization which focuses on bins.

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?

Implies usage for capacity utilization per storage type but no explicit when-to-use or alternatives. Lacks guidance on when to use this vs other tools.

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