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 the semantic context of which fields are exposed (recipient, BIC, correspondent account) and the acceptable currency formatting, which is useful. It does not disclose additional behavioral traits like response shape or provider-specific nuances, but with a low-complexity read tool and output schema present, a 3 is fair.

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: purpose and field list first, parameter guidance second. Every sentence earns its place. The opening clause partly repeats the title ('Реквизиты счёта'), but the appended 'для перевода извне' and the actionable parameter hints justify the wording.

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 2 parameters (1 required), an output schema, and no nested objects, this is a low-complexity tool. The description covers purpose, returned content, the source for account_id, and the currency list format, so an agent has everything needed to invoke it correctly. The only gap is explicit differentiation from similar sounding siblings.

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

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

Schema description coverage is 0%, so the description carries the burden — and it compensates well. 'account_id — из list_accounts()' explains the parameter via provenance, and 'currencies — через запятую (RUB,USD,EUR)' provides both the serialization format and valid values. This meaningfully exceeds what the bare schema 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 specifies the resource (account requisites — получатель, счёт, БИК, корсчёт, ИНН/КПП) and the intent ('для перевода извне' — for external transfers). It clarifies what the agent will receive, and the phrase 'для перевода извне' carries scope beyond the title. It does not explicitly name a sibling to distinguish from, leaving transfer_requisites/card_requisites selection partly to inference.

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 implicitly scopes this tool to inbound-over-bank-transfer requisites, and 'account_id — из list_accounts()' gives concrete guidance on how to supply the required parameter. However, there is no explicit when-to-use versus alternatives such as transfer_requisites or card_requisites, so the agent must infer the selection logic.

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?

Even though annotations already declare readOnlyHint, idempotentHint, and destructiveHint, the description adds substantial behavioral context: a multi-day range really expands results by including one-off events, cinema sessions are deliberately excluded, concert/theater nearest slots are visible immediately, and query is a local name filter. This goes far beyond the annotation safety profile.

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 front-loaded with the purpose and then uses short, scannable statements about kind, city, dates, and exclusions. Every sentence contributes useful information, but a few points could be merged, and the emphasis on 'Диапазон реально работает' is important but slightly verbose. Overall, it's appropriately sized for the tool's complexity.

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 8-parameter tool with zero schema descriptions, the description explains required fields, date range semantics, accepted kinds, and explicitly plumbs the routing to sibling tools for excluded cases. With an existing output schema to cover return shape, nothing essential is missing for an agent to call 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?

Schema description coverage is 0%, so the description carries the whole burden for parameters. It covers kind values ('кино' | 'концерт' | 'театр'), city/city_id requirement, date details, and query semantics. But limit and pages are not explained, and the exact accepted enum literal for kind is not confirmed against the schema default of 'movie'. Minor gaps in an otherwise strong param description.

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

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

The description explicitly states the tool's purpose: 'Афиша вертикали за ПЕРИОД дат: что идёт с date_from по date_to'. It also distinguishes itself from siblings by naming exclusions — exhibitions go to search_app(screen="afisha") or place_schedule(), and cinema sessions go to cinema_schedule(event_id, date). This makes it clear what this tool does and what it does not do.

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

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

The description provides explicit when-to-use and when-not-to-use guidance: it works for кино, концерт, театр; it does not work for выставки or киносеансы, with specific sibling tools named as alternatives. It also states that city is required and that date format is YYYY-MM-DD. An agent can select this tool without guessing.

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, but the description adds useful behavioral detail not in annotations: query is local filtering only, no text-search bank exists, pages are read fully before filtering, and city is effectively required. A full picture is missing only for limit behavior, but the added context is meaningful.

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, front-loads the core purpose, and each sentence adds a distinct fact. There is no fluff or repetition.

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 an existing output schema, the description covers purpose, upstream identification, downstream usage, required city, and page/filter semantics. The only missing operational detail is limit and its relationship to the pages parameter, so the description is nearly complete 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?

With 0% schema description coverage, the description compensates well: it explains kind choices, city/city_id requirement, pages as 100-item page counts, and query's local filtering mechanics. However, limit is never explained, and the Russian kind examples do not explicitly reconcile with the schema's default 'movie'.

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 the resource ('площадки города') and the deliverable ('с их objectId'). It clearly distinguishes this tool from siblings by stating it is the only way to obtain a venue objectId without going through an event, which is an explicit differentiator.

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 says when to use the tool: to discover objectId for a venue. It then routes the agent to the downstream consumers — cinema_schedule(object_id=…), place_schedule(), and place_info() — making the invocation path clear. This is enough for an agent to know not to use this tool when objectId is already known.

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, and non-destructive behavior. The description adds only content-domain context ('statements ordered at the bank') and does not disclose any additional behaviors such as whether the list is filtered, paged, or limited to certain document types.

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 one short sentence with no filler, and the parenthetical examples (fund-flow statements, income statements) add useful concreteness. It earns its place but is minimal; it could be better by also naming the action the tool performs.

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 zero-param, read-only tool with an output schema, this minimal description is borderline acceptable. However, bank_documents is placed among many siblings, and without a clear action or relation to documents, payment_receipt, or flows, the agent is left to infer too much about what invoking this tool actually returns.

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 has zero parameters and 100% schema description coverage, so there are no parameter semantics the description needs to explain. The baseline for zero-parameter tools applies, and the description does not hurt this dimension.

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 says what the resource is — bank-issued statements, including those about fund flows and income — so the domain is identifiable. However, it is a noun phrase with no verb (e.g., 'list', 'get', 'download'), which leaves the tool's actual action and return value implicit rather than explicit.

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 usage conditions or alternatives are mentioned. The description does not distinguish when to use bank_documents instead of sibling tools like documents or payment_receipt, nor does it mention any exclusions or contexts where a different tool would be better.

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=true, idempotentHint=true, destructiveHint=false, so the behavioral burden is largely carried. The description adds no contradiction and provides extra context about what data is shown, but it does not disclose other behavioral details such as freshness or authorization subtleties.

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

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

The description is two short sentences: the first conveys the essential output, the second gives the key parameter sourcing. There is no filler, and the most important information is front-loaded.

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

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

For a read-only tool with one required parameter, annotations covering idempotency and safety, and an output schema available, the description captures the core semantics and parameter provenance. Nothing critical is missing for an agent to call it correctly.

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

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

The schema provides zero description coverage for a single string parameter. The description compensates well by explaining ucid comes from list_cards(), giving the agent a concrete source for the required parameter. It could have also noted format or uniqueness, but for a technically simple parameter this is adequate.

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's purpose: it returns card limits for purchases and withdrawals, plus the amount already spent. This goes beyond the title and is easy to separate from sibling tools like card_operations or card_requisites.

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 defines when this tool is relevant (checking card limits and spent amounts) and specifically instructs to take the ucid from list_cards(), which is valuable routing guidance. It does not explicitly exclude other card tools, but the context is clear enough.

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 description adds meaningful behavioral context well beyond the annotations: it discloses that the API lacks a server-side card filter and that operations are fetched by period and filtered locally. It also explains the special semantics of limit=0 and desc_len truncation, which are not inferable from the schema or annotations. This substantially helps an agent anticipate tool 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?

Every sentence adds distinct value: the primary purpose, the server limitation, and the two non-obvious parameter behaviors are all stated in a compact, front-loaded format. There is no filler or redundant restating of the 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?

The description is largely complete for the tool's operation, especially with annotations declaring readOnly/idempotent and an output schema present. The only notable gap is the absence of an explicit definition of the 'days' period parameter, which is relevant to the described time filtering behavior.

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

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

Schema description coverage is 0%, so the description carries full responsibility for parameter explanations. It explains card_id, limit=0 (show all), and desc_len (column width with truncation marker). However, the 'days' parameter is only indirectly referenced via 'operations for the period', leaving its exact meaning to inference.

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

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

