Server Quality Checklist

Tool Scores

• x5_get_categoriesC
  2.3/5.0
  Behavior3/5

  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 useful output context: it returns source category codes and counts, and warns against inventing category names. However, it does not explain grouping behavior, date-range semantics, or response format.

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

  Conciseness2/5

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

  The description is very brief, but brevity here crosses into under-specification. It is a fragment plus a warning, with no structured explanation of the operation, parameters, or output. It is not appropriately concise; it is simply incomplete.

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

  Completeness2/5

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

  With no output schema, the description needed to describe return values and parameter meaning, but it only gives a minimal hint about category codes and counts. The date range, grouping options, network selection, and relationship to similar category tools are left unexplained, making this inadequate for reliable invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must explain the parameters, but it does not mention from, to, groupBy, or network at all. The only meaningful content is about categories and counts, which does not clarify how to set any of the four parameters correctly.

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

  Purpose3/5

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

  The description identifies the resource as categories and hints at the output (source codes and item counts), but it is a noun phrase with no explicit verb like 'returns' or 'gets'. It also does not distinguish this tool from siblings such as x5_get_category_spending, so the purpose remains somewhat vague.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus alternatives, no exclusions, and no context about date ranges or network filters. The sentence 'Названия категорий не выдумываются' is an instruction about output handling, not usage guidance.

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

• x5_get_product_historyB
  3.4/5.0
  Behavior3/5

  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. The description adds a useful behavioral caveat that networks and units are not mixed in the summary, but it does not disclose pagination behavior, date range handling, or response structure.

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

  Conciseness5/5

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

  Two short sentences carry the core purpose, the prerequisite lookup, and an important output caveat with no wasted words. The information is front-loaded and easy to parse.

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

  Completeness2/5

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

  A six-parameter tool with no output schema and zero parameter coverage in the description needs more context. The description omits meaning for the date range, pagination, and network parameters, and does not describe the response shape at all.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. It clarifies the meaning of pluId by pointing to x5_search_purchases and hints at network semantics, but it does not explain from/to, limit, offset, or the network enum values.

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

  Purpose4/5

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

  The description names a specific resource (PLU) and the data returned (history, prices, quantity), making the core purpose clear. It does not explicitly distinguish itself from the sibling x5_get_price_changes, which could plausibly overlap with price history, so it loses the top score.

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

  Usage Guidelines4/5

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

  The description explicitly tells the agent to find PLU via x5_search_purchases, providing a clear prerequisite and workflow. It does not state when to avoid this tool or how it compares to related siblings like x5_get_price_changes.

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

• x5_get_receiptB
  3.4/5.0
  Behavior4/5

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

  Beyond the readOnly and idempotent annotations, the description discloses a critical behavioral detail: at most 500 items are returned, while itemsCount carries the true total. This adds meaningful context that annotations do not provide.

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

  Conciseness5/5

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

  A single, front-loaded sentence with zero filler. Every word earns its place, and the key constraint (500-item limit) is presented immediately.

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

  Completeness4/5

  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, the description is nearly sufficient: it conveys the return scope and pagination semantics. It omits error behavior or receipt-not-found handling, but these are not critical for such a straightforward retrieval.

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

  Parameters2/5

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

  The schema has one required id with no description, and schema coverage is 0%. The description does not explain that id is the receipt identifier or any expected format, so it adds no parameter-level meaning; the tool name partially compensates but the description itself fails.

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

  Purpose4/5

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

  The description states the tool returns one receipt with up to 500 line items, which clearly identifies the resource and distinguishes it from list-type siblings like recent receipts or search. However, it lacks an explicit verb and does not name sibling alternatives, so it stops short of a top score.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus siblings such as x5_search_purchases or x5_get_recent_receipts. The intended use case (having a receipt ID) is only implied by the name and schema, not stated.

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

• x5_get_spendingB
  3.4/5.0
  Behavior4/5

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

  The annotations already mark this as read-only, idempotent, and non-destructive, and the description adds valuable behavioral detail: spending is computed without double-counting by line items, the period is inclusive, and null network values mean 'unknown.' This goes beyond the annotations and prevents a common misinterpretation, though the phrase 'сеть по исходному коду' is somewhat cryptic and not fully clarified.

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

  Conciseness4/5

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

  The description is compact and front-loaded, conveying the most important behavior (receipt-sum spending) in the first clause. The second clause is telegraphic but economical. It is not padded with filler, though the phrasing of 'сеть по исходному коду' could be clearer without adding much length.

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

  Completeness3/5

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

  With no output schema, the description does not mention what the tool returns (e.g., a single total or a time series), which is a notable gap for an aggregation tool. It covers the key semantic details of the date range and null handling, but the network enum values and their meaning are not explained, and the lack of any return-type hint makes the definition only partially complete.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate for the lack of property docs. It usefully explains that the from/to period is inclusive and that null means 'unknown,' but it does not mention the groupBy parameter at all. The groupBy enum is self-explanatory, but the description does not carry enough weight to fully cover all four parameters.

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

  Purpose4/5

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

  The description clearly states the tool reports spending ('Траты') based on receipt sums rather than itemized products ('по суммам чеков, без удвоения по товарам'), which identifies both the resource and a key semantic distinction. It does not explicitly name a sibling or contrast with x5_get_category_spending, so it loses the top point, but the purpose is specific and unambiguous.

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

  Usage Guidelines2/5

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

  There is no explicit guidance about when to use this tool versus alternatives such as x5_get_category_spending or x5_search_purchases. The phrase 'без удвоения по товарам' implies it should be used for receipt-level totals, but no direct 'use this when…' or 'use that instead…' guidance is provided.

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

