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

The description adds specifics beyond the annotations by identifying the source as the 'public registry' and clarifying that the tool returns company data. Since there is no output schema, this return-value signal is valuable. The description is consistent with the readOnly, openWorld, and idempotent hints.

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, no filler. The core lookup behavior and the practical use case are both front-loaded, and 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?

For a simple one-parameter read-only lookup with rich annotations and full schema coverage, the description covers the behavior, the result, and the intended use case. Nothing essential is missing for an agent to select and invoke this 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?

The schema already fully documents the single parameter with format examples, so schema coverage is 100%. The description does not add new parameter-level details, but it reinforces that the tax number is the subject of validation. This meets the baseline without exceeding it.

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 action ('Looks up'), the resource ('Hungarian tax number in the public registry'), and the result ('returns the company data behind it'). It is easily distinguished from sibling tools like billingo_list_partners or billingo_get_organization because the lookup is tax-number-driven, not a list or organization-level 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?

The description gives explicit guidance: 'Use this to validate a tax number before creating a partner.' This tells the agent exactly when to invoke the tool. It does not enumerate alternatives or exclusions, but the context is clear enough given the sibling set.

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 readOnly/idempotent annotations already present, the description adds valuable behavioral detail: default public URL behavior, Claude Desktop incompatibility with base64, ~1.33x context overhead, and rendering risks. No contradiction with 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?

The description is three sentences that front-load the behavior, then add only necessary caveats. Every sentence earns its place, and the cost/rendering warnings are compactly expressed.

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 read-only tool with no output schema, the description is complete: it states the return form, default behavior, when to override it, and the trade-offs. An agent has enough context to call it correctly and to interpret 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?

The schema already covers both parameters at 100%, so the baseline is 3, but the description adds significant meaning: it names 'url' as the default, instructs when to use base64, quantifies the context cost, and warns about client support. This exceeds schema-only information.

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 clear action and resource: 'Gets the document PDF' and identifies two return formats. It is not a tautology, but it does not explicitly distinguish itself from the sibling billingo_get_document_public_url even though both can yield a public 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 explicit format-selection guidance: default URL is 'what you want in almost every case' and base64 should be used 'only when a caller specifically needs the raw PDF bytes.' It does not, however, mention sibling tools or say when to prefer this tool over get_document_public_url.

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 indicate readOnlyHint, and the description reinforces this with 'Nothing is modified.' It also discloses that the tool creates the export, waits for completion, returns the file, truncates very large exports with an explicit note, and that binary formats may not display inline. This is rich behavioral context beyond 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?

Every sentence in the description contributes meaningful information. The main purpose is front-loaded, followed by behavioral notes and output-type distinctions. It is concise enough to read quickly while covering all important nuances.

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 5 parameters, no output schema, and a complex format-dependent return behavior, the description covers the key operational aspects: no side effects, waiting/truncation behavior, and inline-display limitations. Schema handles the remaining parameter details, so 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining how the format parameter behaves (textual vs binary output, truncation behavior, and that a narrower date range returns the whole export). This extra semantic context justifies a 4.

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?

Description opens with a specific verb and resource: 'Exports documents in a date range to a downloadable file'. It clearly distinguishes itself from siblings like billingo_download_document by emphasizing date-range export and multiple accounting formats. The explicit format examples further anchor the purpose.

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 scenarios: use for date-range exports in Billingo-supported formats, with guidance on textual vs binary outputs. However, it does not explicitly name alternatives such as billingo_download_document or say when not to use them, so it stops short of a full when/when-not 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, idempotentHint, and openWorldHint, covering the key behavioral safety traits. The description confirms it returns data but adds no extra behavioral context such as not-found behavior, response format, or authorization requirements. It does not contradict 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, direct sentence communicates the core operation with no filler or redundant wording. The essential qualifiers 'single' and 'by id' are front-loaded and immediately actionable.

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 single-parameter read operation with strong annotations, the description is largely sufficient to select and invoke the tool. The only minor gap is the absence of response-shape or error-behavior details, but the low complexity and clear purpose make this acceptable.

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 provides 100% coverage with a clear description for the only parameter ('Bank account id.'). The description merely restates 'by id' and adds no new semantic detail beyond what the input schema already conveys, so the baseline score 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 uses a specific verb ('Returns') and resource ('a single bank account') along with the lookup criterion ('by id'). This clearly distinguishes it from sibling tools like billingo_list_bank_accounts, which returns multiple accounts, and from other get-by-id tools for different entities.

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 this tool is for fetching exactly one bank account when its id is known, which is the appropriate context versus listing bank accounts. It does not explicitly name alternatives or give when-not-to-use conditions, but the single-by-id phrasing provides enough contextual guidance for a simple getter.

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 openWorldHint, covering safety and repeatability. The description adds a useful nuance that it returns the rate Billingo would apply, not necessarily a market rate. However, it does not describe rate dynamics, date sensitivity, or output details, so it adds only moderate behavioral context beyond 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?

