QuoteBill

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces this with "nothing is saved to any account." It also adds useful behavior beyond annotations: the tool returns a URL, the agent should "Give them that url exactly as returned," and interfaceLanguage controls the page's language.

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 compact and front-loaded: the first sentence states the core action, the second explains the return value and side-effect-free behavior, the third gives a direct instruction, and the fourth adds a parameter-use rule. Every sentence earns its place with 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?

For a complex 16-parameter tool with nested objects and an output schema, the description is complete: it covers what is built, what is returned, that nothing persists, how to handle the returned URL, and how to handle language mismatches. The schema and output schema cover the remaining parameter details.

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. The description adds meaningful parameter-level guidance by explaining when to set interfaceLanguage: when the document language differs from the language the person is writing in. This goes beyond the schema's generic description and helps the agent choose the correct value.

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: "Builds a complete quotation or invoice from line items," optionally starting from a template and totaling it. This clearly distinguishes it from sibling tools like calculate_totals, get_template, and search_templates by emphasizing the end-to-end document-building behavior and the returned URL.

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 gives clear context for when to use the tool: when building a complete quotation or invoice, and it adds operational guidance such as passing interfaceLanguage when the document language differs from the user's language. It does not explicitly name alternatives or say when not to use it, but the context is strong enough for an agent to route correctly.

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, and destructiveHint=false. The description adds meaningful behavioral detail beyond annotations: rounding to the currency and rounding each tax component separately, plus QuoteBill parity. There is no contradiction with 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?

A single front-loaded sentence states the core action first ('Adds up line items, applies discounts, and applies the tax'), then adds a precise qualifier about rounding. Every word earns its place with 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 an output schema present and full parameter coverage in the schema, the description only needs to convey the calculation behavior, which it does thoroughly, including the rounding nuance. No critical behavioral aspect for invoking the tool 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 all four parameters are already documented in detail. The description mentions applying discounts and tax for a country, which loosely maps to lineItems and country, but it adds no syntax, format, or parameter-specific meaning beyond the schema. 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 states a specific verb and resource: it 'Adds up line items, applies discounts, and applies the tax for a country.' It also distinguishes itself from siblings by referencing QuoteBill's exact arithmetic, making clear this is a calculation tool rather than a retrieval or document-building tool.

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 gives clear context by noting it uses 'the same arithmetic QuoteBill uses,' implying this is the canonical totals calculator. It does not explicitly name alternatives or when to avoid it, but among siblings only get_tax_rule is vaguely related, so the usage context is mostly clear.

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, so safety is covered. The description adds behavioral context beyond annotations: it discloses that the tool does not fabricate a rate for countries without a national rate, instead reporting a jurisdiction requirement. This is a meaningful, non-obvious behavior that an agent must 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?