The description states a specific verb and resource: it retrieves transactions for a specific card, with the card strongly emphasized as 'КОНКРЕТНОЙ карте'. It clearly distinguishes itself from the general list_operations sibling by focusing on per-card filtering, and even specifies the source of card_id from list_cards().

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 explains when to use the tool: when operations for a specific card are needed. It also provides important context about the lack of server-side filtering and the client-side fallback, helping to set expectations. It does not explicitly say when not to use it or mention alternative sibling tools by name, but the implied use case is clear enough.

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 description goes well beyond annotations by disclosing that the card number is masked by default, CVV is never shown by default, and `reveal=True` outputs full card data sufficient to make payments. This is a critical behavioral guarantee that also flags privacy consequences, exceeding the readOnlyHint and destructiveHint already present.

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 earns its place: first introduces the data, then default masking behavior, then the potential risk with `reveal=True` and a concrete example of what is NOT a valid request. The structure is front-loaded and reasonably compact with no 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?

The tool has an output schema, so return values need not be restated. The description covers the source of the required parameter, the default vs reveal behavior, privacy implications, and the exact user consent threshold. It is fully actionable for an agent deciding whether and how to call it.

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

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

Schema description coverage is 0%, but the description compensates fully: `ucid` is sourced from list_cards(), and `reveal` is explained with a privacy/approval rule. This adds meaning beyond the plain schema, which only defines types and defaults.

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 identifies card requisites as the resource and lists what is provided (holder, expiration, number). It distinguishes this tool from account_requisites and transfer_requisites by explicitly mentioning card and the `ucid` from `list_cards()`, though it lacks an explicit verb like 'returns' or 'gets'.

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?

Provides strong guidance on when to use `reveal=True`, including the condition that the user must explicitly ask for full details and that they should be warned. It does not explicitly name sibling alternatives or state when to use another requisites tool, but the parameters and card context make the scope reasonably clear.

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

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

Annotations already indicate this is not read-only and not destructive, but the description adds behavioral context beyond those hints: it creates an order, does not collect money yet, and unpaid reservations expire automatically. 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 front-loaded with the core behavior and then provides only necessary clarifying details about seat formats, seat_type, and payment flow. Every sentence adds value.

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 existence of an output schema and the surrounding tool flow, the description is largely complete. It covers the key workflow, seat formatting, differentiation from ticket_pay, and the need to show the total before payment. The main residual gap is the meaning of the identified order fields.

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

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

Schema description coverage is 0%, so the description carries the semantic burden. It does explain kind, seats, and seat_type well, but leaves event_id, slot_id, and object_id unexplained. Also, the Russian kind values in the description may not map cleanly to the schema's 'movie' default.

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 books seats and creates an order, explicitly noting that it does NOT pay. It distinguishes itself from ticket_pay and sets the correct expectation for a booking 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 explicitly says that payment is handled separately by ticket_pay and that unpaid bookings auto-cancel, which guides the agent on when and how to use this tool. It doesn't discuss all sibling alternatives like ticket_cancel, but the critical workflow distinction is clear.

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

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

Beyond the read-only/idempotent annotations, the description adds several behavioral details: city is required unless object_id is provided, city is passed by name not numeric cityId, limit semantics with default 20, and the warning that schedule data sorted by a mismatched city center can look plausible but be meaningless. It also explains that returned objectId/slotId/eventId values are useful only when passed to cinema_seats() or cinema_book().

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 long but appropriately so: it documents an 8-parameter, 3-mode endpoint with conditional requirements. It is front-loaded with the core purpose, organized into bullet-style modes, and each line either explains a parameter, a mode, or a critical behavioral constraint. No filler is needed.

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 endpoint complexity, 0% schema coverage, and conditional parameter logic, the description is complete enough for an agent to choose the correct mode, fill the right parameters, and understand how results are used downstream. An output schema exists, so the description does not need to restate the return structure.

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

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

Schema description coverage is 0%, so the description is the sole documentation for parameters. It compensates by explaining date format, limit semantics including 0, cinema substring matching, around as a time like '17:00', window_min as allowed tolerance in minutes, city-as-name semantics, and the conditional roles of object_id and event_id across all modes.

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 defines the tool as cinema showtimes for a date and expands into three explicit modes: entire cinema repertoire, one movie in one cinema, and one movie across a city. It also ties the output to objectId/slotId/eventId, making it distinct from sibling tools like cinema_search and cinema_seats.

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 each mode: object_id without event_id for a cinema's full day repertoire, event_id + object_id for a single film at a cinema, and event_id + city for a film across a city. It even gives a concrete 'what plays tomorrow in this cinema' scenario and warns against the costly alternative of scanning the city schedule.

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 cover read-only and idempotent status, and the description adds substantial non-obvious behavior: limit defaults to 20 but limit=0 shows the full poster, pages scans by slices of 30, default page cap, city default pitfalls, and eventId city-independence. This goes well beyond what annotations provide.

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 efficiently organized by parameter and includes essential caveats without fluff. The historical note about the old 8-page cap is slightly extra but still adds context to the default.

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 five parameters with no schema-level descriptions and an output schema present, the description covers all operational nuances needed to invoke the tool: default city, city_id resolution, pagination and page scaling, eventId purpose, and warn-header hints. Nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must carry the load. It does: query, city, city_id, pages, and limit are all explained with practical details — mandatory status, default behaviors, fallback logic, and what values mean.

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 the specific purpose — find a movie in theatrical distribution and its eventId — and immediately links it to the sibling tool cinema_schedule, which makes call routing clear. It is not a tautology and distinguishes the tool from related cinema 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 strong usage guidance: empty query means the whole city poster, city is mandatory, city_id is the fallback, and pages must be raised if a header says unchecked results remain. It clearly explains why to use the tool, although it does not explicitly contrast it with every alternative cinema tool.

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?

This is the strongest dimension. The description explicitly says money is not moved, explains the output cap and '…ещё N' hint, describes row/sector filtering, and discloses the critical difference between the numbered 'row:seat' cinema format and the composite seatId used by other verticals. It adds substantial behavioral value beyond the annotations and does not contradict them.

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

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

The description is dense but well-structured: front-loaded purpose and side-effect-free behavior, then parameter semantics, then a short critical usage/format note. Every sentence adds useful information, and there is no 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 an eight-parameter read-only tool with zero schema descriptions, the description covers a lot: parameter provenance, default display limits, kind aliases, filtering behavior, and the booking handoff requirement. The only meaningful omission is event_id, which remains a required parameter without any explanation.

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?

Since the schema has zero parameter descriptions, the prose must do the work, and it does so for most parameters: slot_id, object_id, row, max_price, kind, sector_id, and limit all receive meaningful semantics. However, the required event_id parameter is not explained anywhere, and the default meanings of max_price=0 and limit=0 are only implied, leaving a notable gap.

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 identifies the tool as 'Свободные места на сеансе' (free seats for a session), combining a concrete resource with a read-oriented verb. It also positions itself within the cinema flow by referencing cinema_schedule() and cinema_book, so an agent can distinguish it from schedule and booking siblings.

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

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

The description gives strong contextual guidance: where slot_id and object_id come from, which verticals it covers, and how the selected seatId must be passed to cinema_book. It does not explicitly say when NOT to use this tool or name direct alternatives, but the workflow context makes the intended use clear.

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

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

The annotations already provide readOnlyHint, idempotentHint, and non-destructive behavior, and the description reinforces that it is read-only and adds a concrete limitation: the MCP cannot book from this screen, only view availability. It also clarifies where seatId data can be found instead of this screen. No contradiction with the annotations.

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

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

The description is compact and front-loaded with the core purpose, then adds selection rules and read-only limitation in short sentences. Every part adds useful context, although the structure could be slightly tighter.

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

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

With an output schema present, the return shape does not need to be repeated. The description clearly covers the domain boundaries, the read-only nature, and the fallback for seats. However, it does not explain how an agent should obtain or interpret event_id, slot_id, and object_id, which is a necessary step 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 0%, so the description must compensate. It does explain the meaning of the kind parameter, including the two valid kinds and their exclusions, but it gives no meaning or context for the three required parameters: event_id, slot_id, and object_id. The description is not enough to fully determine how those parameters should be supplied.

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 explains that this is a view over sectors with free seating (entry tickets, fan zones) and clarifies the kind values whose concert/theater domains have free seating, while cinema has numbered seats and exhibitions have no such screen. It does not use an explicit verb like “get” or “list”, but “смотреть наличие” conveys the read action clearly.

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 selection conditions: use kind "концерт" or "театр", not cinemas and not exhibitions. It further states that booking from this MCP is not possible, so the tool should be used only to watch availability, and explicitly points to cinema_seats(kind=…) for the actual seats and their seatId.

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 clear. The description adds valuable behavioral context: there is no date parameter, all future showings return at once, touring events may have many venues, and the returned slotId/objectId are later used with cinema_seats(). This explains side effects and expected behavior 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?