The description is a single, focused sentence that front-loads the core action and resource. Every word adds meaning, and there is no repetition of the title or obvious filler. It is optimally concise and scannable.

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 straightforward, read-only conversion-rate lookup with two required enum parameters and one optional date, the description together with the schema and annotations gives an agent enough to call the tool correctly. There is no output schema, but the return value is clearly implied by the description. A few details like exact response format or error conditions are absent, but they are not essential 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?

The main description contains no parameter-level information, but schema_description_coverage is 100%. The schema provides clear descriptions for from, to, and date, including a valuable explanation of how to use the date parameter for historical documents. This meets the baseline expectation for a well-covered schema; the description itself adds no further parameter semantics.

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 ('Returns'), a specific resource ('conversion rate'), and a clear qualifier ('Billingo would apply'). It fully conveys what the tool does and is naturally distinguished from the sibling tools, none of which offer conversion rates.

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 main description does not explicitly state when to use this tool or when to prefer an alternative. Since no sibling tool provides conversion rates, this is less critical, but the usage context is only implied. The schema's date parameter description adds meaningful practical guidance for backdated documents, but that belongs to the structured schema rather than the tool description.

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, openWorldHint, and idempotentHint, covering the safety profile. The description adds the useful behavioral detail that the tool can look up by either Billingo id or vendor_id, but it does not disclose return shape, error behavior, or exclusions. Given the annotations, this is adequate but not rich.

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 front-loaded sentence with no filler. It states the core behavior first, then immediately provides the essential parameter instruction. Every part 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?

For a simple read-only lookup with annotations covering safety and a schema covering both parameters, the description provides enough to invoke the tool correctly. It is slightly incomplete in not steering the agent away from sibling document tools, but that is a minor gap given the simplicity of the operation.

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 meaning beyond the schema by stating that either id or vendor_id should be provided, and by explaining that vendor_id is the caller's external reference set at document creation. This clarifies the role and relationship of the two parameters.

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 action ('Returns') and a specific resource ('a single document'), clearly distinguishing from list-style tools. However, it does not explicitly differentiate itself from sibling tools like billingo_download_document or billingo_get_document_public_url, 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 description gives parameter-level guidance ('Give either id or vendor_id') but does not explain when to choose this tool over the many document-related siblings. There is no explicit when-to-use or when-not-to-use guidance, so an agent could confuse it with download or public-URL retrieval 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, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds only the resource scope ('payments recorded against a document') and no further behavioral context such as response shape, pagination, or edge cases, so it contributes little beyond 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?

The description is a single, focused sentence with no redundant wording. It front-loads the action and resource, making it easy to scan.

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, single-parameter read-only tool with rich annotations, the description is mostly sufficient: the agent knows the input (document id), the operation (returns payments), and that it is safe/idempotent. Some detail about the returned payment entries could be useful, but it is not necessary 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% and the single parameter already has a clear description ('Document id.'). The tool description does not add parameter-specific meaning beyond what the schema provides, which matches the baseline for high schema coverage.

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 uses a specific verb ('Returns') and a clearly identified resource ('payments recorded against a document'). It is easily distinguished from sibling tools like billingo_get_document and billingo_get_document_reminders, so an agent can tell what this tool does without inspecting schemas.

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 that this tool should be used when payment information for a document is needed, but it provides no explicit guidance about when not to use it or which sibling alternative might be more appropriate. The intended use is inferable, not directly stated.

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 openWorldHint, covering the operation's safety and repeatability. The description adds meaningful behavioral context: the returned URL is shareable and accessible without authentication/login. It does not mention URL expiration or permissions, but for a simple public-URL generator the key behavioral trait is disclosed.

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 with no filler. The main outcome ('Returns a shareable public URL') is front-loaded, and the key condition ('viewable without a Billingo login') is included succinctly.

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-only, idempotent tool, the description covers the essential behavior and access requirements. There is no output schema, but stating that it 'Returns a shareable public URL' gives sufficient expectation of the result. Minor missing details like URL expiration or response shape could be added, but they are not critical 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?