The description is two sentences with no filler. The primary output is front-loaded, and the exception is stated clearly and concisely. Every word earns its place, making it easy for an agent to parse quickly.

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 tool with only two parameters (one required) and an output schema, the description is complete. It covers the core behavior, the special case, and the return fields. An agent has all necessary information to call it correctly and interpret the result, with no missing details about prerequisites or response format.

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 both parameters are already documented. The description adds value by explaining the semantic nuance of the 'country' parameter: for certain countries (e.g., US), the tool will report a jurisdiction need rather than a numeric rate. This enriches the agent's understanding of how to interpret the response, going beyond the schema's basic format.

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 ('look up') and resource ('tax rule'), and details exactly what is returned: published rate, name, currency, and source, across 195 countries. It also clarifies the special case of countries without a national rate (like the US), which further defines scope. It is clearly distinct from siblings like build_document or calculate_totals.

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 when to use this tool (when you need tax information for a country) and provides a crucial usage caveat: for countries like the US, no single rate is returned; instead, the result indicates a jurisdiction is needed. It does not explicitly name alternative tools, but the sibling list makes the distinction obvious, and the caveat effectively guides the agent on expectations.

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, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context about returning the full record, including example line items, and localizing content to the requested language, which goes beyond bare annotation information.

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, efficient sentence that front-loads the core behavior ('full record for one template slug') and adds the two differentiators (example line items, language). Every word earns its place with no redundancy.

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 a simple read operation with only two parameters, both fully documented in the schema. The output schema exists, so return values need not be described. Combined with the annotations and the description's mention of the full record including line items, nothing essential is missing 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 description coverage is 100%, with detailed descriptions for both slug and language, including an enum and example. The description briefly reinforces the language parameter ('in the language asked for') and the concept of a slug, but does not add substantial meaning beyond what the schema already provides. 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 states a specific verb and resource ('full record for one template slug') and distinguishes it from sibling search/list tools by emphasizing a single, complete record including example line items. This makes the tool's purpose immediately clear.

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 clearly implies when to use this tool: when you need the full record for a specific template slug, including example line items. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for an agent to distinguish it from list/search tools.

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, and destructiveHint, so the safety and side-effect profile is fully covered. The description adds no behavioral detail beyond the topics listed; it doesn't mention list ordering, pagination, or fallback behavior, though the schema's language parameter does document the English fallback.

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 compact single sentence that front-loads the resource ('QuoteBill's written guides') and then gives concrete examples of the guide topics. It is slightly list-like but every part contributes to clarifying what the tool returns.

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 listing tool with one well-documented optional parameter, strong annotations, and an output schema, the description plus schema covers what an agent needs to invoke it correctly. The only minor gap is that the description does not explicitly say the tool returns a list, but the title and output schema make that apparent.

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?

There is only one optional parameter and the input schema documents it 100%, including its enum values, default, and fallback behavior. The description's mentions of German, Japanese, and Korean map only loosely to the language parameter and add no operational semantics beyond the schema, so 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 title and name clearly state the action: 'List the how-to guides.' The description adds the resource's scope—QuoteBill's written guides covering quote-to-invoice conversion, country-specific invoice requirements, payment terms, numbering, and currency—which distinguishes it from siblings like list_reference and search_templates. It is not a 5 because the description itself is a fragment and relies on the title for the explicit verb.

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 when to use the tool: when a user wants QuoteBill's written how-to guides on invoice topics. However, it provides no explicit guidance about when to prefer list_reference, get_template, or search_templates instead, and gives no exclusion criteria or alternate routing.

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 and idempotentHint=true, so the safety profile is covered. The description adds behavioral details: categories and layouts are named in the requested language, and only countries with published tax rules are returned. This goes beyond the annotations and helps set expectations about the output's language sensitivity and filtering.

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 sentence that immediately conveys the purpose ('The ids the other tools accept') and then enumerates the exact categories of data. There is zero fluff; every phrase earns its place, and the most important context is front-loaded.

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 the low complexity (one optional parameter), a complete schema, rich annotations, and an existing output schema, the description covers everything an agent needs to know: what data is returned, how language affects naming, and the filtering rule for countries. Nothing essential 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?

The schema description covers the 'language' parameter fully, including the list of supported languages, the default, and its effect on naming. The description restates the language behavior but adds no new meaning beyond the schema. With 100% coverage, the baseline of 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 clearly states what the tool returns: template categories, document layouts, languages, and country codes with published tax rules. It explicitly frames these as 'the ids the other tools accept', which distinguishes it from sibling tools like search_templates or list_guides. The title and description are consistent and unambiguous.

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 provides clear context: this tool supplies reference IDs used by other tools. This implicitly tells an agent to use it when needing valid category, layout, language, or country codes. It doesn't explicitly mention alternatives or exclusions, but the purpose is clear enough that an agent would know when to invoke 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 disclose the safe read-only, idempotent, non-destructive nature, so the description appropriately adds non-redundant behavioral detail: it returns example line items, a page a person can open, localized results, and a concrete scale (133 templates). This is helpful context beyond the annotations and does not contradict them.

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 three short sentences with the main purpose front-loaded. The first sentence states the action and filters; the second summarizes return content; the third gives useful scope context. It is concise overall, though the phrase 'in the language asked for' is slightly redundant with the language parameter.

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 search tool with five optional parameters, an output schema, and read-only/idempotent annotations, this description is substantially complete: it covers search dimensions, return contents, localization, and the size of the template set. The remaining gaps, such as default values or matching behavior, are already covered by the fully documented input schema.

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 schema fully describes all five parameters, so the description is not required to add detailed parameter semantics. It does restate 'words, document type or category' for query, docType, and category, but adds no new format, default, or interplay information 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?

The description names a specific verb ('Find'), a resource ('QuoteBill templates'), and the main filter dimensions ('words, document type or category'). It also tells what is returned (example line items and an openable page), which clarifies the search intent. It does not explicitly contrast with sibling get_template, but the search-vs-get distinction is reasonably inferable.

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 purpose itself implies when to use it: when the agent needs to find templates by words, type, or category. It gives no explicit guidance about when not to use it or which sibling tool to choose instead, such as get_template for a specific known template or list_guides for guide templates.

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