The description is mostly efficient and front-loaded with the core purpose and key outputs. It loses a point because 'Даты в запросе нет — приходит всё будущее сразу' appears twice and could be streamlined. Otherwise, the structure is clear and well-sectioned by parameter.

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

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

The tool is fully self-contained for correct invocation: all parameters are described, the downstream use with cinema_seats() is identified, sibling routing is given, and the fact that the response is useful despite having no date-filter is clearly explained. An output schema exists, so return-value format is not needed in the text.

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?

Even though schema_description_coverage is 0%, the description compensates fully: it explains event_id's source, kind's allowed values ("концерт" | "театр" | "выставка"), limit semantics (0 = all, default 15), and object_id purpose (filter to one venue). Every parameter is given operational meaning beyond raw schema field names.

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 clearly states a specific action: retrieving scheduled showings for a concert, theater event, or exhibition, including venue, date, slotId, and objectId. It also explicitly distinguishes itself from cinema_schedule by saying movies do not belong here, which differentiates it from likely siblings.

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

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

The description gives explicit usage boundaries: use for concert/theater/exhibition but NOT for cinema, with a direct referral to cinema_schedule(event_id, date). It also explains that event_id comes from search_app(query, screen="afisha"), painting a clear flow of how and when to invoke this tool.

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 indicate the call is not read-only, not destructive, and open-world, but the description adds almost no behavioral clarity. It does not say whether the code is consumed, whether retries are possible, what happens on an invalid code, or whether the current session is updated.

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 short, but that brevity does not help because it is an under-specified and misleading sentence rather than a concise explanation. It repeats the same idea as the title without adding structure or actionable context.

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 tool, an output schema helps, but the description still leaves out the core flow: that an OTP was received by SMS and that calling this tool confirms it. It lacks any detail about prerequisites, errors, or integration with the login/session flow.

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 parameter schema is bare: one required string named 'otp' with 0% description coverage. The description mentions 'SMS-код', which weakly suggests the value is a code from SMS, but it fails to clarify the expected format, how the user should obtain it, or whether the code must be sent as digits or text.

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 says 'Отправить SMS-код' ('Send an SMS code'), which does not say the tool confirms or verifies an OTP. The tool name confirm_otp and title 'Подтверждение кода из SMS' point to confirmation, so the description is likely to mislead an agent into thinking the tool sends an SMS rather than validates a code.

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 about when to use this tool versus related auth tools such as login, confirm_password, confirm_pin, refresh_session, or session_status. The description neither explains that the user must have received an SMS code first nor describes what happens after confirmation.

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 description goes beyond the annotations by disclosing a critical security-sensitive behavior: the password is read from a terminal invisible to the model and must not be handled by the agent. This prevents a misuse that annotations alone could not express. It also clarifies the CLI's role and the intended execution context.

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 short, information-dense sentences are placed in logical order: prohibition first, reasoning second, actionable alternative third. Every sentence earns its place and there is no filler or redundant schema repetition.

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 security-sensitive tool, the description is complete. It tells the agent why the tool exists, how the password is handled, when the bank may request it, and exactly what action the agent should take. The existing output schema covers any required return-value detail, so nothing essential is missing.

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

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

The schema only provides a 'password' title with no description, but the tool description adds essential semantic context: this is the account password, it must not be transmitted through the agent, and for the CLI flow it is read directly from the terminal. It does not specify format constraints, but the security-critical meaning of the parameter is clearly conveyed.

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

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

The description clearly states what the tool is for: password confirmation for first login on a new device, but only for the login_cli.py flow. It also explicitly differentiates it from a chat-accessible tool by warning 'НЕ вызывай напрямую из чата'. The agent knows the tool's role and how it differs from a normal login/confirmation flow.

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 and when-not-to-use guidance. It says the agent must never call it from chat, explains the password must not pass through the agent, and tells the agent exactly what to do instead: ask the user to run login_cli.py when the bank requests a password on a new-device first login.

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 description goes well beyond the annotations by explaining that this operation continues a stored attempt, does not create a new payment, cannot double-charge, and does not advance state on an incorrect code. It also discloses that the code is never logged and that the final outcome is visible via payment_status(attempt_id). These are highly valuable behavioral details. No contradiction with the annotations was found.

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 dense and front-loaded, leading with the purpose and then covering the key behavioral guarantees. There are sentences that could be tightened, but the extra length is justified because it explains a bank payment flow, retry semantics, and side effects. Overall, it is well-organized and efficient for its complexity.

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 destructive banking operation, the description covers the trigger condition, the origin and meaning of both parameters, the behavior on wrong and valid codes, the resend path, and the follow-up status-checking tool. With an output schema present, omitted return-value details are not a concern. Nothing critical is missing for an agent to 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 description coverage is 0%, so the description carries the burden of explaining parameters. It does clarify that attempt_id comes from the initiating transfer/pay_bill response and that otp is the SMS/push code. However, the schema marks otp as optional with an empty default while the description says to pass it as a required confirmation code, leaving a minor semantic mismatch. Still, the description compensates meaningfully for the schema gap.

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 opens with a specific and unambiguous purpose: confirming a payment that the bank holds at WAITING_CONFIRMATION via a second factor. It also explicitly differentiates itself from confirm_otp, which handles login confirmation, making the tool distinguishable from the large sibling set. This is a strongly clear and purpose-oriented description.

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 guidance is explicit: call this tool when transfer, transfer_requisites, or pay_bill return a “ТРЕБУЕТСЯ ПОДТВЕРЖДЕНИЕ” response. It also states exactly when not to use confirm_otp and provides a full workflow: ask for the SMS/push code, take attempt_id from the previous response, and pass otp. Guidance for retrying, resending, and checking status is also included.

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=false and destructiveHint=false, so the description does not need to repeat them. The phrase 're-auth' adds a little context beyond the annotations, implying a state change on the current session. However, it does not reveal what happens to the session, whether a pending PIN is required, or whether there are rate limits or other restrictions, so the behavioral transparency is still limited.

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 consists of a single short sentence, but it is underspecified rather than the intentionally concise. It lacks key information about the re-auth flow, the effect of the call, and the relation to other auth tools, so the shortness works against the usability. It is not a well-earned conciseness.

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

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

The context signals show a large set of auth-related siblings (login, confirm_otp, refresh_session, session_status, confirm_password), yet the description does not explain how confirm_pin fits into that flow. With an output schema present we do not need to document return values, but the absence of when/why to call this tool makes it incomplete for correct usage.

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

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

Schema description coverage is 0%, and there is only one required parameter 'pin'. The description explicitly says 'Отправить PIN', which in essence associates the 'pin' parameter with the value to be sent. Nevertheless, it provides no information about the format, potential restrictions, or how the PIN is obtained/used in the re-auth flow. This partial clarification is better than nothing but does not fully compensate for the absence of schema descriptions.

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 concrete verb и объект: 'Отправить PIN' (send PIN), and adds the context '(re-auth)'. However, it does not clearly differentiate the tool from siblings like confirm_otp or confirm_password, and the relationship between name 'confirm_pin' and 'send PIN' is slightly ambiguous. It is minimal but comprehensible.

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 only hint is the 're-auth' abbreviation, which suggests the tool is for re-authentication, but there is no explicit instruction on when to use this tool versus alternatives such as login, confirm_otp, or confirm_password. No conditions or exclusion she is provided, so the agent cannot reliably distinguish this from its siblings.

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 description discloses key behaviors beyond the annotations: traces are written automatically on every tool call, can be disabled with TBANK_TRACE=0, and contain no secrets or free text. It also explains how the report sections are intentionally structured, including the deliberate mixing of failures and successes.

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 comprehensive but disciplined: purpose and exclusions come first, then parameters, then how to interpret the output. Each block adds critical guidance without redundancy, and the structure makes it easy for an agent to extract the relevant information quickly.

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

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

For a debug tool, the description covers every important aspect: what data is captured, how to request it, why the output is structured, and what to do with the findings. The presence of an output schema further reduces the need to document return format in prose, and the description still explains the report's semantic sections.

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?