There is only one parameter, 'id', and the schema description fully documents it as 'Document id.' With 100% schema description coverage, the description adds little beyond connecting 'document' to the public URL concept, so 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 states a specific verb ('Returns'), a precise resource ('shareable public URL for the document'), and a key distinguishing trait ('viewable without a Billingo login'). This clearly separates it from sibling tools like billingo_get_document or billingo_download_document, which do not provide a public shareable 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 implies the use case: when you need a publicly accessible link that does not require the recipient to have a Billingo account. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide between this and document retrieval/download 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful context that results are grouped into sent, upcoming, and postal-mail reminders, but does not elaborate on what those categories entail or any other behavioral nuances.

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, front-loaded sentence that uses concise, precise wording. Every word contributes to conveying the tool's action and output grouping.

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 single-parameter input, annotations covering read-only and idempotent behavior, and the absence of an output schema, the description adequately explains the return grouping. It does not detail the contents of each reminder category, but this is not critical for invoking 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?

The schema covers the single parameter with a clear 'Document id' description, so schema coverage is 100%. The tool description does not add additional meaning beyond reinforcing that the id refers to a document.

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 tool returns payment reminder events for a document and specifies the grouping into sent, upcoming, and postal-mail reminders. It is specific about the resource and action, though it does not explicitly distinguish itself from sibling tools like get_document_payments.

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: the agent should use this tool when it needs payment reminder events for a document. However, no explicit guidance is given about when to choose this tool over alternatives or any 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?

Beyond the readOnly/openWorld/idempotent annotations, the description adds valuable behavioral detail about error conditions: 4xx errors and 'NavOnlineSzamla is not found' indicate no NAV record exists, not a NAV failure. This helps an agent correctly interpret failures and avoid false conclusions.

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 what is returned, the second gives the usage intent, and the remaining sentences clarify error semantics. Every sentence adds value without unnecessary fluff.

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-only tool with no output schema, the description is complete: it covers return fields, intended use, and error interpretation. An agent has enough information to decide when to invoke it and how to interpret both success and failure responses.

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 already documents the single required parameter 'id' as 'Document id' with full coverage, so the baseline is 3. The description does not add extra detail about where to find the id or its format, but for a single clearly-named parameter, this is acceptable.

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 uses a specific verb and resource: 'Returns the NAV Online Számla reporting status of a document' and names the concrete outputs (transaction id, status, validation messages). It clearly distinguishes this from generic document tools like billingo_get_document by focusing solely on NAV reporting status.

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 explicitly states when to use the tool: 'Use this to check whether reporting succeeded.' It also explains the meaning of errors in context, clarifying that a missing NAV record is not a failure. It does not name alternative sibling tools, but the use case is clear enough for an agent.

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 establish readOnlyHint, idempotentHint, and openWorldHint. The description adds meaningful behavioral context beyond those flags by specifying the data scope (account-level data tied to the API key owner) and the explicit exclusions. It doesn't mention output format or error conditions, but for a zero-parameter read-only tool, the annotation coverage plus content description is sufficient.

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 sentences and every sentence earns its place: what it returns, what it explicitly does not return, and when to use it. It is front-loaded with the core action and resource, followed by the non-obvious exclusion and use case. There is no filler or repetition of schema/annotation 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, zero-parameter, read-only tool with strong annotations and no nested schema, the description fully equips an agent to select and call it correctly. It explains the return scope, the negative case (not a company profile), and the intended use case. No critical information is missing given the tool's complexity.

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 has zero parameters and the schema description coverage is 100%, so there is no parameter ambiguity for the agent. The baseline for zero parameters is 4. The description appropriately focuses on return value semantics rather than parameter details, which adds no value here.

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: 'Returns account-level data for the organization that owns the API key.' It explicitly lists the contained fields (tax code, subscription, NAV Online Számla connection status) and explicitly distinguishes this from a company profile by stating what it does NOT contain. This makes the tool's purpose unambiguous and differentiates it from sibling tools like billingo_get_organization/profile-like 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?

