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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing the content of the response (including the is_test flag and organization tax/VAT/offline/SMS settings), which is meaningful since no output schema exists. It omits auth requirements and any caching/rate-limit 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?

Front-loaded with the action and subject, followed by a short imperative sentence telling the agent when to call it. The parenthetical field list is dense but earns its place because no output schema documents the return shape.

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 full burden of describing the return value and does so across both the cashier and organization objects. It is complete enough to call correctly, though it could note whether organization data is always present.

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, so the schema imposes no semantic burden and the baseline for a no-param tool is 4. The description correctly implies a no-argument call by framing the result as the server's own identity.

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 ('Returns the cashier this server is signed in as') and enumerates the returned payload (name, permissions, signature type, is_test, organization fields). This clearly separates it from siblings like get_cash_register or get_current_shift, which operate on registers and shifts rather than identity.

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?

'Call this first to learn whose data the other tools will show' gives explicit ordering guidance and a clear context in which the tool is useful. It stops short of naming a when-not condition or an alternative, but no plausible alternative exists for an identity endpoint.

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, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: what fields come back in each mode, the meaning of offline_mode, and that the open shift is included.

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 with no filler; the core behavior is front-loaded and the conditional cases are laid out in a compact parallel structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does enumerate the fields returned in each mode, which is adequate for a single-optional-param read tool. It stops short of describing nesting or error behavior, but nothing essential for invoking it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema documents the UUID pattern, so the baseline is 3. The description goes further by explaining the semantic consequence of supplying versus omitting cash_register_id, which is genuinely more than the schema conveys.

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 ('Returns one cash register (ПРРО)') and immediately differentiates the two operating modes via the presence or absence of cash_register_id. It does not name sibling tools like list_cash_registers, so it is clear but not sibling-differentiating.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes the two calling contexts: with cash_register_id you get full details plus the open shift; without it you get the register bound to CHECKBOX_LICENSE_KEY. It gives clear context but names no alternative tool for listing multiple registers and states no 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds genuinely non-annotated behavior: the exact content of the response and, importantly, the no-open-shift case, which tells the agent how to interpret an empty result.

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, front-loaded with the verb and resource, and every clause carries information. The parenthetical field list is dense but justified because there is no output schema to document the payload.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must sketch the return shape, and it does (status, opening time, register, balances, per-tax totals) plus the empty-state behavior. It stops short of explaining field formats or any auth/offline caveats for an openWorld tool, but nothing essential is missing for a parameterless read.

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?

Zero parameters, so the baseline is 4 and there is no schema surface the description needs to compensate for. The description correctly avoids inventing parameter details, though it also adds nothing 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?

States a specific verb and resource ('Returns the active shift of the signed-in cashier') and enumerates the payload (status, opening time, cash register, running balance, per-tax totals), so the agent knows exactly what comes back. It implicitly distinguishes itself from get_shift/list_shifts by being the no-argument, signed-in-user variant, but never names a sibling 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 only implied: the 'signed-in cashier' scoping and the empty-shift note suggest when this tool is appropriate, but there is no explicit when-to-use, when-not-to-use, or pointer to get_shift/list_shifts for other cases. An agent must infer the routing from the absence of parameters.

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 it read-only, idempotent, and non-destructive. The description adds valuable domain context by citing Checkbox's 36-hour and 168-hour offline limits and clarifying that durations are passed through as returned by the API, helping the agent interpret results. It does not mention rate limits or auth needs, but the annotations carry the safety profile well.

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 paragraph that front-loads the core purpose and then adds domain limits and a note on duration formatting. Every sentence contributes, though the final sentence about durations is slightly tangential and could be trimmed.

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 annotations covering the safety and idempotency profile and the schema fully documenting parameters, the description completes the picture by stating what is returned (codes, sufficiency, sessions, time) and the relevant business constraints. No output schema is needed, and nothing an agent requires to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both from_date and to_date are fully documented in the schema with format and timezone examples. The description mentions an optional period but adds no additional syntax or format details beyond what the schema provides, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Reports') and resource ('offline mode status') and enumerates exactly what is returned: available offline fiscal codes, sufficiency, offline sessions, and total offline time. It is clearly distinguishable from siblings like get_current_shift or get_cash_register, which cover different domains.

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 by stating the optional period filter, which tells an agent it can query without dates for a full status or with dates for a bounded window. However, it does not explicitly state when to prefer this over other status tools or when-not to call it, keeping it below a 5.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: the result contains customer PII (name, phone, address) and there is an expectation not to echo it unprompted — a data-handling constraint the agent could not infer from annotations or schema.

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, zero filler. The return-content summary is front-loaded and the PII caveat follows immediately; every clause carries 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?

