contboxx Procurement

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

Annotations already declare readOnly/idempotent/non-destructive; the description adds real behavioral context beyond that — an external VIES lookup occurs, reverse charge applies only on a valid VAT ID, and the result is explicitly non-binding. It does not mention latency/fallback behavior when VIES is unavailable.

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 dense sentence with the key qualifier (non-binding) placed at the end as a caveat, and the priced scope front-loaded. The parenthetical and semicolon make it slightly run-on, but every clause adds 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 6-param calculation tool with no output schema, the description omits what the response contains (amount, currency, VAT rate, line items) and says nothing about `zip` or plan validity. Adequate to call correctly, but not complete for interpreting the result.

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 50% schema coverage, the description compensates well: it clarifies period as monthly/annual, addon as an optional dpa package, vat_id as driving reverse charge, and country as the billing country. The `zip` parameter and the plan's example values are left unexplained in the 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+resource and narrows scope precisely: exact price of a *new* subscription, VAT-inclusive for the billing country. That implicitly separates it from create_quote and request_enterprise_quote (non-binding vs. binding), though no sibling is named 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 implied rather than stated: 'non-binding' and 'exact price' hint that this is a pre-quote estimate, not an order or a formal quote. There is no explicit when-to-use/when-not statement or named alternative (e.g. use recommend_plan first, use create_quote to commit).

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?

Goes well past the annotations: discloses the outbound e-mail, that only the recipient can confirm, the 30-day validity tied to the price list, the response fields returned, and the explicit non-ordering guarantee. These are exactly the side-effect details an agent needs before invoking a non-idempotent write.

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 dense sentences: behavior and validity first, then recipient constraint, then return values, then the negative scope. No filler and nothing important 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?

No output schema exists, but the description compensates by enumerating the returned values (quote id, status, next step, privacy policy). Slight gap on how plan/catalog identifiers interact (e.g. addon from catalog) and on failure modes, but the picture is otherwise sufficient to call it 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?

At 50% schema coverage, only the email parameter is elaborated in the description, and that elaboration largely restates the schema's own email description. The plan, period, country, zip, addon and language parameters get no added meaning beyond the schema's enums and maxLengths.

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 (stores a non-binding quote) plus its validity window and the side effect (e-mails a confirmation link). The closing 'Does not order anything' carves out a clear boundary against the ordering/enterprise siblings.

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?

'non-binding', 'valid 30 days while the price list holds' and 'Does not order anything' give clear usage context, and it constrains who may be used as recipient. It stops short of naming when to prefer calculate_price or request_enterprise_quote instead.

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=false, so the safety profile is fully covered. The description's only added behavioral signal is that the catalog is 'complete' and machine-readable, implying one bulk static read — useful but thin, with no note on size, caching, or whether the data is tenant-specific.

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 that leads with the core noun ('The complete machine-readable catalog') and then enumerates contents. The dense comma list is information-bearing rather than filler, though the enumeration is slightly list-heavy for one sentence.

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 parameters and no output schema, the description carries the burden of saying what comes back, and it does so by enumerating the catalog's sections. Missing only structural detail such as nesting or approximate size, which is minor for a static reference endpoint.

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 tool takes zero parameters, which is the baseline-4 case; there is nothing to disambiguate. The description correctly makes no parameter claims, consistent with an empty 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?

States precisely what the tool returns — a complete machine-readable catalog — and enumerates its contents (company, plans with net prices and limits, DPA packages, tax rule, request counting, screens per plan, legal documents). That is far more specific than the title alone, though it never explicitly contrasts itself with siblings such as get_trust_documents or recommend_plan, which partially overlap in subject matter.

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 statement of when to call this versus calculate_price, recommend_plan, or get_trust_documents, and no guidance about whether it should be fetched once and reused. Usage is only implied by the content list (call it to obtain reference pricing/limits data).

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 readOnly/idempotent/non-destructive/non-open-world, so the safety profile is covered. The description still adds real value beyond that: it declares the response excludes personal data and explains the semantics of links.order (only set once the recipient confirmed), which is behavioral context an agent can't get from the annotations.

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 with no filler, and the returned-fields summary is front-loaded ahead of the links.order caveat. The closing clause is slightly cryptic in isolation (what object is links.order part of?) but earns its place as return-shape detail.

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 single-parameter read with no output schema, the description covers what comes back (status, items, validity, links.order) and the privacy boundary, which is the information the schema can't supply. Missing minor items: not-found/error behavior and whether the ID is the quote's public identifier.

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?