The description gives explicit when-to-use guidance: 'Use it to check the subscription or NAV connection status.' It also provides a clear when-not-to-use signal: 'This is NOT a company profile — it contains no name, id or address.' This effectively prevents an agent from invoking this tool for company profile lookups, even without naming alternative sibling tools explicitly.

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 openWorldHint, so the core safety profile is covered. The description adds only the cardinality ('a single') and the lookup mechanism, but it does not disclose not-found behavior, error handling, or response shape beyond what annotations and schema imply.

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, front-loaded sentence with no filler or redundant clauses. Every word earns its place for such a simple getter tool.

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 one required parameter and read-only/idempotent annotations, the description is nearly complete. It lacks explicit not-found/error behavior and the exact shape of the returned partner object, but these are not critical for correctly selecting and invoking this simple getter.

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%: the id parameter is already described as 'Partner id.' The tool description simply says 'by id,' which adds no new semantic value 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 states a specific verb ('returns'), a clear resource ('a single partner'), and the lookup key ('by id'). This distinguishes it from plural/list siblings like billingo_list_partners and from other get_* 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?

The description implies the tool should be used when a specific partner id is already known, but it does not explicitly mention alternatives or when not to use it. The presence of billingo_list_partners as a sibling makes the lack of explicit routing guidance a minor gap.

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 openWorldHint, so the tool's safety profile is covered. The description adds the return cardinality ('a single product') but does not disclose behavior such as what happens when the id is not found. This is acceptable but not richly 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?

The description is a single, front-loaded sentence with no filler. Every word contributes to explaining what the tool does, making it highly scannable for an AI agent.

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, one-parameter getter, the description is nearly complete: it identifies the input (id) and the output (a single product), and annotations cover safety and idempotency. It does not mention not-found or error behavior, but that is a minor gap given the tool's low complexity.

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 the single parameter 'id' is already described as 'Product id.' The description merely restates the parameter usage ('by id') without adding new semantic detail, so it adds no value 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 uses a specific verb ('Returns') with a clear resource ('product') and identifies the retrieval key ('by id'). The word 'single' distinguishes it from sibling tools like billingo_list_products, making its purpose 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 clearly implies the intended use case: retrieving one product when an id is known. It does not explicitly name alternatives such as billingo_list_products for bulk retrieval, but the singular 'by id' phrasing provides clear context and leaves little room for misuse.

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, openWorldHint=true, and idempotentHint=true, covering the safety profile. The description adds only that the returned quantity is 'current', which is mild behavioral context but does not disclose potential caveats such as data freshness, units, or whether the quantity represents available vs. physical stock. Since annotations carry most of the burden, a mid-range score is appropriate.

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, front-loaded sentence with no filler or repetition. It conveys the action, the resource, and the returned information efficiently.

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 one-parameter getter with rich annotations, the description is nearly complete. It tells the agent what will be returned ('current inventory quantity'). However, since there is no output schema, a slightly more explicit statement about the return format could improve completeness, though it is not essential for such a trivial 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?

The schema already provides 100% coverage with a clearly described 'id' parameter. The description does not add any parameter-level meaning beyond what the schema states, so the baseline score 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?

The description names a specific verb ('Returns'), a specific resource ('inventory quantity'), and the target ('a product'). This clearly distinguishes it from siblings like billingo_get_product, which would return broader product details. The tool's name and title reinforce the purpose without adding confusion.

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 no guidance about when to use this tool versus alternatives such as billingo_get_product or billingo_list_products. There is no stated context, prerequisite, or condition that would help an agent choose it over similar product-related 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering the safety profile. The description adds only that it returns a single spending, which is consistent but does not disclose additional behavioral traits such as not-found behavior or response format. It does not contradict 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?

The description is a single sentence with no filler. It front-loads the core action and resource and avoids repeating the tool name or restating schema details.

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 single-parameter read tool with strong annotations and no output schema, this description is sufficient. An agent knows the input (id) and the expected result (a single spending) without needing additional detail.

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%: the id parameter is documented as 'Spending id.' The description's 'by id' adds no new semantic meaning beyond the schema. Baseline 3 is appropriate because the schema fully explains the 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?