• x5_get_category_spendingA
  3.8/5.0
  Behavior4/5

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

  Annotations already mark the operation as read-only, non-destructive, and idempotent. The description adds meaningful behavioral context beyond that: the value is computed as pricePromo × quantity and the price semantics are unconfirmed, which tells the agent the result is approximate and may differ from actual receipts.

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

  Conciseness5/5

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

  Two succinct sentences: the first front-loads the purpose and formula, the second adds a necessary data-quality caveat. There is no filler.

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

  Completeness3/5

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

  The core estimation logic and caveat are covered, but with 5 parameters, no output schema, and zero parameter descriptions, several details an agent needs (e.g., what network means, how limit/categoryCode affect results, and what the response looks like) are left implicit.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not compensate. It never explains the meaning or formatting of from, to, limit, network, or categoryCode; the word 'categories' only mirrors the existing schema property name.

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

  Purpose5/5

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

  The description states a specific action ('ОЦЕНКА' / preliminary estimate) and a specific resource ('трат по категориям'), and even gives the computation formula (pricePromo × quantity). The disclaimer 'это не точные итоги чеков' sets it apart from receipt-level siblings like x5_get_spending and x5_get_recent_receipts.

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

  Usage Guidelines4/5

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

  It clearly frames the tool for preliminary estimates, which is an explicit usage context, and warns that it is not exact receipt totals, serving as a when-not. However, it does not name an alternative tool for exact spending figures.

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

• x5_get_price_changesA
  3.9/5.0
  Behavior4/5

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

  Annotations already mark the tool as read-only and idempotent, so the description does not need to restate that. It adds behavioral nuance by noting the comparison is done separately by network and unit and that promotions may explain price differences, which helps set expectations about result interpretation.

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

  Conciseness5/5

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

  The definition consists of two short sentences with no filler. The core comparison logic is front-loaded, and the promotions caveat adds useful interpretive context without bloating the text.

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

  Completeness3/5

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

  The description is adequate for the primary behavior but omits details an agent might need: there is no output schema, yet the response format (which PLUs, which prices, how the limit applies) is not described, and no sibling routing guidance is offered. Given the annotations cover safety, this is a moderate gap rather than a severe one.

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

  Parameters3/5

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

  With zero schema description coverage, the description must carry parameter meaning, and it does for the core fields: 'period' maps to from/to and 'network' is explicitly referenced. However, limit and categoryCode receive no semantic explanation, though their names and schema constraints leave them partially inferable.

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

  Purpose5/5

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

  The description specifies a concrete action—comparing the first and last known price per PLU—and scopes it by period, network, and unit. This distinguishes it from sibling tools like x5_get_product_history or x5_search_purchases, which target individual product histories or purchase records rather than aggregate endpoint price comparisons.

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

  Usage Guidelines3/5

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

  The description implies a clear use case—analyzing price movement between period endpoints—but never states when to choose this tool over the listed siblings, nor any when-not conditions. An agent must infer the selection criteria from the stated behavior.

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

• x5_get_sync_statusA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about which aspects the tool reports (network, freshness, last sync results) but does not disclose output format or additional behaviors. 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.

  Conciseness5/5

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

  Two short, efficient sentences with no filler. The first sentence enumerates the status dimensions, the second gives the usage directive. Every word contributes value.

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

  Completeness4/5

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

  For a parameterless, read-only status tool, the description gives the essential content (what the status spans) and when to use it. There is no output schema, so a bit more detail on return shape could help, but the description provides enough for an agent to invoke and interpret the result.

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

  Parameters4/5

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

  This tool has zero parameters and 100% schema description coverage with an empty schema. Baseline 4 applies for no-parameter tools; there are no parameter semantics to explain and the description does not mislead.

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

  Purpose4/5

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

  The description clearly identifies the resource (sync status) and enumerates what it covers: history coverage, network, freshness, and results of last synchronizations. It is distinguishable from sibling x5_sync_history, though it does not explicitly name the alternative. A specific verb is absent but supplied by the tool name 'get'.

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

  Usage Guidelines4/5

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

  The description explicitly instructs to check before analytics ('Проверять перед аналитикой'), giving clear when-to-use context. It does not mention when-not-to-use or point to alternatives like x5_sync_history, so it stops short of a 5.

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

