Kras-Trans: transport quotes, CMR, WZ and interest notes

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so no side-effect warning is needed. The description adds useful computation details: it uses the current NBP reference rate and is exact to the grosz, and it states the returned values (days late, rate, interest).

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 short sentences with no filler; the main purpose and output are front-loaded and the sibling routing is a single closing sentence. Every sentence earns its place.

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 covers the return values (days late, rate, interest), input scope, rate variants, and precision. There are no gaps that would prevent an agent from selecting and calling the tool 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% and the input schema already documents every parameter, including enum meanings and formats. The description adds context like the NBP reference rate and Polish statutory article, but it does not materially explain the parameters beyond what the schema provides, so the baseline 3 is appropriate.

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 ('Calculates'), resource ('Polish late-payment interest'), and scope ('one or more overdue amounts'), and distinguishes itself from sibling create_interest_note by noting the formal note is a separate action. It is immediately clear what the tool does and how it differs from related tools.

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 to use create_interest_note when the goal is to issue a formal interest note, providing the key routing decision. The opening phrase states the applicable condition: overdue amounts for which interest needs to be calculated.

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 only generic annotation flags, the description carries the behavioral burden and handles it well: it discloses that the tool creates the note, returns a review link, enables a free 4-copy PDF download, works in 25 languages, and that fields 22–24 are intentionally added on paper after printing. This tells the agent what the user will experience after the call.

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 core behavior and output are front-loaded, and each clause adds relevant information. The multi-language synonym list is long but serves as practical routing vocabulary; a shorter version could trim it without losing clarity, so it is not maximally 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?

Given 18 parameters, nested objects, and no output schema, the description covers the essential context: what is produced (link + free 4-copy PDF), what to ask for, and the paper-signature step. It does not mention link expiry or repeated-call behavior, but those are minor for a tool whose schema fully documents its fields.

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 input schema already documents all parameters (100% coverage), so the baseline applies. The description adds value by prioritizing which fields the agent should actively collect from the user (sender, consignee, places, goods) and noting that stamps/signatures are handled outside the tool, which shapes how optional parameters are treated.

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 starts with a specific verb and resource: it creates an international CMR consignment note on kras-trans.eu and returns a link/PDF. It also names the exact standard (Geneva Convention 1956, IRU layout, 24 fields), which clearly separates it from the sibling tools that create interest notes or WZ goods-issue notes.

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 'Use for' list with CMR and equivalent terms in multiple languages, and tells the agent to ask only for missing essentials (sender, consignee, places, goods). It stops short of naming alternatives or exclusions, but the context is clear enough for an agent to select this tool over non-CMR siblings.

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 annotations providing no safety hints, the description carries the burden and does disclose key behaviors: it creates an external document, uses statutory/commercial/custom rates, counts interest to today for unpaid invoices, and is exact to the grosz. It doesn't mention authentication or legal-effect caveats, but the core behavioral profile is 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?

Three sentences with no filler; the main action and output are front-loaded. Each sentence adds necessary context: calculation logic, rate sources, and behavior for unpaid invoices.

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 description sufficiently explains the tool's output and rate behavior, which is important because there is no output schema. It doesn't spell out required creditor/debtor/invoices fields, but the rich input schema covers that, and the brief output description is adequate for a no-output-schema 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 coverage is 100%, so the input schema already explains all 11 parameters. The description adds useful context around custom rates and unpaid-invoice interest counting, but it doesn't need to compensate for missing parameter documentation.

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: it calculates Polish late-payment interest, creates an interest note (nota odsetkowa), and returns a short link to the PDF. This clearly distinguishes it from the sibling calculate_late_payment_interest by emphasizing document creation and delivery.

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 implies usage for overdue Polish invoices and mentions rate options, but it never explicitly tells an agent when to choose this tool over calculate_late_payment_interest or when not to use it. The boundary between 'just calculate' and 'calculate and create a note' is left to inference.

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 are all false, so the description carries the behavioral disclosure burden. It discloses that the tool creates an external document, returns a short link, calculates line values as quantity × unit price, and gives free PDF access. This is meaningful beyond the annotations, though it does not mention persistence or side effects in detail.

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 compact sentences front-load the main action and result, with no filler. The keyword 'Use for' list is slightly repetitive but earns its place by supporting multilingual and synonym-based agent selection.

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?