Description uses a specific verb ('Returns') and resource ('single spending') with an explicit lookup key ('by id'). It clearly differentiates from the sibling billingo_list_spendings, which returns multiple spendings, and aligns with the get-by-id pattern of sibling tools like billingo_get_partner.

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 when a specific spending id is known and a single spending is needed, and it implicitly contrasts with billingo_list_spendings. However, it does not explicitly state when to prefer this tool over list_spendings or mention any exclusions or prerequisites.

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 readOnlyHint, idempotentHint, and openWorldHint annotations already establish that this is a safe, read-only operation. The description adds the scoping detail that accounts are those 'configured on the organization,' but does not disclose additional behavioral traits such as pagination behavior or response characteristics.

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 with no redundant wording, and the main verb and resource appear first. Every word contributes to the purpose without unnecessary 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 straightforward list operation with optional pagination parameters and read-only annotations, the description provides the essential resource and scope. It does not describe the response shape, but given the title and sibling get_bank_account, an agent can reasonably infer a list of bank account objects; a mention of pagination defaults could slightly improve completeness.

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 100% schema coverage, the input schema already documents page and per_page with descriptions and ranges. The description adds no parameter-specific meaning, so it meets the baseline but does not exceed it.

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 uses the specific verb 'Lists' with the resource 'bank accounts configured on the organization,' clearly conveying the operation's scope. It contrasts with sibling billingo_get_bank_account, which targets a single account, making the list-vs-get distinction apparent.

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 indicates this tool is for enumerating the organization's configured bank accounts, which is clear context for choosing it over billingo_get_bank_account. However, it does not explicitly state when not to use it or mention alternatives, so the guidance is implicit rather than directive.

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, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful domain context about blocks being required for invoice creation, but does not disclose pagination behavior, sort order, or response shape. This is acceptable given the annotations but adds only modest behavioral insight.

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 wasted words. The main action is front-loaded, and the explanatory clause about why block IDs matter is directly relevant rather than 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 simple read-only list tool, the description plus annotations and full schema coverage are largely sufficient. There is no output schema, so an explicit note about return fields would be slightly helpful, but the tool's purpose is clear enough that this is a minor 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 100%, with page and per_page already documented in the schema. The description adds no extra parameter-level detail, so the baseline of 3 applies: the schema carries the semantic weight.

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 uses a specific verb and resource ('Lists document blocks') and further clarifies the domain concept as 'invoice number ranges.' It does not explicitly contrast with sibling list tools like billingo_list_documents, but the resource is distinct and clearly 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 description gives a clear use context: 'Every document belongs to a block; you need a block id to create an invoice.' This signals when the tool is needed, though it does not explicitly mention alternatives or 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 communicate read-only, idempotent, open-world behavior. The description adds useful behavioral detail: results are newest first and the returned set includes more than the invoice/receipt type filter values. It does not detail pagination behavior, but the schema covers per_page limits and defaults.

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 compact sentences with no filler. The first sentence front-loads the action, scope, and ordering; the second summarizes the filter dimensions. It earns its place without repeating the full schema.

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 read-only list tool with no required parameters, rich schema descriptions, and safe annotations, the description is complete. An agent can select the tool and form valid filter-based requests without missing essential information.

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 descriptions cover most parameters, so the description's filter summary maps cleanly onto existing fields: type, start/end_date, partner_id, payment_status/method, and block_id. This grouping adds mild semantic value, but it does not introduce syntax or meanings 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 a specific verb and resource: 'Lists documents', and adds scope ('invoices, receipts, proformas, drafts and more') plus ordering ('newest first'). This clearly distinguishes it from single-document siblings like get_document or download_document.

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 establishes a clear listing context and explains available filters, so an agent can infer it is for retrieving a filtered collection. However, it does not explicitly contrast with sibling tools or state when not to use it, stopping just short of full 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 the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower. The description adds genuine behavioral context beyond the annotations: the default result ordering ('newest first') and the scope of the search ('over the partner name'). No contradiction with 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 sentences with zero filler. The core purpose is front-loaded in the first sentence, and the second sentence adds the two supported features. Every word 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?