With no output schema, the description usefully enumerates the returned sections (status, payment, receipt draft, delivery) and flags the PII, which is what an agent most needs to know before calling. It is slightly thin on lookup behavior — e.g. what happens if the order is not found, or how whole_organization affects visibility — but 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% and the order_id description already explains the UUID source (list_orders field "id") and whole_organization explains its own semantics. The description adds no parameter-level meaning, so the baseline 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?

States a specific verb and resource ("Returns one order") and enumerates what the payload contains: status, payment, receipt draft, delivery details. The singular "one order" implicitly distinguishes it from list_orders, but 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 only implied: fetching a single order by id is the obvious reading, and the PII instruction ("do not repeat it unless the user asks") gives downstream handling guidance. There is no explicit statement of when to prefer this over search_receipts or get_receipt, nor any prerequisite for the order_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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them: the output is text-only via the API, and it enumerates what the report contains (totals by tax rate, payment form, returns, cash in register, each Z-report with number and date).

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 that front-loads the verb, resource and scoping key, then lists the report contents. No filler or repetition, though the inline enumeration is long enough to be slightly heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully compensates by describing the returned text's content and noting the API is text-only. Combined with annotations covering the safety profile, an agent has nearly everything needed; only explicit sibling routing 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 description coverage is 100%, and the schema documents from_date, to_date and short with ISO 8601 examples, so baseline 3 applies. The description mentions the date range but adds no format or semantics beyond what the schema already provides, and never addresses the 'short' flag.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: 'Returns the periodical report ... of the cash register ... for a date range.' It also enumerates the report's contents (Z-report totals by tax rate and payment form, returns, cash in register). It does not explicitly differentiate itself from siblings like get_report or list_reports, 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?

Usage is implied by the date-range framing and the mention of CHECKBOX_LICENSE_KEY, but there is no explicit when-to-use vs when-not, and no routing to get_report or list_reports for other report types. Context is inferable but not 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 readOnly, idempotent and non-destructive, so the safety profile is covered. The description goes beyond them by disclosing the eventual-consistency behavior ('still being created'; retry after a second) and the concrete contents returned per format, which are not derivable from 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?

Front-loads the resource and scope, then the two format outcomes, then the retry caveat. Dense and mostly waste-free, though the parenthetical '(чек)' and the somewhat compressed format sentences slightly reduce readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly carries the burden of explaining return values and does so for both formats, plus the transient 'still being created' state. What it does not cover, such as error shape or whether tax_url may be absent for pending receipts, is minor.

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 baseline is 3. The description adds genuine meaning to the 'format' enum by enumerating what the json variant contains (goods, payments, taxes, discounts, fiscal number, status, tax_url) versus the literal printed text, beyond the schema's brief 'structured object' / 'printable plain-text form'.

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 ('Returns one receipt') and scopes it to a single record, which implicitly separates it from the sibling search_receipts. It does not name any sibling explicitly, so differentiation is inferable rather than stated.

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 (fetch a known receipt by id), and it adds a useful retry instruction for freshly created receipts. However, there is no explicit when-to-use-vs-alternatives guidance, e.g. nothing telling the agent to prefer search_receipts when the id is unknown.

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/openWorld, so the safety profile is covered. The description goes beyond them by disclosing exactly what the json payload contains (totals per payment form and tax rate, receipt counts, rounding, cash balance) and that text mode is the printed form — genuinely useful for a tool with no output schema.

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, front-loaded with the tool's scope and followed by the format semantics. The internal field enumeration is dense but each item is informative; little wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and full schema coverage, the description supplies the missing return-value context precisely. It omits only edge behavior (e.g., unknown/closed report ids), which is a minor gap for a read-only lookup.

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 enum descriptions already document the format parameter, so the baseline is 3. The description earns above baseline by spelling out the payload each format returns, giving the agent a reason to choose json vs text beyond the schema's bare wording.

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 ('Returns one X- or Z-report') and is distinguishable from list_reports and get_periodical_report by its singular, id-based retrieval scope. It does not explicitly contrast itself with those siblings, which keeps it 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?

There is no guidance on when to prefer this over list_reports or get_periodical_report, nor any prerequisite or precondition. Usage is only implied by the required report_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 declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: the payload is complete rather than partial, and the embedded Z-report is only present once the shift is closed, which is a conditional-state detail the annotations cannot convey.

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 no preamble or filler. The long field enumeration is dense but each item is informative about the return shape, so it earns its space; it could have been trimmed slightly for a short description field.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing the return value and does so thoroughly, including the conditional Z-report. What is missing is any guidance on usage relative to sibling shift tools and on the failure case for an unknown id.

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 one parameter with 100% schema description coverage (shift_id, UUID with a regex pattern), so the schema fully carries parameter semantics. The description adds nothing about shift_id, its format, or where to obtain it, which is the baseline-3 outcome when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (returns) plus resource (one shift) with an enumerated payload: status, cashier, cash register, balance, per-tax totals, opening/closing transactions, Z-report. It is clear what the tool does, but it never distinguishes itself from siblings like get_current_shift or list_shifts, so the by-id retrieval scope is only implied.

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?