Because there is no output schema, the description appropriately specifies the return value as a short link and the user workflow. Combined with the schema's required fields and item structure, an agent can call the tool correctly, though optional behavior like default unit price could be slightly clearer.

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 75%, so the description does not need to compensate heavily. It adds global context by stating prices are in PLN and line values are exactly quantity × unit price, which clarifies unit_price_pln and quantity semantics. It does not explain optional parameter defaults or edge cases beyond what the schema already provides.

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 clearly that it creates a Polish WZ goods issue note on kras-trans.eu and returns a short link for review, print, or PDF download. The verb, resource, and platform make the purpose concrete and distinct from sibling tools like CMR or interest notes.

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 an explicit 'Use for' list covering Polish and English terms for WZ documents, which helps an agent recognize when this tool is appropriate. It does not explicitly say when not to use it or mention alternatives such as CMR, 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 cover readOnly/idempotent/non-destructive, but the description adds real context beyond them: the price carries a validity date, the CMR path only exists after the price is accepted, and the agent must never accept the price on the user's behalf. It stops short of describing failure modes (e.g. unknown quote number or mismatched e-mail).

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, each earning its place: what it returns, what it needs and where to get it, then the workflow constraint front-loaded before the action limit. 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 carries the return-value burden and does so fully (status, net price with validity, CMR print destination), plus the input sourcing and the guardrail. Nothing an agent needs to call this 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%, so the baseline is 3, but the description adds meaning the schema lacks: the number's source (request_transport_quote or the e-mail) and the requirement that the e-mail match the one used in the request. This pairing constraint is genuinely useful for correct invocation.

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?

Specific verb+resource: it checks a Kras-Trans transport quote and states exactly what is returned (status, dispatch price with validity date, CMR print location). It also implicitly distinguishes itself from request_transport_quote by naming it as the upstream origin of the quote number.

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 when to reach for it (looking up a quote's status/price/CMR) and what inputs are needed, and gives a clear behavioral guardrail about not accepting the price. It does not, however, explicitly rule out alternatives or name a sibling to use instead for related tasks.

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 only declare the generic write/open-world profile, so the description's additions carry real weight: the dispatcher calls back with the price, the tool itself returns no price, and the user's phone and e-mail are shared with a third party only after confirmation. It does not mention rate limits or how the request is acknowledged.

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?

Purpose and the confirmation workflow are front-loaded and the operational sentences (confirm before calling, no price returned) earn their place. The carrier credentials (GITD licence, 100,000 EUR liability, 5.0 from 29 reviewers) are largely non-operational padding for an invocation decision, though they support the 'which company can transport this' use case.

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 10 parameters at full schema coverage and no output schema, the description supplies exactly what's missing: the consent protocol, the third-party data handoff, and the fact that no price is returned. An agent can drive the whole collect-summarize-confirm-call loop from it.

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 and the schema already documents every field including examples. The description adds only that pickup, delivery, goods, phone and e-mail should be collected and that user_confirmed gates the call, which is marginal over the existing user_confirmed description.

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 ('sends a request for a road transport price') and names the recipient (Kras-Trans dispatch), with the carrier's scope (vans up to 3.5 t, Poland and 25 EU countries). It is unmistakably distinct from the sibling document-generation tools.

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 names the triggering situations: shipping goods, pallets, furniture or a removal, or the user asking which company can transport between Poland and Europe. No competing alternative needs to be excluded since siblings handle CMR/WZ/interest documents, but no explicit when-not guidance is given.

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