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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the entity-type scope but says nothing about not-found behavior, whether the response is a single object or empty, or the case-sensitivity caveat (that lives only in the schema).

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 the resource and the lookup key front-loaded, and no filler. Nothing can be removed 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 simple two-parameter read with no output schema and full schema coverage, the definition gives enough to invoke it correctly. The only real gap is the absence of a not-found/response-shape note, which is minor for a straightforward 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?

Schema description coverage is 100% and both parameters are documented there, including the case-sensitive HANA note, so the schema carries the burden. The description reinforces that cardCode must be exact but never mentions the optional fields projection 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 verb and resource ("Fetch one business partner") and narrows the domain with "(customer, supplier or lead)". The words "one" and "exact CardCode" implicitly separate it from the list-style sibling search_business_partners, but 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?

The phrase "by its exact CardCode" implies the precondition (you must already know the code) and hints that broad matching belongs elsewhere, but no alternative is named and no when-not condition is given. An agent must infer that search_business_partners is the fallback when the code is unknown or uncertain.

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 and destructiveHint=false, so safety is covered. The description adds genuine value by disclosing the payload contents (four balance figures plus credit limit), which matters since there is no output schema. It says nothing about behavior for unknown card codes, empty results, or whether balances are real-time.

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 tight sentence that front-loads the returned metrics with zero filler. It is a noun fragment rather than a full sentence, which is minor, but every word 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 one-parameter read tool with full schema coverage and rich annotations, the description is nearly sufficient; enumerating the returned fields compensates for the absent output schema. Missing are edge-case behavior and result-shape hints (e.g. whether all four figures are always present).

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 parameter is fully documented, including case sensitivity on HANA. The description's phrase 'for one business partner' reinforces that cardCode identifies exactly one partner rather than filtering a list, but adds no format or lookup guidance 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 names the specific resource (business partner) and enumerates the four values returned: account balance, open orders balance, open deliveries balance and credit limit. Combined with the tool name the verb is unambiguous. It does not explicitly contrast with get_business_partner, so it falls short of 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?

Usage is only implied: it fetches figures for exactly one business partner, which tells an agent this is a single-record lookup rather than a search. There is no statement of when to prefer get_business_partner or get_open_invoices, and no preconditions such as the card code needing to exist.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered externally. The description contributes the exact-match/case-sensitivity framing but says nothing about not-found behavior or whether missing items return empty vs. error.

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 key constraint (exact code) is placed where it is read first.

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, fully documented read tool with rich annotations and no output schema, this is close to sufficient. The only meaningful omission is behavior on a non-existent ItemCode and whether 'fields' projection affects payload size.

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%, including the case-sensitivity note on HANA and the full enum list for 'fields'. The description's mention of 'exact ItemCode' restates the schema rather than adding format, casing, or projection guidance.

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 (Fetch) and resource (one item master record) with the lookup key (exact ItemCode), so an agent knows this is a single-record exact-match read. It does not explicitly name search_items as the alternative for fuzzy/list lookups, so the sibling distinction is only implied by 'one' and 'exact'.

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

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

The phrase 'by its exact ItemCode' implies the precondition for use (you must already know the code), which is meaningful guidance. But it never states when to prefer search_items instead, nor what happens when the code does not exist.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds real value by spelling out the unpaid-balance formula, but says nothing about ordering, pagination behavior, or what happens when no filters are supplied.

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 tight sentence that front-loads the resource and immediately defines the balance calculation, with no filler. It is appropriately sized for a simple read tool, though the parenthetical formula slightly interrupts the flow.

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 read-only listing tool with a fully described schema and no output schema, the definition covers what the tool returns (invoices plus unpaid balance) and the optional narrowing options. Only minor gaps remain, such as default sort order or maximum result 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 all three parameters are already documented, including limits and the HANA case-sensitivity note. The description only loosely restates customer and overdue filtering and adds no format or edge-case detail beyond the schema, 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?

Names a specific resource (open A/R invoices) and defines the key computed field as DocTotal - PaidToDate, which tells an agent exactly what it will get back. It is less explicit about how it differs from close siblings like get_customer_balance or get_open_sales_orders, so it stops short of 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 phrase 'optionally for one customer or only overdue ones' hints at when the optional parameters apply, but there is no explicit when-to-use or when-not-to-use guidance and no mention of the sibling tools (e.g. get_customer_balance, get_open_sales_orders) that an agent might otherwise pick.

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 the operation as read-only, idempotent, open-world, and non-destructive. The description adds meaningful context by defining 'open' as not closed and not cancelled, and by stating the default ordering is newest first.

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 compact sentence with no wasted words. The key scope and ordering information is front-loaded and easy to parse.

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 list tool with rich annotations and complete schema documentation, the description covers the essential scope and behavior. It could say slightly more about result shape or pagination expectations, but nothing critical is missing.

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

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

Schema description coverage is 100%, so limit, fields, and cardCode are already fully documented in the schema. The description reinforces that customer filtering is optional but does not add syntax, edge cases, or other 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?

The description clearly states the resource ('sales orders') and scope ('open, not closed, not cancelled'), which distinguishes it from read-only invoice tools. It does not explicitly name sibling alternatives, but the resource and status are specific enough for an agent to identify the operation.

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 implies usage by saying the results can be optionally filtered for one customer and are returned newest first. However, it does not state when to use this tool instead of siblings like get_open_invoices or run_saved_query, nor does it give exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered structurally. The description adds genuine context by naming the underlying collection (ItemWarehouseInfoCollection), which hints at data provenance and result shape, but says nothing about error behavior for unknown item codes or how empty warehouses are handled at the response 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?

