BOM (malzeme listesi) kontrolü

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the computation performed per line — MOQ/order multiples, price-break selection, lead time when stock is short — and the return shape: line totals plus BOM total with VAT excluded. It also discloses throughput and the hard 60-line cap, which are practical constraints an agent must plan around.

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 first defines the operation and its outputs, the second gives the call-size limit and remedy. Dense but every clause carries information an agent needs; 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?

With no output schema, the description responsibly explains what comes back (line totals, BOM total, VAT-excluded, EOL/price-on-request flags) and covers the batch limit. The one omitted behavior is what happens to lines whose part cannot be resolved or that are ambiguous — a meaningful gap for a batch tool fed arbitrary part numbers.

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 schema already documents part formats, quantity bounds, currency and language. The description adds only marginal semantic value — it clarifies that MOQ and order multiples are applied to the supplied quantity and that prices are VAT-excluded — while never mentioning the 'boards' multiplier or 'language' 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?

The description states a specific verb and resource ('Check a bill of materials against Özdisan') and then enumerates the per-line work: part resolution, MOQ/order-multiple application, price-break selection, stock and lead-time checks, end-of-life/price-on-request flagging, and line plus BOM totals. This is unmistakably a batch BOM pricing/availability check, clearly distinct from single-part siblings like get_product or search_products.

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 concrete operating guidance: up to 60 lines per call at roughly 1 s per line, and instructs splitting larger BOMs into several calls. What it does not do is name an alternative for the single-part case (e.g. get_product) or state when not to use it, so it stops short of explicit routing.

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