No when-to-use, when-not-to-use, or alternative guidance is given. An agent must infer that this fetches a single shift by id and that get_current_shift or list_shifts cover the other cases; nothing in the text routes 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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real context beyond them: results are scoped to registers 'available to the cashier' (an authorization boundary) and each entry conditionally includes the currently open shift.

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 resource and returned fields come first and the downstream routing tip is second. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by naming the fields each register carries, including the conditional open shift. Paging behavior is covered by the schema, so nothing an agent needs 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 description coverage is 100%, so limit, offset, in_use and fiscal_number are already fully documented in the schema. The description mentions none of the filtering parameters, so it adds no meaning beyond the structured fields; 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 (Lists) and resource (cash registers / ПРРО), and enumerates the returned fields (fiscal number, address, branch, online/offline mode, open shift). An agent can distinguish it from the singular get_cash_register sibling without opening either 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?

The second sentence gives downstream usage ('use the returned ids to filter receipts and reports'), which implies context, but never states when to prefer this over get_cash_register, get_current_shift, or list_shifts. No exclusions or prerequisites are given.

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, openWorldHint and destructiveHint=false, so safety is covered. The description goes beyond that by explaining the domain lifecycle (external system creates, courier fiscalizes after delivery and payment) and by naming the fields returned (status, payment state and method, linked receipt id) plus what is deliberately excluded. Pagination and default-clamping behavior live only in the schema, not here.

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, front-loaded with the core purpose and followed by the return/exclusion note. Every clause carries information: the domain definition, the lifecycle, the returned fields, and the routing hint. The Ukrainian gloss on 'orders' is a minor cost in a bilingual product context, not padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly compensates by enumerating the meaningful return fields and flagging the omitted ones with a pointer to get_order. All 8 optional parameters are fully documented in the schema, and the read-only annotation set covers the safety profile, so an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 8 parameters, including formats, defaults and the ISO-8601 offset guidance, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond what is already documented, which is the expected baseline when coverage is complete.

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 (Lists) plus the resource (orders) and then defines what an order actually is in this domain: a draft receipt created by an external system, pending fiscalization after delivery and payment. That definition alone separates it from receipt- and shift-oriented siblings, and it explicitly names get_order as the tool holding the omitted customer details.

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?

Gives clear context for when this is the right call (browsing draft/fiscalization-pending orders) and points to get_order for customer delivery details, which is a real alternative-selection signal. It stops short of stating exclusions such as whether fiscalized orders are included or when to prefer search_receipts 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 readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description contributes extra substance by describing the report contents returned. It does not mention pagination behavior or default caps, but with annotations this is above the required bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: what is listed, how to filter, and where to go for alternatives. The core purpose is front-loaded before the routing hint.

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 filtered list with a rich 9-parameter schema and no output schema, the description supplies identity, content of results, filter axes and sibling routing. Only the return shape and paging behavior are left implicit, which the schema partly covers.

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 every parameter is already documented with patterns, defaults and constraints. The description's mention of the filterable dimensions (period, shift, cash register, serial, report type) mirrors the schema without adding format or semantics beyond it, making the baseline 3 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?

States a specific verb (Lists) and resource (X-reports and Z-reports), and goes further by defining each type ('interim, non-fiscal' vs 'end of shift') and the payload returned (receipt counts, cash balance, totals per payment form). An agent can tell it apart from get_report and the shift/receipt siblings without opening a 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?

Explicitly routes to get_report for tax breakdowns or printable text, which is a clean alternative-selection rule. It also lists the filter dimensions, giving context for when this tool applies. It stops short of stating when NOT to use it (e.g. single-report retrieval), so a 4 rather than a 5.

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, destructiveHint=false, openWorldHint), so the bar is lower, yet the description adds two real behavioral facts: the page-size cap of 50 for this endpoint and the CHECKBOX_LICENSE_KEY requirement for cash_register scope. It does not describe ordering guarantees or result-shape nuances, but those are minor here.

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?

Dense but front-loaded: the resource and returned fields come first, then scope semantics, then the alternative-tool pointer. Every sentence carries information, though the parenthetical license key and cap clauses make it slightly heavy for a list 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?