• x5_get_top_productsA
  4.1/5.0
  Behavior4/5

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

  Annotations already establish read-only/idempotent/non-destructive behavior. The description adds useful behavioral information: aggregation by number of distinct receipts, inclusion of quantity and last purchase, and available filters. It does not disclose output ordering or limit behavior, but the core semantics are transparent.

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

  Conciseness5/5

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

  Two short sentences deliver the essential purpose and filters with no filler. The key aggregation logic is front-loaded and every phrase earns its place.

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

  Completeness3/5

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

  The description covers the main operation and filters, but with no output schema it omits the exact return shape, ordering, and limit behavior. An agent could call the tool correctly from the schema, yet would need to infer how the result list is structured and sorted.

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

  Parameters4/5

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

  With 0% schema description coverage, the description compensates by mapping period to from/to, network to the network filter, and category to categoryCode. The limit parameter is not mentioned, though its default/min/max are present in the schema, so the missing semantic is minor.

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

  Purpose5/5

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

  The description names a specific resource (top products), defines the ranking metric (number of distinct receipts), and lists the returned attributes (quantity, last purchase). This makes the tool's function clear and distinguishable from siblings like x5_get_product_history or x5_search_purchases.

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

  Usage Guidelines3/5

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

  The filters for period, network, and category imply when the tool is applicable, but the description gives no explicit guidance on when to choose this tool over alternatives or when not to use it. Usage context is implied rather than stated.

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

• x5_search_purchasesA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral detail beyond annotations: local search, case-insensitive matching, ё/е handling, and available filter dimensions. 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.

  Conciseness5/5

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

  One dense sentence with no filler. The core action is front-loaded, and every clause adds a distinct piece of information: search target, matching behavior, filters, and pagination.

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

  Completeness4/5

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

  For a 7-parameter search tool with no output schema, the description covers query semantics, filters, and pagination. It does not describe the return shape or default limit, but the tool name and schema defaults partially fill that gap, leaving only a minor completeness gap.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description compensates by indicating the meaning of the key parameter groups: product-name query, date filters, network filter, category filter, and limit/offset. It does not enumerate exact parameter names or enum values, but the schema provides those structural constraints.

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

  Purpose5/5

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

  The description opens with a specific action and resource: 'Локальный поиск по названию товара' (local search by product name). It adds matching semantics like case-insensitivity and ё/е normalization, and clearly distinguishes itself from the sibling get_* tools.

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

  Usage Guidelines3/5

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

  The description implies its usage: use this tool when searching purchases by product name with optional filters. However, it does not explicitly state when not to use it or name any alternative sibling tool, so guidance remains implicit rather than explicit.

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

• x5_sync_historyA
  4.4/5.0
  Behavior4/5

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

  The description discloses that this is a network request, updates the local cache, and has first-run parameter requirements. This complements the annotations (readOnlyHint=false, idempotentHint=true) rather than contradicting them. It does not explain the exact meaning of the 7-day overlap or return behavior, but offers meaningful 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.

  Conciseness5/5

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

  Three short sentences with no filler. The purpose is front-loaded, followed by practical usage notes and a size-based exclusion. Every sentence contributes concrete value.

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

  Completeness4/5

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

  For a mutating sync tool with no output schema and only two date parameters, the description covers the key operational points: network side effect, local cache update, first-run requirements, overlap policy, and large-import alternative. It could be more complete by referencing the sibling status tool for determining first-run state, but it is sufficient for correct invocation in most cases.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description carries the burden of explaining parameters. It mentions from/to and the first-run requirement plus 7-day overlap, which adds essential semantic context. However, it does not define each parameter individually or clarify the exact date-range semantics beyond the requirement.

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

  Purpose5/5

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

  The description clearly states a specific action: loading X5 receipts into local SQLite. It distinguishes this tool from the sibling get_* tools by indicating it performs a network sync that updates the local cache, rather than a read-only query.

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

  Usage Guidelines5/5

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

  The description gives explicit usage context: first run requires from/to, subsequent runs use a 7-day overlap, and large imports should be handled via CLI instead. This provides clear when-to-use and when-not-to-use guidance, including an alternative execution path.

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

• x5_get_recent_receiptsA
  4.5/5.0
  Behavior4/5

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

  Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond annotations: the result excludes receipt composition, supports limit/offset pagination, and comes from SQLite.

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

  Conciseness5/5

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

  The description is a single compact sentence that front-loads the core purpose, states the key limitation, and points to the alternative. No wasted words.

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

  Completeness5/5

  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 two optional pagination parameters, the description is complete: it states what is returned, what is not returned, how pagination works, and which sibling covers the missing data. An agent can 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.

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It names limit/offset, indicating pagination controls, but does not explain their meaning or edge behaviors beyond what the parameter names themselves imply. The schema provides defaults and bounds, partially filling the gap.

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

  Purpose5/5

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

  The description clearly states the tool returns recent receipts from SQLite without their line-item composition, with limit/offset pagination. It also explicitly distinguishes itself from x5_get_receipt, which provides the composition.

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

  Usage Guidelines5/5

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

  The description gives a direct routing rule: use this tool for recent receipt headers, and use x5_get_receipt if the composition/line items are needed. This makes the choice versus the most relevant sibling explicit.

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