One required parameter at 0% schema description coverage, so the description should carry the load; it only says 'by id' and leaves the required format (Q- followed by 24 hex chars, enforced by the schema pattern) unmentioned. The pattern mitigates this, keeping it at a minimum-viable 3 rather than lower.

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 the three things it returns (status, items, validity) plus a scoping detail (no personal data), so the agent knows exactly what to expect back. It doesn't name or differentiate itself from any sibling (create_quote, request_enterprise_quote), though none of those are read operations, so confusion risk is low.

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 tool is keyed by a quote id, so it is clearly a lookup after a quote exists, and the links.order note hints at post-confirmation polling. There's no explicit when-to-use/when-not, no stated alternative, and no mention of what happens for an unknown id.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add content context — which it does by scoping the payload and noting compliance status distinguishes "what is and is not claimed," a genuinely useful honesty signal. It stops short of stating the response shape, but with zero params and no side effects there is little else an agent needs to know before calling.

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, packing all five returned data categories into one line. It is slightly list-like and lacks a leading verb, but nothing is wasted and the most important scoping (legal entity, hosting, compliance) comes 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?

With no parameters and no output schema, the description must carry the entire burden of explaining what comes back — and it does, naming each returned field group including the external links. An agent knows precisely what payload to expect before invoking 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?

The tool takes no parameters, so the baseline of 4 applies; there is no parameter semantics for the description to clarify or omit.

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 enumerates exactly what the tool surfaces — legal entity, VAT ID, hosting region, compliance status, and links to terms/privacy/imprint — which for a zero-parameter getter effectively states its purpose. It never uses an explicit verb ("returns") and doesn't name a sibling, but the subject matter alone separates it cleanly from the pricing/quote 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?

There is no when-to-use guidance, no mention of alternatives, and no trigger condition such as "use when a customer asks about data residency or vendor compliance." The agent must infer the usage scenario entirely from the content list.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the description's job is the non-obvious logic, and it delivers: the result is the cheapest qualifying plan, non-fitting plans carry reason codes, and the status flips to needs_sales on total failure. It stops short of naming the actual return fields beyond reason code and status.

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 the outcome front-loaded and no filler. The parenthetical about fetch frequency and runtime earns its place; the semicolon-joined needs_sales clause is slightly compressed but not wasteful.

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 5-parameter tool with no output schema, the description covers the decision logic, the failure mode, and partial return shape. The remaining gaps are the undocumented departure_stations parameter and the full response structure, which is a minor shortfall rather than a blocking one.

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 must carry the load, and it partially does: screens are glossed as fetch frequency and runtime, and content/locations/dpa are named. However departure_stations is never mentioned, and 'dpa volume' does not clearly map to the dpa_requests_per_day parameter or its unit.

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 outcome: the cheapest self-service plan satisfying given screen/content/location/dpa requirements, plus reason codes and a needs_sales status when nothing fits. The 'self-service' qualifier implicitly separates it from request_enterprise_quote, though no sibling is named explicitly. An agent can tell what it computes without opening the schema.

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 explicit 'use this when' or 'use X instead' statement. The 'self-service' framing and the 'needs_sales when none does' outcome hint that enterprise-sized requirements route elsewhere, but the agent must infer that escalation path rather than being told it.

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 this is a non-read-only, non-idempotent, open-world write, so the safety profile is covered. The description adds genuinely new behavioral facts: the request is handled by the contboxx team and answered by e-mail within two working days, which tells the agent this is asynchronous and human-mediated. It does not say whether resubmission creates duplicates, which would round this out.

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, no waste, and the most decision-relevant element (the routing condition) is placed at the end as a clear activation trigger. The inline field list substitutes efficiently for prose.

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?

It correctly answers the two biggest questions for a submission tool: where the request goes and how fast a reply arrives. But with 15 parameters, 0% schema coverage, and no output schema, an agent still cannot tell what most fields mean or what identifier comes back, leaving a real 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 0% across 15 parameters, so the description carries the compensation burden and mostly does not. It name-drops seven fields in a parenthetical without explaining formats, enums, or the required email/company, and leaves dpa, leitweg_id, deadline, language, name, and message entirely unexplained.

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: it sends a structured enterprise quote request to the contboxx team, listing the payload categories (screens, locations, content, term, payment, e-invoice, PO number). It is clearly not a price calculator or catalog reader, though it never contrasts itself with the sibling create_quote, which is the closest functional neighbor.

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?

'Use when recommend_plan returns needs_sales' gives an explicit trigger condition tied to a named sibling tool, which is unusually actionable. There are no when-not conditions or exclusions (e.g., versus create_quote), so it falls short of a full routing rule.

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