For a low-complexity read-only list tool with 100% parameter documentation and the safety profile carried by annotations, the description is largely sufficient. Minor gaps remain: the return shape and pagination metadata are not described (no output schema exists), and no explicit guidance distinguishes this from billingo_get_partner.

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 the schema independently documents page, query, and per_page with defaults. The description's mention of 'paging and a free-text search over the partner name' largely restates the schema's query description and adds no new parameter-level meaning, so the 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?

States a specific verb and resource: 'Lists partners (customers), newest first.' The parenthetical clarifies the domain term, and the ordering detail adds precision. As a plural list operation it is readily distinguishable from the single-resource sibling billingo_get_partner and from list tools on other resources like billingo_list_products or billingo_list_documents.

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 through 'Lists partners' plus the paging and free-text search capabilities, but it never explicitly states when to choose this tool over alternatives. It does not route single-partner lookups to billingo_get_partner or mention any exclusions, so usage context 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 already provide readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is well covered. The description adds only the catalogue scope ('products and services') and does not disclose additional behavioral details such as pagination behavior or result ordering, but it also does not contradict 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?

The description is a single front-loaded sentence with no filler. It states the action and resource directly and wastes no words.

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 fully documented optional parameters and strong annotations, the description is nearly complete. A short mention of the return shape or a pointer to the singular get_product sibling would make it fully self-contained, but nothing essential is missing for a basic call.

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 page, query, and per_page are already fully documented in the input schema. The description adds no parameter-level meaning beyond framing the tool as searching the product catalogue.

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 action ('Lists') and the resource ('products and services from the product catalogue'). It conveys a broad listing operation, though it does not explicitly contrast itself with the sibling billingo_get_product beyond the plural 'Lists'.

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 listing purpose is clear, and the optional page/query/per_page parameters imply catalogue browsing. However, the description does not explicitly say when to prefer this over billingo_get_product or billingo_get_product_quantity, so usage guidance is mostly 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 already carry the safety profile (readOnlyHint, openWorldHint, idempotentHint), lowering the burden on the description. It adds the date-range filtering behavior and clarifies that 'spendings' means 'costs', but it does not mention pagination behavior, result ordering, or what happens when no filters are supplied. No contradiction with 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 with zero filler: the verb and resource come first, and the optional-filter qualifier follows as secondary context. Every word 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?

For a low-complexity list tool with rich annotations and fully self-documenting parameters, the definition is nearly complete. There is no output schema so the return shape is undocumented, and there is no explicit routing to billingo_get_spending for single-record lookups, which keeps it from a 5.

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 all four parameters (page, per_page, start_date, end_date) individually documented, so the baseline is 3. The description's date-range phrasing adds nothing beyond what start_date and end_date already specify.

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 ('Lists') and resource ('recorded spendings (costs)'), and the qualifier 'optionally filtered by date range' adds useful scoping. It is clearly a bulk read operation, but it does not explicitly distinguish itself from the sibling billingo_get_spending, which would be required for 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 filtered by date range' implies the main use case (bulk retrieval with optional date bounds), but there is no explicit statement of when to prefer this tool over billingo_get_spending or the other list siblings. Usage context is implied rather than directly stated.

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 and idempotentHint, so the safety profile is covered. The description adds the output format (PDF receipt) and POS sizing intent, which is useful, but it does not disclose additional behavioral details such as error handling, authorization requirements, or document availability behavior.

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 front-loaded sentence with no filler. It efficiently conveys the output type, the target use, and the format in one line.

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-only tool with full schema coverage, the description plus schema adequately cover what an agent needs: the document id, the size, and the PDF output. An explicit pointer to sibling document-retrieval tools would strengthen routing, 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?

The input schema already fully documents both parameters: id as 'Document id' and size as thermal paper width with 58/80 enumeration. The description adds no new parameter-level meaning beyond reinforcing the POS sizing context, 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 description uses a specific verb ('Returns') and clearly identifies the deliverable: a printable PDF receipt for a document, sized for a POS thermal printer. This distinguishes it from sibling document tools like billingo_download_document by its receipt-specific POS purpose.

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 'sized for a POS thermal printer' gives a clear contextual signal for when this tool should be chosen over generic document download or public-URL tools. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full guidance.

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