Even though schema description coverage is 0%, the description fully defines both parameters: runs determines how many recent server runs to examine with 0 meaning all available, and top controls how many lines are shown per section. This fully compensates for the lack of schema descriptions.

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 exactly what the tool does: it reports which tools were called, in what order, what responses were returned, and where agents got stuck. It also explicitly scopes the tool to debugging the MCP itself and contrasts it with banking tasks, which helps distinguish it from the large set of business-oriented sibling 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 clear usage context: use this when debugging the MCP, not for banking tasks. It also maps each report section to a diagnostic interpretation, such as repeated identical calls indicating a poor docstring, and transitions diverging from an expected flow.

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 readOnly, idempotent, and non-destructive behavior. The description then adds genuinely useful context: records are redacted and contain no secrets, the data comes from a local events file, and the header reveals total count so the user can see how many events are omitted by limit. There is 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 compact and information-dense: purpose, safety redaction, source path, and parameter semantics are all covered in two short sentences. There is no filler and the diagnostic intent is front-loaded before the limit explanation.

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 diagnostics tool with an output schema, the description is complete: it explains the event kinds covered, the source file, the no-secrets policy, possible diagnostic use, and how to interpret the output header. Nothing essential is missing for correct selection and 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?

With 0% schema description coverage, the description fully compensates by explaining the only parameter: limit controls how many of the latest events are shown, 0 means show all, and the output header exposes the total count. The distinction between limit and omitted events is exactly what an agent needs when invoking the tool.

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 identifies the resource: recent redacted events related to checkout actions and session refresh, stored in a known local file. It says this is for diagnostics, and even specifies the two intended diagnostic actions: reconstruct an attempt or find the last confirmed step. This distinguishes it from operational tools like pay_bill or confirm_payment.

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 when to use the tool: for diagnostics, reconstructing an attempt, or finding the last confirmed step after a payment flow. It does not explicitly compare itself to a sibling alternative such as debug_report, nor does it give clear when-not-to-use guidance, so it misses the top score.

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 non-destructive behavior, so the description adds substantial extra context: the data store contains documents belonging to relatives, they are filtered out by date of birth by default, and include_others=True changes their visibility. This subtle behavior is essential for correct invocation and is not derivable from the schema or 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 compact and front-loaded: it first enumerates supported document kinds, then explains parameter behavior, and finally reveals the subtle relatives filtering edge case. Every sentence carries meaningful information and there is minimal non-content language.

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

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

The description is sufficiently complete for a read-only list tool with two optional parameters and an output schema. It covers the document types, filtering semantics, and the unusual relatives-filtering behavior, leaving little room for an agent to misinvoke the 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 description coverage is 0%, but the description fully compensates by explaining both parameters: kind is a filter by name or code, with examples and an 'empty = all' rule, and include_others is the flag that surfaces relatives' documents. There is no ambiguity left about the meaning of the two arguments.

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 identifies the resource by listing concrete client document types (паспорт, СНИЛС, ИНН, ПТС/СТС, etc.) and explains the filtering capability. It does not use an explicit imperative verb like 'list' or 'retrieve', so the exact action is slightly inferred 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 through the parameter explanations: kind filters by name or code with an explicit default of all documents, and include_others proactively shows relatives' documents when true. However, there is no direct comparison to sibling tools such as bank_documents or any when-to-use versus when-not-to-use 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 mark the tool as destructive and non-idempotent, but the description adds much more: real money is spent in one step, a payment confirmation button appears, the client is refused without explicit elicitation, and the payment may be declined due to the unavailable travel session. The caveat that the signature was reconstructed but live payment was never executed is unusually explicit.

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 front-loaded with the most important safety facts and is structured in useful blocks. It is still long and contains engineering detail not needed for selecting or invoking the tool, such as key reconstruction details, HmacSHA256, and X-Detach-Key/Timeout headers, with repeated warnings that money will not move.

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

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

The description covers the full flow of a high-stakes booking: confirmation, refusal, child exclusion, no refund, force retry, and fallback to the app. An output schema exists, so return values do not need to be described, but account_id semantics are missing and the description does not point agent to flight_seats() as the source for seat selection.

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

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

With 0% schema description coverage, the description compensates well: offer_id, fare, passengers, seats, and force are all explained with run behavior. However, account_id is never explained, leaving one of six parameters semantically unclear.

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 opens with 'КУПИТЬ авиабилет' and immediately states that the call is a single step that both books and debits money. It is clearly scoped to flight purchase, explains the distinction from separate booking/refund flows, and references flight_search() and flight_offer() as input sources.

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 usage context: use the tool after offer_id and fare are known, show the final price and rules to the client, and let confirmation happen via the button. It explicitly excludes child bookings, refunds via MCP, and defines when force=True may be used after checking trips() and the app.

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?

Although annotations already mark the tool as read-only, idempotent, and non-destructive, the description adds non-obvious behavior not present in annotations: the endpoint responds only under a mobile session with the X-Travel-Context='mb' header, and that header was discovered through live probing rather than passive traffic capture. This is genuinely useful operational context beyond the schema and 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?

The description is compact and front-loaded: it states the primary purpose, gives the unique lookup rule, and closes with an execution-critical technical note. Every sentence earns its place and no filler is present.

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 zero parameters and an existing output schema, the description is complete. It covers purpose, the exact condition under which to use the tool, the fact that it is the authoritative IATA-code source, and the session/header prerequisite for the 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?

The input schema has zero properties and 100% coverage, so there are no parameters to document. The description correctly says nothing about parameters; no additional semantics are needed.

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

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

The description clearly states what the tool is and what it offers: flight search history and, critically, the only source of IATA codes paired with city names. This differentiates it from travel sibling tools such as flight_search and flight_offer, and from generic list tools, because it flags a unique lookup responsibility.

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 an explicit usage rule: if the user names a city in words, look up its code here rather than substituting from memory. It also explains that this endpoint, like flight_search, works through a mobile session via X-Travel-Context='mb', setting clear invocation expectations.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: the price is re-read and may be outdated, and the tool sorts fares by ascending price with this order numbering. These are useful traits for an agent to know to avoid stale assumptions and to correctly compose the number into the next booking step.

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 organized in a logical, front-loaded order: what the tool does, how the fare number relates to the booking flow, and a critical caveat about fresh pricing. Every sentence adds decision-relevant information; no filler, and the length is proportional to the tool's complexity.

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

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

The description is extremely complete for a tool of this simplicity: it covers the source of the required parameter (offer_id), the meaning and destination of the optional fare, the ordering and numbering, and the price nicety. With an output schema available no return-details repetition is needed, and the annotations layer already covers safety. The agent has everything needed to select and invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries the full burden—it succeeds. It explains offer_id as coming from flight_search() and fare as the numbered list index (fare=1, 2, …) that is used for flight_book(), with fare=N filtering to a single tariff. Both parameters are given meaningful context beyond the bare type definitions, leaving no meaning unexplained.

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

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

The description uses a precise verb ('показать') and the resource ('Тарифы, багаж и правила возврата по выбранному рейсу'), and further clarifies the exact scope. It explains how a single search result expands into multiple fares and how the tool numbers them, clearly distinguishing it from the sibling flight_search, flight_book, and flight_seats. This is a specific verb+resource verb+resource with a clear role in the flight booking flow.

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 places the tool in the pipeline: offer_id comes from flight_search(), and the fare number generated here is passed to flight_book(). It also names the parameters that drive usage, like fare=N to show one tariff. However, it stops short of explicit 'do not use when…' exclusions or an explicit alternative comparison, though the context makes its role unambiguous.

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/idempotent annotations, the description discloses authentic operational details: fast first-batch behavior on the default path, a slow stream of thousands of partner offers when only_bookable=False, an experimental payment path that may fail, and an odd X-Travel-Context header not observed in normal traffic. This is unusually candid and behaviorally useful.

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 core purpose is front-loaded in the first sentence, and the rest is parsed into compact sections: code resolution, offer policy, booking/payment recommendation, and endpoint caveat. Every paragraph carries decision-relevant info; there is 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?

