open_items_ageing

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose two useful constraints beyond the schema: the date format and default for key_date, and the hard cap 'top max 1000'. However, it never states that this is a read-only reporting call, what permissions/company-code scope are required, or how results are paginated or grouped — gaps that matter for a 5-param SAP report.

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

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

A single dense sentence that is front-loaded with the resource and computation, then appends parameter hints with no filler. It is slightly over-compressed ('top max 1000', the trailing 'with names') at the cost of a little readability, but no sentence 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?

An output schema exists, so the bucket and name return values need not be re-explained. For a 5-parameter report tool the description covers the essential computation and most parameters; the remaining shortfall is the undocumented required company_code and the ambiguous partner 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 0%, so the description must define all five parameters, and it only partly does. key_date gets a format and default, account_type gets its two values, and top gets a maximum — but the required company_code is never mentioned at all, and 'per partner' leaves the partner parameter ambiguous (filter vs. grouping dimension) while top's default of 500 is omitted.

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 resource and computation: 'Vendor/customer ageing computed in SAP: open items at key_date ... per partner in buckets by days past net due', and even enumerates the bucket boundaries. The ageing-over-open-items framing is inherently distinguishable from sibling report tools like trial_balance_by_period or glir_differences without needing to name them.

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: an agent infers 'use this when you need AR/AP ageing buckets'. There is no explicit when-to-use statement, no when-not-to-use, and no named alternative (e.g., trial_balance_by_period for ledger balances vs this for open-item ageing).

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