With no output schema, the description carries the burden of describing what is returned and does list the key fields (status, times, balance, Z-report reference). Paging and filtering are fully covered by the schema, so the remaining gap is only the absence of sorting/response-shape detail, which is not material for a 7-param list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description still adds meaning by explaining the semantics of the scope enum (whose shifts are returned, license gating) and by overriding the generic page-size cap with an endpoint-specific 50. It adds nothing for limit/offset/from_date/to_date/statuses beyond what the schema already documents.

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 gives a specific verb and resource ("Lists shifts") and enumerates the returned fields (status, open/close times, balance, Z-report reference). It explicitly distinguishes itself from the sibling get_shift ("Use get_shift for the full record"), so an agent can route between them without opening 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?

It states the default scope behavior and the condition for the alternative ("scope 'cash_register' lists shifts of the cash register behind CHECKBOX_LICENSE_KEY, whoever opened them"), and names get_shift as the fuller alternative. It stops short of stating when a shift listing is inappropriate (e.g., for a single known shift), leaving one inference to the 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 declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds real value beyond that by disclosing the shape of the returned records and the cross-entity meaning of the numeric code (what a receipt line's tax list points at), which no annotation conveys. It stops short of noting ordering, pagination, or empty-result behavior, so it is not a 5.

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, front-loaded with the action and resource, then the returned field set. Every clause carries information the agent cannot get from the empty schema or the annotations, and the receipt-line note is a compact cross-reference 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?

With no parameters, no output schema, and read-only annotations, the description carries the burden of describing the return payload and does so field by field. It could be slightly more complete by indicating whether the list is exhaustive or how it is ordered, but nothing essential to invoking the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so the baseline is 4 and there is nothing in the schema for the description to compensate for. The fields it lists are output attributes rather than inputs, which is the right thing to document 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?

States a specific verb and resource ("Lists the tax rates configured for the organization") and enumerates the exact fields returned, including the numeric code, symbol, label, rate, extra rate, and price-inclusion flag. No sibling in the provided set (receipts, orders, registers, shifts, reports) overlaps with tax-rate configuration, so an agent can route to it unambiguously.

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: the agent can infer this is the lookup for tax-rate definitions, reinforced by the note that receipt lines refer to the numeric code. There is no explicit when-to-use statement, no prerequisite mention, and with zero parameters there are no filtering alternatives to distinguish from.

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, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that: the exact return fields (code, name, price in kopecks, barcode, UKTZED, group, tax rates, stock count) including a unit convention, plus the caveat that the catalogue may be empty for organizations that don't track goods in Checkbox.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, then returns, then the empty-catalogue caveat; nothing is redundant. The return-field enumeration is long but earns its place since there is no output 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?

With no output schema, the description carries the return-shape burden and does so, and it flags the empty-result scenario. Remaining gaps are minor: no mention of search-match semantics, total-count/paging behavior, or that limit/offset come from the 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?

Schema description coverage is 100%, with limit/offset clamping, default values and the group_id UUID pattern all documented in the schema itself. The description adds no syntax or behavioral detail about query matching (substring, prefix, fuzzy) or how group_id interacts with query, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (searches) and resource (the goods catalogue / номенклатура in Checkbox), and no sibling tool touches goods, so the agent can route here unambiguously versus receipts, orders, shifts, or reports. The parenthetical local term also disambiguates the domain vocabulary.

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 never says when to reach for this tool over alternatives, nor how the parameters select behavior (full scan vs query vs group_id filtering). The only conditional statement is about the catalogue being empty, which is a data caveat rather than usage 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 (readOnly, idempotent, non-destructive, openWorld), and the description adds two genuinely useful behavioral facts: results are scoped to the signed-in cashier by default, and the API cannot filter by status or type. The stated return fields are helpful too, though the default-scope detail partially overlaps the all_cashiers schema description.

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?

Front-loaded with purpose and filter dimensions, then return shape, then the API limitation, then the sibling routing hint. Every sentence carries distinct information 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 an 11-parameter read tool with no output schema, the description compensates well by summarizing the returned row fields and flagging the client-side filtering requirement and default cashier scoping. Nothing essential to correct invocation 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 description coverage is 100% and all 11 parameters are documented there, including defaults, caps, ISO 8601 format and UUID patterns. The description restates the filter dimensions but adds no syntax or format detail beyond the schema, so the baseline 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?

States a specific verb (Finds) and resource (receipts) and enumerates the exact filter dimensions available: period, fiscal number, barcode, shift, cash register, branch. This makes it immediately distinguishable from siblings like get_receipt or search_goods.

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?

Names the alternative tool and the condition that selects it: 'Use get_receipt for the full record.' It also warns that status/type filtering must be done client-side, which tells the agent this is a broad list-and-filter tool rather than a targeted lookup.

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