The search workflow is well covered: how to obtain codes, how to interpret only_bookable, and how the tool fits with flight_test, flight_offer, flight_seats, and flight_book. The return value is presumably covered by the output schema. The remaining gap is max_batches/limit not being connected to the described batch/stream behavior, which could confuse an agent when it wants to limit the result flow.

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 description adds meaning beyond the schema for from_code, to_code, date, and only_bookable, which are the most critical fields. However, the schema has 0% description coverage and 5 of 9 parameters (limit, adults, children, infants, max_batches) are left undocumented in both schema and description, forcing the agent to infer from titles and defaults.

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 opens with a specific verb+resource pair (Поиск авиабилетов) and defines the core inputs: IATA codes and date format. It also distinguishes the flight workflow roles by naming flight_offer, flight_seats, and flight_book as sibling steps, so an agent can tell which tool does what.

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 explicitly tells the agent not to guess city-derived IATA codes and to take them from flight_history() instead. It also explains when only_bookable=True vs False should be used, and it clarifies that booking/payment belongs to flight_book and that reliable purchase goes through the app.

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 mark the tool as read-only and idempotent, and the description adds important behavior: seats are paid but optional, skipping them does not prevent booking, and selected seats must be passed one per passenger in the same order. This is useful beyond what the structured annotations alone provide.

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 seat map purpose comes first, then input provenance, then the one critical workflow detail. There is no filler or repetition of what the schema and annotations already state.

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

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

The output schema and annotations cover return values and safety, and the workflow context is well described. The main gap is the lack of detail around the limit and max_price parameters, which limits full completeness for an agent trying to use all available inputs.

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 description explains offer_id and fare, which helps because the schema has no property descriptions. However, limit and max_price are left unexplained, and max_price's default of 0 is ambiguous without more context, so the description does not fully carry the parameter-semantics burden.

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 name and first phrase clearly identify a seat map for a flight with prices ('Карта мест в салоне с ценами'). It ties the tool to flight_search() and flight_offer(), which distinguishes it from siblings like train_seats and cinema_seats while making the resource 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 gives the exact workflow placement: take offer_id from flight_search(), take fare from flight_offer(), and pass selected seats into flight_book(). It also gives an implicit when-not-to-use by noting seats are optional and a row will still be assigned at check-in.

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?

Аннотации уже передают безопасность чтения через readOnlyHint и idempotentHint, поэтому описание не обязано повторять это. Оно добавляет сверх аннотаций важные детали поведения: topic понимается как свободные слова, без аргумента возвращается список тем и правил, а результат фильтруется по подходящим разделам.

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?

Описание компактно, начинается с ключевой идеи, затем переходит к параметру и заканчивается пояснением поведения без аргумента. Все фразы несут полезную информацию без повторов и избыточности.

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?

Для простого инструмента с одним параметром описаны все ключевые сценарии использования и задокументировано поведение без параметра. Наличие output 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 0% описание целиком компенсирует отсутствие описания параметра в схеме. Оно объясняет, что topic — это свободная формулировка, приводит наглядные примеры тем и детально описывает сценарий с пустым значением. Для одного необязательного параметра этого достаточно.

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?

Описание сразу задаёт конкретный ресурс: «Гид по флоу: порядок вызовов для конкретной задачи». Это однозначно отличает инструмент от операционных соседей вроде login, pay_bill, train_search — он является мета-инструментом для получения последовательности вызовов по теме.

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?

В описании явно указаны два сценария использования: с параметром topic — для конкретной задачи, и без параметра — для получения списка тем и общих правил, включая примечание про тулы с реальными деньгами. Не хватает только прямых формулировок «не используй, когда…», но для справочного инструмента этого достаточно.

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 indicate read-only, idempotent, non-destructive behavior, and the description substantially enriches the behavioral model: it discloses that invalid sections produce a refusal, that seven sections error without arg rather than returning empty, that obrezanie is unique to statements, and that response truncation is explicitly marked. This goes far beyond what annotations provide.

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 long because it must enumerate a large section set and special cases, but the structure with bold caveats, a list of arg-requiring sections, and clear exclusions keeps it scannable. Every sentence earns its place; the slight lack of conciseness comes from the inherent breadth of the tool, not from redundancy or 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?

Given the tool's coverage of subtitle data and a large section list, the description is unusually complete: it considers edge cases, error behavior, response truncation, alternative tools, and ambiguous data location issues. The existence of an output schema means return value formats do not need to be encoded in the description. Agents can call this tool correctly with the information provided.

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 has no parameter descriptions (0% coverage), and the description fully compensates for this: section is mapped to its full valid value set, arg is refined per section with concrete meanings and examples, days is specified as the statement window with default 30 and no effect on others, and max_chars semantics including the 0 default are explained. This is a model of parameter-level documentation.

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 identifies the tool as a universal getter for bank data organized by sections, and enumerates the supported section values. It also explicitly names sibling tools that handle certain cases (payment_qr, transfer_sbp_resolve, account_requisites), preventing confusion with nearby tools. The scope and purpose are unambiguous despite the breadth of the tool.

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

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

The description provides explicit guidance on when to use this tool and when to prefer alternatives: payment QR goes to payment_qr, recipient search belongs to transfer_sbp_resolve, and own account requisites belong to account_requisites. It also instructs agents to check both invoices and subscription_bills before concluding no unpaid bills exist. Required arg usage and error behavior are precisely defined.

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?

Описание раскрывает важное неочевидное поведение: при превышении доступного остатка возникает CART_QUANTITY_CONFLICT, корзина не записывается, количество не уменьшается автоматически. Это существенно дополняет аннотации readOnlyHint/destructiveHint, которые не говорят о семантике ошибок и отсутствии частичного применения.

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?

Описание компактное, в три коротких предложения, без воды. Сначала входные данные, затем обязательные параметры и связность с другими вызовами, потом критичное поведение при ошибке и инструкция по восстановлению. Ключевые предупреждения размещены в конце и обоснованы.

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?

Описание покрывает обязательные входные данные, межзависимость с grocery_stores/grocery_cart/grocery_checkout и сценарий конфликта, поэтому агент может корректно вызвать инструмент. Есть выходная схема, поэтому описание не должно объяснять возвращаемое значение. Небольшой вычет за формальное расхождение с input-schema: в описании app_id/point_id обязательны, но схема помечает их как необязательные с default.

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?

При 0% описания в схеме, описание компенсирует это: указана структура items = JSON [{id, count}, ...], обязательность app_id/point_id и источник их значения — grocery_stores(). Однако id не связан явно с источником товаров, например grocery_search, а остаток countAvailable только упомянут без пояснения, где его получить.

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?

Описание называет конкретное действие — «Добавить товары в корзину» — и явный объект (корзина), что позволяет отличить его от grocery_cart и grocery_checkout. Однако явного противопоставления близкому саблингу grocery_set_cart нет, поэтому различение с саблингами неполное.

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?

Даётся ясный контекст: app_id/point_id надо брать из grocery_stores(), они обязательны, и тот же магазин нужен для grocery_cart и grocery_checkout. Также описан сценарий повторного вызова после конфликта. Нет явного «когда не использовать» и сравнения с альтернативами вроде grocery_set_cart или grocery_plan_order.

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 the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description reinforces read-only behavior. It adds behavioral context about output shape and header count: limit=0 means all attempts and total count is shown in the header, which is useful 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 earns its place: purpose, returned fields, use case, and parameter edge case are covered in three compact lines. The most important context (read-only, UNKNOWN reconciliation) is front-loaded, with no filler.

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

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

For a simple read-only listing tool with one optional parameter and an output schema, this description is complete. It conveys when to call it, what it returns, how limit behaves, and what the magic value 0 means — nothing essential is missing.

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

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

The schema has one parameter, `limit`, with no schema-level description, but the tool description fully documents it: 'how many recent attempts to show (0 = all)' and notes the total count in the header. This adds real semantic value beyond the raw integer 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 names a specific resource — recent grocery checkout attempts — and a specific verb: show/display. It also states the exact use case (reconciliation after an UNKNOWN checkout result) and the returned fields, which clearly separates it from siblings like grocery_checkout and grocery_order_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 gives an explicit trigger condition: use it after checkout returns an indeterminate UNKNOWN result, when reconciliation is needed. It does not explicitly list sibling alternatives or exclusion conditions, so it falls just short of the strongest possible 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 mark this as read-only, idempotent, and non-destructive. The description adds contextual behavior beyond that: it discloses that each line prints trend-only countAvailable and explains the CART_QUANTITY_CONFLICT block and the instruction to resolve discrepancies. This is honest and informative.

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

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