A single dense sentence with no filler, and the resource is front-loaded ahead of the qualifier ('from ItemWarehouseInfoCollection'). Slightly awkward phrasing but zero 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?

With no output schema, the description carries the return-value burden and does so by listing the four quantity measures, which is the key thing an agent needs. Missing only edge-case notes (unknown item, empty result set) for a lookup tool that is otherwise straightforward.

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 itemCode, includeEmpty and warehouseCode are already documented in the schema. The description only restates the 'one item / per warehouse' scoping, adding no format, case-sensitivity or default details beyond what the schema provides. 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 names the exact resource (per-warehouse stock quantities for a single item) and enumerates the returned measures (in-stock, committed, ordered, available), so an agent can distinguish it from get_item. It doesn't explicitly name a sibling it is not, so it stops short of 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?

There is no when-to-use guidance and no routing to alternatives such as get_item or search_items when the agent has a partial code. Usage is only implied by 'for one item', leaving the agent to infer when this tool beats the broader item lookup.

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 read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds genuinely new behavioral context: the query set is fixed by an administrator in a config file, arbitrary SQL/filters are rejected, and sales_by_month additionally requires a KN_SALES_BY_MONTH entry to exist. It does not say what happens when an unregistered name or undeclared param is supplied.

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

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

Front-loaded with the core constraint (pre-registered only, no free SQL) before the catalog, and every clause carries information. The dense single-sentence catalog is slightly harder to scan than a list would be, but nothing is redundant.

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

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

There is no output schema, and the description does not describe the shape of returned rows, though "highest first" hints at ordering for one query. For a tool with a nested free-form params object, the missing param key names and unspecified behavior on an invalid name leave real gaps for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3, but the description meaningfully upgrades the schema: the schema types "name" as a bare string with no enum, and the description supplies the closed list of three valid values. It also clarifies that "params" must match the declaration of the chosen query rather than being free-form, though it never states the actual param key names (threshold, date, year) an agent must pass.

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 ("Run a query that an administrator pre-registered") and then enumerates the exact closed set of allowed query names with a one-line meaning for each. This immediately separates it from the sibling tools, which are direct entity getters rather than pre-registered, parameterized queries.

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 free SQL or free filters are accepted" plus the admin-config prerequisite gives a clear condition for use and rules out ad-hoc filtering attempts. It stops short of naming a sibling to fall back on (e.g., use get_open_invoices for a plain listing), so the routing guidance is one-sided.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered without the description's help. The description adds real value in disclosing the matching rule (substring contained in CardCode OR CardName), which is behavior beyond the annotations. It does not disclose result ordering, case sensitivity, or whether inactive/frozen partners are included, which matter for a search 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?

Two short sentences, front-loaded with the primary matching rule and followed by the optional refinement — no filler. It is perhaps too terse for a tool with four parameters, but nothing is wasted or buried.

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 is simple and fully read-only, and annotations plus the schema cover the safety profile and most parameters, so the bar is modest. Still missing for correct invocation: behavior with an empty or omitted query (return everything capped at limit?), case sensitivity, and result ordering — all relevant to a free-text search over a large partner master.

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 75% and the description reinforces the query semantics ('contains') and defines the purpose of the type filter, whose enum values carry no description in the schema. It adds little for limit and fields, but those are already self-describing in the schema, so the description complements rather than duplicates.

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 ('Search business partners') plus the exact match semantics (substring on CardCode or CardName) and an optional type filter. This implicitly distinguishes it from the sibling get_business_partner (exact single-record lookup), but it never names the sibling or draws the contrast 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?

Usage is only implied: an agent can infer this is the tool for partial-text/exact-prefix lookup, and the 'optionally filter by type' clause hints at narrowing. There is no guidance on when to prefer get_business_partner, what happens with an empty query, or how to page beyond the limit, so the agent must infer the boundary conditions.

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, non-destructive and openWorld, so the safety profile is covered. The description adds the matching semantics (containment on ItemCode or ItemName) beyond the annotations, which is useful, but says nothing about case sensitivity, result ordering, or what happens when the limit truncates a larger result set.

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 filler, and the most important information (what is searched, and on which fields) is front-loaded. Nothing in it could be removed without losing meaning.

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 four optional parameters, full schema coverage and no output schema, the description is close to sufficient, but it leaves real ambiguity: whether matching is case-sensitive or tokenized, whether results are ordered, and how the default limit of 20 interacts with a broad query. For a search tool these are the details an agent most needs.

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, query, fields and inStockOnly are all documented in the schema itself. The description restates the query semantics that the schema already gives and adds nothing about the other three parameters; baseline 3 is appropriate 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 ("Search") and resource ("items") and states the matching rule: substring match on ItemCode or ItemName. That is enough to distinguish it from get_item (key lookup) by implication, but it never names the sibling explicitly, so the differentiation is inferred 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?

Usage is only implied: the agent must infer that this tool is for partial-text lookup while get_item is for exact retrieval. There is no explicit when-to-use guidance, no mention of when not to use it, and no reference to search_business_partners as the analogous tool for a different resource.

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