The description is two sentences with no filler. It quickly introduces the purpose, then explains the provenance requirement and the conflicting scenario. Every sentence adds value and key constraints are mentioned up front.

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

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

The description is sufficient for an agent to invoke the tool correctly: it defines the parameters, their sources, the expected output, and a conflict condition. Slight missing details like empty-cart behavior or response format are compensated by the existing output schema annotation.

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?

Input schema has two parameters with no description coverage, but the description significantly enriches them. It says both are mandatory, sourced from grocery_stores(), and must match the ones used in grocery_add_to_cart. That covers the essential semantic meaning the schema lacks.

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 clearly states that the tool shows cart contents and prints per-item availability counts. It also references grocery_add_to_cart to define the required parameter context. However, it does not explicitly differentiate this from other cart-related siblings like grocery_set_cart or grocery_checkout, which leaves some room for ambiguity.

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 concrete prerequisite: app_id/point_id must come from grocery_stores() and match those used in grocery_add_to_cart. That is valuable usage guidance. But it does not say when this tool should be chosen instead of checking the cart elsewhere, or when it should be avoided.

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 description goes far beyond annotations: it discloses that real money move, that a CART_QUANTITY_CONFLICT blocks the order before delivery and before any payment, that checkout makes its own backend-driven preview and only executes after a button confirmation, that the bank recomputes the cart after confirmation, that ambiguous results block retries, and that force only re-shows the confirmation button. This is exactly the behavioral context the agent needs for a destructive, non-idempotent operation. No contradiction with the annotations exists.

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 long but every paragraph corresponds to a distinct decision an agent must make: high-level purpose, mandatory store identity, cart conflict handling, consent UI, dry-run behavior, account selection, multi-step idempotency guard, and failure diagnosis. It is front-loaded with the most critical fact: real money. This length is justified by the destructive nature of the 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 payment-completing tool with no parameter descriptions and a large sibling family, the description leaves almost nothing unknown: inputs, side effects, failure modes, retry policy, confirmation requirement, and even Playwright failure remediation. There is no need to describe the return format because an output schema is provided.

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?

Despite 0% schema description coverage, the description covers all 6 parameters: app_id/point_id are explained as mandatory and sourced from grocery_stores(), dry_run is described as preview without order or payment, account_id is described as overriding the default app payment account, expected_sum is the previously announced sum for reconciliation, and force is scoped to the explicit-no-previous-order case. Without this, an agent would be heavily constrained by these fields.

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 identifies the tool as the full grocery checkout flow: 'Полный чекаут: доставка → заказ → оплата'. It ties the tool to grocery context (корзина, grocery_stores, app_id/point_id) and emphasizes 'РЕАЛЬНЫЕ ДЕНЬГИ', which distinguishes it from non-payment grocery tools and from unrelated payment/purchase siblings such as train_pay, ticket_pay, and pay_bill.

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 usage rules: app_id/point_id must come from grocery_stores(), the cart must match the same store, dry_run is for preview, expected_sum verifies a previously quoted total, retries are blocked pending grocery_attempts(), force=True is allowed only after explicit user confirmation, and user consent must be via button rather than text. It directly tells the agent when and how to use the tool and what to do when the invocation is unsafe.

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, idempotentHint, and destructiveHint=false. The description adds behavioral detail beyond annotations: it lists the returned product fields, explains that КБЖУ is given both per 100 g and per package, and notes that in some chains КБЖУ exists only as text and is parsed. This is useful context not available from the annotations alone.

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: sentence on the card contents and sentence on the source of good_id plus КБЖУ units and parsing behavior. Every part earns its place; there is no unnecessary repetition.

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

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

The tool has one required parameter and an output schema, so the description is nearly complete. It covers the key data fields, the source of the main parameter, and the units. The only missing piece is an explanation of optional app_id/point_id, but they are non-essential and defaulted.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the only required parameter, good_id, by indicating that it comes from grocery_search() or grocery_plan_order(). However, app_id and point_id are left undefined, and their semantics are not clarified beyond their names and defaults.

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 identifies the tool as retrieving a product information card (состав, КБЖУ, вес, срок хранения, производитель), which is distinct from sibling tools like grocery_search, grocery_plan_order, and grocery_add_to_cart. It also clarifies that this is the 'good info' lookup rather than a search or ordering 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?

It provides direct usage guidance: good_id must come from grocery_search() or grocery_plan_order(). This tells the agent when to call this tool and where to obtain the required input. However, it does not explicitly state when not to use this tool or mention alternatives, so it falls just 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.

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

The description discloses significant behavioral detail beyond annotations: paid orders are refunded to the debit account, the result must be evaluated from payload.status rather than the outer status, code 605 means already cancelled, and re-reading with app_id may be needed to confirm actual cancellation. This gives the agent a realistic model of the tool's side effects and response evaluation.

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 dense but every statement is functional. It front-loads the purpose, follows with refund and consent handling, then captures important parameter conditions and response semantics. There is no filler or redundancy.

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

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

Given the tool's complexity and a small parameter set, the description covers action, outcomes, return-behavior semantics, edge cases like already-cancelled orders, and handling when status is unknown. Even though there is an IS input schema, the description does not need to explain the return shape, but it also gives the critical interpretation of the response.

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 0%, so the description carries the full burden for both parameters. The description explains that order_id is the sole cancellation key, that paymentId/payment_id is specifically NOT required, and that app_id is optional, sourced from grocery_stores()/grocery_attempt(), and improves status accuracy. This fully compensates for the unhelpful JSON 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 states a specific action and resource: cancel a grocery order, whether paid or unpaй. It additionally distinguishes itself from the sibling ticket_cancel by noting paymentId is not needed, and names the relevant order identifier, so an agent can correctly select this tool.

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

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

The description gives explicit usage direction: use this to cancel a grocery order, it requires consent from the user first, paymentId is not needed unlike ticket_cancel, and app_id is optional but beneficial. It also tells the agent what to do if the tool returns an error: check grocery_order_status or rely on the app, making whens and alternatives clear.

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

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

Beyond the readOnlyHint and idempotent annotations, the description adds crucial behavioral context: app_id is mandatory despite an empty schema default, and without it the bank returns a raw 400 instead of a meaningful error. It also explains how to derive the app_id from grocery_stores(), which is important operational knowledge.

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: it starts with the core purpose, then gives the expected usage context, then delivers the mandatory app_id caveat. Every sentence adds unique, useful 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 a read-only order-status tool with an output schema, the description covers the purpose, the condition requiring invocation, the required parameters and their semantic quirks, and the source for deriving the app_id. Nothing essential is missing for correct use.

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

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

Schema description coverage is 0%, so the description must compensate. It fully covers both parameters: order_id is the order identifier to query, and app_id is clarified as mandatory, not optional despite the default, and must be taken from grocery_stores() based on the store name from orders().

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 identifies the exact action: reconcile the status of a grocery order by orderId via GET /api/grocery/order. It also states why it is useful: checking whether an order was created or paid after an UNKNOWN checkout. This clearly differentiates it from grocery_checkout, grocery_attempts, and grocery_order_cancel.

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 gives explicit guidance: use this after an UNKNOWN checkout to verify whether the order was created or paid on the backend. It does not explicitly name sibling alternatives or explain when not to use them, but the trigger condition is clear enough to route an agent correctly.

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

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

Annotations already declare readOnly/idempotent/non-destructive. The description adds useful behavioral details: confidence markers ('✓' vs '⚠ проверь'), exactly how matching handles punctuation/word order/word forms, and the important limitation that synonyms and transliterations are not guessed. It aligns with the readOnlyHint since it only plans and matches, not writes.

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 every sentence provides necessary guidance: output markers, matching behavior, and where to retrieve IDs/profile. It avoids fluff and front-loads the purpose before the more detailed semantics.

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 planning tool, the description covers the essential preconditions, inputs, and output semantics. It relies on an external 'ladder' skill and does not repeat output schema details, which is acceptable given the output schema exists. The custom_ordered vs global distinction is mentioned though not fully defined.

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

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

Schema description coverage is 0%, so the description must compensate. It does: it gives the ingredients format as a JSON array with an explicit example, and tells the agent where app_id/point_id come from (grocery_stores). The only caveat is that app_id/point_id are called 'обязательны' while the schema lists only ingredients as required, creating a minor conflict.

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's job: 'Спланировать заказ' and explains that it looks up each ingredient (custom_ordered → global). It is specific enough to be distinguished from sibling tools like grocery_search or grocery_checkout, though it never names a sibling to disambiguate further.

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 supplies concrete context: app_id/point_id come from grocery_stores() and are described as mandatory; it also explains what to do when matching fails (manual lookup via WebSearch/browsing). It does not explicitly contrast this tool with alternatives, but the intended context is reasonably clear.

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

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

Beyond the readOnly and idempotent annotations, it discloses meaningful behavior: no ranking strategy is applied by default, items missing a required sort field are placed last regardless of asc/desc, and fetching nutrition fields by sorting incurs an extra request per candidate. This gives the agent insight into actual runtime semantics and cost.

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 front-loaded with the purpose and then expands into tightly-packed details: when sorting is inactive, allowed sort values, order values, nutrition-fetch behavior, and missing-data behavior. Every sentence adds a distinct fact; there is no filler or redundancy.

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

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

Together with the output schema, annotations, and title, this description is enough for the agent to invoke the tool correctly and interpret most runtime behavior. It clearly explains sorting, missing-data ordering, and fetch-related side effects. The remaining gap is the under-documentation of app_id, point_id, and limit, which would make the context fully self-contained.

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?

Given the input schema has no parameter descriptions, this description adds meaningful semantics for the most important parameters: sort_by values, order asc/desc, the meaning of empty sort_by, and the with_nutrition behavior. Still, not every parameter is covered: point_id, app_id, and limit are left completely unexplained, so the compensation is strong but not 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?

The description clearly states that the tool returns query candidates with attributes and optional sorting, and it disambiguates itself as an 'instrument, not a policy.' The resource is identifiable from the title and name, but the description does not explicitly differentiate it from sibling tools like grocery_search, so it is clear but not fully sibling-aware.

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 concrete guidance on when sorting should be applied: only when the caller/user requests a strategy, otherwise sort_by should stay empty and store order is preserved. It also explains when nutrition fields are fetched automatically versus via with_nutrition=True. However, it does not explicitly state when to choose this over alternative tools such as grocery_search, so it provides context without a clear exclusion.

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 description adds behavioral detail beyond the annotations: it says returned products carry the likely_raw tag and that the response header shows total matched vs. total returned. These are genuinely useful expectations not present in the annotations, and there is no contradiction.

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 well-structured: purpose first, then parameter sourcing, result qualification, and limit behavior. Every sentence provides necessary information without redundant wording.

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 four parameters, no schema descriptions, and an output schema present, the description covers the important usage factors: what to search, where to get store IDs, and how limit affects output. The only notable gap is the requirement mismatch around app_id/point_id, which creates potential confusion about whether the tool can be invoked only with query.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It explains app_id/point_id source and limit semantics, but it states they are 'obligatory' while the schema marks them optional with default ''. This semantic contradiction reduces clarity. Query itself is self-explanatory, but the parameter help is incomplete and partially misleading.

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 ('search product by name') and resource (grocery item), which distinguishes the tool's basic purpose. It does not explicitly compare against sibling tools like grocery_good_info or grocery_rank, so a small ambiguity remains, but the core purpose is clear.

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

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

The description gives concrete usage direction: app_id/point_id should be taken from grocery_stores(), and limit is defined as controlling how many results to show, with 0 meaning all matching items. It does not explicitly reject alternatives, but for a search tool the instructions are adequate and not misleading.

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 description adds substantial behavioral detail beyond annotations: absolute quantity semantics, full-cart rewrite behavior, countAvailable rejection with CART_QUANTITY_CONFLICT, no silent clamping, and the post-change cart return value. No contradiction with annotations is present.

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 for its complexity, well-structured with line breaks, and each sentence adds functional value. It front-loads the key distinction from grocery_add_to_cart and does not repeat schema fields.

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 output schema exists, return-value description is optional, but the tool still explains the post-change contents. Error behavior, full-rewrite mechanics, absolute semantics, and parameter semantics are all covered, making this complete 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 schema has no parameter descriptions, but the description compensates well: items gets a JSON structure with count>0, count=0, and omitted-item semantics, and clear gets an explanation. app_id and point_id are not individually explained but are clear identifiers and optional with defaults.

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's action: modify or remove cart items by overwriting quantities. It explicitly distinguishes itself from grocery_add_to_cart, which increments quantities, so an agent can tell it apart without opening the schema.

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

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

The description explains exactly when to use this tool vs grocery_add_to_cart, how count=0 removes items, how items omitted stay untouched, and how clear=True empties the cart. It also clarifies that there is no dedicated delete endpoint, so the tool must rewrite the whole cart.

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, idempotentHint, destructiveHint), so the description adds genuinely valuable behavioral semantics: 'fast' is measured by the END of the nearest delivery window because the bank returns two incomparable slot types ('within 15 min' vs 'tomorrow 08:00–11:00'), and stores with no or elapsed slot always go to the END of the sorted result. This edge-case rule prevents an agent from incorrectly treating 'unknown' as a zero value.

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 text is longer than average, but every sentence is load-bearing: result contents, dependency note, sort policy, parameter values, and the edge-case semantics. It is front-loaded with what the tool returns, and the sorting rationale is necessary to justify a non-obvious rule 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?

The description covers the result shape, parameter semantics, and sorting edge cases, and an output schema exists so return format does not need to be repeated. What is missing is minor: no mention of behavior when the store list is large/empty or how the result interacts with the user's address, but for a 2-parameter read-only tool this is adequate.

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

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

Schema description coverage is 0% and there are no enums, so the description carries the entire load. It fully documents sort_by (speed/price/min_sum with their meanings) and order (asc|desc), and even explains the behavior of borderline values. The descriptions' param info is high-value and completes 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 states a concrete verb+resource: the list of stores available at the user's address, with the delivery window, price, minimum order sum, and cashback. It also distinguishes the tool from its many grocery siblings by noting it provides the appId/pointId that all other grocery tools need, positioning it as the entry-point listing tool.

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

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

The description gives an explicit usage rule — sort only when the user named a criterion, otherwise keep the order the bank returned ('this is a TOOL, not a policy'). It also signals when the tool fits in a flows as the source of the appId/pointId that the other grocery tools depend on. However, it doesn't name sibling tools to avoid (e.g., grocery_search) with explicit when-to-use-vs-not wording.

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 behavior. The description adds meaningful context beyond annotations: rates are only included when dates are provided, and no API call exists to accept bookHash for booking. This is extra behavioral information that annotations do not 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?

Two sentences pack the essential information: card fields, date-dependent behavior, hotel_id source, booking limitation, and next step. No filler or repetition, and the most critical limitation is placed at the end for emphasis.

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 information tool with an output schema, the description covers the core usage pattern and an important edge case (no booking). It tells the agent where to get the required parameter and what to expect. Combined with annotations and the output schema, an agent can call the tool correctly without further assumptions.

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 has zero descriptions for parameters, so the description carries a significant burden. It does clarify that hotel_id comes from hotel_search() and that dates trigger rates, but it does not explain limit, adults, children, or the format of checkin/checkout fields. Some parameter semantics are compensated, but others remain opaque.

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

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

The title and description clearly define the tool's output: a hotel card with address, check-in time, reviews, and rates when dates are supplied. It references hotel_search() as the source of hotel_id, which differentiates it from the hotel_search sibling. Though the description lacks an explicit verb, the resource and scope are unmistakable.

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 instructs that hotel_id comes from hotel_search(), establishing the intended call sequence. It explicitly states booking via MCP is not possible and points to an external app/site, which prevents misuse. It does not list all alternative tools, but the guidance is unambiguous enough for correct selection.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful context beyond that by stating that booking via MCP is impossible and that only search/compare is supported, which clarifies the practical scope.

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 core search parameters are presented first, followed by the no-booking restriction and a sibling referral. Every sentence adds value and there is no redundancy.

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

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

Given that the tool has an output schema and read-only annotations, the description provides all needed invocation essentials: query semantics, date format, child age format, and the alternative for deeper hotel details. It is complete for correct selection and 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 0%, but the description compensates by explaining query values, checkin/checkout date format, and children format. It does not explicitly describe adults/limit, but these are inferable from their names and schema defaults, making the parameter guidance strong but not 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?

Description states a clear verb and resource ('Поиск отелей') and explicitly explains what the query accepts (city, region, or hotel name). It differentiates itself from hotel_info by adding that booking is not possible and that price/cancellation details belong to hotel_info.

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 explicitly tells the agent this tool is only for finding and comparing hotels, not for booking, and directs specific rate/cancellation lookups to hotel_info(hotel_id, checkin, checkout). This gives a clear when-to-use and when-not-to-use 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?

The annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds the important 'active/current' scoping and the inclusion of amounts and terms, but does not disclose additional behavioral details such as whether expired policies are shown or how results are ordered.

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 entire description is a single, compact sentence that wastes no words. It front-loads the resource ('active insurance policies') and immediately gives useful distinctions: policy types and returned data.

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 zero parameters, an output schema, and strong annotations declaring read-only and idempotent behavior, the description covers all required guidance. It explicitly states the scope and key output fields, so nothing critical 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?

The tool has zero parameters and schema coverage is 100%, so the schema already fully documents the input surface. The description adds useful content-level context (amounts and terms) beyond the empty parameter schema, which is sufficient for this parameterless tool.

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 names the resource (active insurance policies: OSAGO/KASCO/travel) and the data returned (amounts and periods), making the tool's scope recognizable. However, it lacks an explicit verb like 'list' or 'return', so it relies on the tool name to imply the read action.

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 use for querying current insurance policies, but it does not explicitly state when to use it versus alternatives or what user questions map to this tool. There are no close insurance-specific siblings, so no explicit routing is needed, but the guidance is still more implied than 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 the tool readOnly, idempotent, and non-destructive, so the description doesn't need to repeat that. It adds meaningful behavioral context: the tool exposes brokerage and InvestBox accounts, and its output is a required dependency for investment operations. 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 crisp sentences: the first defines the scope, the second explains the critical relationship to sibling tools. Every word serves a purpose and the information is front-loaded.

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

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

For a zero-parameter tool with an output schema and safe annotations, the description conveys all essential context. An agent can correctly determine when to call this tool and what it provides to other investment tools.

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 has no parameters, so there is nothing for the description to explain on that side. The description adds value by naming the key output property 'brokerAccountId' and its role, though that is not input 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 identifies the resource explicitly — 'Инвест-счета' (investment accounts), qualified as brokerage and InvestBox. It further clarifies that the tool is the source of brokerAccountId for three sibling investment tools, which distinguishes it from them. Lacking an explicit verb such as 'list' or 'get', the purpose is clear but not fully 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?

The description states a precise usage rule: brokerAccountId from this tool is the only argument for invest_portfolio/invest_operations/invest_securities. This directly tells an agent when to call this tool instead of the sibling investment 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 convey read-only, idempotent, and open-world behavior. The description adds valuable non-obvious traits: operation types are not a stable published enum, 0 is a special limit meaning 'all returned by the bank', and results are newest-first. This is consistent with the openWorldHint and readOnlyHint.

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 resource is stated first, then ordering, then parameter semantics, and finally the important 'first call without filter' discovery strategy. Every sentence contributes non-duplicative value, and no phrasing is wasted.

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 output schema exists and annotations cover safety properties, the description handles the most important complexities: dynamic operation_type values, limit's dual request/output effect, and newest-first ordering. The main remaining gap is the unexplained source or purpose of broker_account_id, but sibling tools like invest_accounts likely supply that value.

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

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

With 0% schema description coverage, the description must explain all parameters, and it does explain limit and operation_type clearly, including the special 0 behavior and the dynamic list of observed values. However, the required broker_account_id parameter receives no explanation, leaving the agent to infer its purpose from the name alone.

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 identifies the resource (brokerage operations), the ordering behavior ('новые сверху'), and filtering limits, so an agent can infer that this tool returns a list of brokerage operations. However, it does not use an explicit verb like 'list' or 'return', and it does not explicitly differentiate itself from sibling tools such as list_operations or card_operations.

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

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

The description provides actionable in-tool usage guidance: new operations are on top, limit behaves differently when set to 0, and operation_type should be left empty first so the agent can discover available values before filtering. It does not, however, discuss when to choose this tool over related investment or operations siblings, stopping 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 declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered structurally. The description adds contextual behavior by indicating the result is period-based and includes historical/monthly valuations, but it does not disclose additional operational traits such as computed vs raw data, update timing, or limitations. 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 short and front-loaded: it names the resource, enumerates the data categories, and gives the account ID source. It earns its place, though a touch more explicit parameter detail would improve it without bloating the 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?

There is an output schema and detailed annotations, so the description does not need to explain return values or safety. However, given that the tool sits among several invest_* tools and has two parameters, the description leaves the days/period parameter under-explained and does not clearly differentiate selection from invest_operations. This is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the purpose and source of broker_account_id as 'from invest_accounts()', but it does not explain the 'days' parameter beyond the phrase 'за период', which only weakly implies a time window. The agent is left without clear semantics for the duration, unit, or effect of the optional period 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?

The description clearly identifies the tool as 'Портфель статистика' — portfolio statistics — and enumerates what it covers: deposits/withdrawals, coupons, dividends, and monthly valuation. This gives an agent a concrete sense of the resource and data, and it is distinct enough from related tools like invest_operations, though it does not explicitly contrast itself with them.

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 meaningful prerequisite — broker_account_id comes from invest_accounts() — but it does not state when to choose this tool over siblings like invest_operations or invest_securities. There is no exclusion guidance or alternative selection logic, so the usage guidance remains mostly implicit.

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 readOnlyHint, idempotentHint, and destructiveHint: false. The description goes further and discloses a genuinely non-obvious behavior: a broker account may have several portfolios, the portfolio brokerAccountId does not match the account id from invest_accounts(), and an empty response for a specific id is not conclusive evidence that there are no securities. This directly prevents a likely misinterpretation of results.

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 every sentence earns its place: it states the returned fields, defines the parameter contract, and warns about the multiple-portfolio edge case. It adds the important 'Учти' caveat without burying the primary usage 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?

The tool takes one optional parameter, and the description covers the parameter's source, default behavior, a subtle id mismatch, and a fallback invocation strategy. The tool reports an output schema, so return-value details do not need to be repeated; the description already names the main fields anyway.

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 no description for broker_account_id, so schema description coverage is 0%. The description compensates fully by explaining where the value comes from, what an empty value means, and the key id-mismatch caveat. For a single optional parameter, this is more than sufficient semantic detail.

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 explicitly states what the tool returns — 'тикер, количество, текущая цена, доля и доходность' — so the resource and scope are clear. It does not use an explicit verb like 'get' or 'list', and it does not directly contrast with sibling tools such as invest_portfolio or invest_operations, so it stops just short of full differentiation.

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 operational guidance: broker_account_id should come from invest_accounts(), and omitting it means all portfolios. It also gives a concrete recovery instruction — if a specific id returns empty, call without arguments and inspect the available portfolios. It does not explicitly say when to prefer this tool over the nearby invest_portfolio or invest_operations alternatives.

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, openWorld, and non-destructive. The description adds that this is a ping that extends the current session, but it does not mention edge-case behavior such as handling an already-expired session.

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 short sentence that front-loads the core idea: ping, extend session. Every word contributes value and there is no redundancy.

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

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

For a zero-parameter tool with an output schema and strong annotations, the description is nearly complete. The main missing context is router guidance relative to refresh_session, but this is a minor gap rather than a functional one.

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

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

The tool has zero parameters, and schema description coverage is 100%, so there is nothing missing for the agent to interpret. The description does not need to explain parameter meaning because no parameters exist.

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: ping and prolong the session. It clearly separates the tool from a generic status check, though it does not explicitly contrast it with refresh_session.

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 as a lightweight keepalive heartbeat to extend an active session. It does not explicitly state when to prefer this over refresh_session or session_status, nor does it give 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 establish readOnlyHint, idempotentHint, and no destructive effect, so the description only needs to add behavioral context beyond those. It does so by clarifying that the result is an account-level aggregate view containing balances, cards, and both id and ucid, which is useful context for downstream tool choice.

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