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

While annotations already indicate non-read-only and non-idempotent behavior, the description adds important context: it triggers a courier search and marks the delivery as actually ordered. It also discloses error conditions (409 with specific codes) and recovery steps, which is valuable beyond the structured 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 states the main action and consequence in the first sentence, then provides essential operational and error-handling details. Every sentence serves a purpose with no filler, making it easy to scan.

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

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

Given the tool's complexity as a mutating action with potential 409 errors, the description adequately covers preconditions, version source, and error recovery. It lacks an explicit description of the return value, but since there is no output schema, the description still provides enough context for correct invocation in the broader flow of express_* 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 already provides 100% coverage with detailed descriptions for both parameters. The description adds extra value by clarifying that the version is derived from express_get_claim, reinforcing the schema's provenance guidance for claim_id. This goes beyond simply repeating schema info.

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: confirms a claim after successful evaluation (status ready_for_approval) and initiates courier search, making the delivery actually ordered. It specifies the resource (claim) and the specific context, distinguishing it from sibling tools like express_cancel_claim or express_create_claim.

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

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

The description provides clear usage context: it is meant for claims already in ready_for_approval status, and it instructs that the version should be taken from express_get_claim. It doesn't explicitly list alternative tools to avoid, but the required status and error handling imply when it is appropriate. This is slightly above baseline but not fully explicit about when not to use it.

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

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

Beyond the destructiveHint annotation, the description warns about financial consequences (paid cancellation fee), version-based concurrency (errors 409), and the ability to cancel confirmed claims. This adds valuable behavioral context without contradicting any 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, front-loaded with the main action, and efficiently covers prerequisites and error handling in three sentences with no redundancy.

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

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

For a destructive financial operation, the description adequately covers prerequisites, fee consequences, and error conditions. It doesn't describe the output, but no output schema exists, and the 100% parameter schema fills the gap.

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

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

The schema already covers all three parameters with detailed descriptions and an enum for cancel_state. The description reinforces where to get version and cancel_state but adds little new semantic information beyond the 100% schema coverage.

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

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

The description clearly states that the tool cancels a claim, including already confirmed ones, using a specific verb and resource. It distinguishes itself from siblings like express_cancel_info and express_accept_claim by focusing on the cancellation 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?

It explicitly instructs to call express_cancel_info first and pass its cancel_state, and to take version from express_get_claim. This provides a clear workflow and prerequisites, though it doesn't explicitly state when not to use the 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 already declare readOnlyHint, idempotentHint, and non-destructiveHint, and the description adds valuable behavioral context: it details the return structure (cancel_state with meanings) and indicates that paid cancellations return price fields. This goes beyond what annotations provide and clarifies the tool's role in the cancellation flow.

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 concise sentences front-loaded with purpose, followed by return value details. No filler or repetition of schema information, earning its place efficiently.

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

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

Despite lacking an output schema, the description completely explains the return values and their implications. Combined with the detailed schema for the single parameter, this tool is fully specified for safe and effective 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?

Input schema description covers 100% of the parameter meaning (claim_id, its length, and source). The description does not add extra parameter semantics, but since schema coverage is high, a baseline score of 3 is appropriate.

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

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

The description clearly states this tool returns cancellation conditions for a claim and specifies the cancel_state values (free, paid, unavailable). It distinguishes itself from the sibling express_cancel_claim by instructing to call it BEFORE cancellation, making its purpose and scope 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?

Explicitly instructs the agent to call this tool BEFORE express_cancel_claim, providing a clear when-to-use directive. It also implies usage for checking cancelability and pricing, which differentiates it from other siblings like express_get_claim or express_check_price.

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, covering safety. The description adds important behavioral details: price is returned as a string-decimal, not a number; typical errors (400 address_not_found, 409 estimating.cant_construct_route) are disclosed; and the output fields are listed. This goes beyond the annotations and aids client handling.

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 concise and front-loaded: it immediately states the primary purpose and the key differentiator (no order creation). It then lists return fields and typical errors in a compact, information-dense manner. Every sentence earns its place, with no redundancy.

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

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

For a tool with no output schema, the description adequately covers return values (price, currency_rules, distance_meters, eta, zone_id) and common error responses. It also notes the coordinate order and the option to use addresses. It does not exhaustively describe every possible error or edge case, but it provides sufficient context for an agent to use the tool effectively.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description mentions that route points can be coordinates and/or address, which is also in the schema. It does not add any extra meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Первичная оценка стоимости экспресс-доставки (день в день) БЕЗ создания заявки' (primary cost estimate for express delivery without creating an order). It explicitly distinguishes itself from siblings by mentioning the absence of order creation, and specifies the resource (express delivery) and the action (estimation). The mention of returning price, eta, etc., further clarifies its purpose.

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

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

The description provides clear context for when to use this tool: for preliminary cost estimation, and explicitly states 'without creating an order' (БЕЗ создания заявки), which serves as a when-not-to-use for order creation. However, it does not explicitly name alternative tools like express_create_claim, so it stops short of a full 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 fully discloses the non-obvious lifecycle: claim is not immediately active, status passes through new → estimating → ready_for_approval, and confirmation is required. It also explains idempotency semantics tied to request_id, complementing the idempotentHint=false annotation by clarifying the conditional behavior. No annotation contradictions.

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 four sentences long, with the critical 'ВАЖНО' warning up front. Every sentence earns its place: purpose, workflow, return fields, and idempotency. 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?

For a complex tool with 14 params, nested objects, and no output schema, the description covers the essential behavioral context: return fields (id, status, version, route_points, pricing, created_ts), the estimation/confirmation workflow, and idempotency. Parameter construction is not described but schema satisfies that need.

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

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

Schema coverage is 100%, with detailed descriptions for all 14 parameters, including auto_accept and request_id. The description reiterates these but does not add new parameter-level meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with 'Создаёт заявку на экспресс-доставку' (creates an express delivery claim), using a specific verb and resource. It also distinguishes from siblings by stating that the claim must be confirmed via express_accept_claim or auto_accept=true, clearly situating this as the creation step in the workflow.

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 clear workflow context: the claim goes through estimation and needs subsequent confirmation via express_accept_claim, or the agent can pass auto_accept=true. This implies when to use this tool versus the acceptance tool, though it doesn't mention how to choose between this and pricing/sibling 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?

Despite having readOnlyHint and idempotentHint annotations, the description adds a crucial behavioral warning: error_messages may appear inside a successful 200 response. This goes beyond annotations and is valuable for correct handling.

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 main purpose and includes a concise field list, but the long enumeration of statuses adds some bulk. Still, every element (fields, statuses, warning) serves a purpose, so it earns a 4.

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?

Since there is no output schema, the description fills the gap by listing all key response fields (status, version, items, pricing, performer_info, eta, timestamps) and even enumerates possible status values. The additional error_messages caveat makes it fully contextual for a get tool.

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

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

The single parameter claim_id is fully described in the schema (including format and source). The description does not add extra parameter-level detail, so it relies on the schema's 100% coverage, yielding the baseline score of 3.

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 'Полная информация по заявке' and enumerates the fields returned, making it clear this is a read/get operation for claim details. It also lists possible statuses, distinguishing it from sibling tools like accept/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?

The description notes that the version field is needed for accept/cancel, providing a usage hint. However, it does not explicitly mention when not to use this tool or name alternative tools for specific scenarios, so it falls 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds substantial value by detailing the response structure (lat, lon, timestamp, accuracy, speed, direction, route_points) and error codes (404, 409), giving the agent a clear expectation of behavior beyond the annotations.

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

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

The description is two sentences long, front-loaded with the purpose, and includes only essential information (response shape and error codes). No redundant words 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?

For a simple read-only operation with one parameter and no output schema, the description is remarkably complete: it specifies the response fields, error conditions, and usage context. All necessary information is provided without needing to consult other tools or documentation.

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

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

Schema description coverage is 100% for the only parameter (claim_id), and the schema already explains its origin and length. The description does not add further parameter-specific semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states that the tool returns the current geolocation of the courier for an active claim, with specific response fields (position, route_points, sharing_link). This distinguishes it from sibling tools like express_get_claim (claim details) and express_tracking_links (tracking links). The verb is implied but unambiguous from the resource naming.

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 specifies that the tool applies to 'active claim' and mentions a 409 error when the claim is not in active status, giving clear context on when it is appropriate to use. However, it does not explicitly name alternative tools or provide 'when-not-to-use' guidance, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable behavioral context: sorting by creation date, return of a cursor, and the rule that passing cursor makes other filters unnecessary. No contradiction with annotations.

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

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

Two sentences, front-loaded with purpose, followed by essential pagination details. No redundant 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?

Given the 12 parameters are all schema-described and annotations are present, the description covers return shape, pagination, and sorting. It lacks explicit error cases but is otherwise complete for a search 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 covers 100% of parameters. The description supplements this by clarifying the relationship between cursor, offset, and limit, and that cursor supersedes other filters. This adds semantic value beyond the schema.

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

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

The description states 'Поиск заявок по фильтрам с пагинацией' (search claims by filters with pagination), specifying the verb, resource, and sorting. It distinguishes from sibling express_get_claim by noting the return format matches that tool while this one searches multiple claims.

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 explains pagination options (offset/limit vs cursor) and the cursor behavior, giving clear context for usage. It does not explicitly contrast with sibling tools, but the search-vs-single-claim distinction is implied via the reference to express_get_claim.

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 read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: the exact response structure, the constraint that sharing_link exists only for destination points, and the specific 409 error codes (inappropriate_status, unknown_tracking_links). This enriches the agent's understanding of expected behavior.

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

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

The description is two sentences, front-loaded with the main purpose, and includes only essential details: output structure, sharing_link constraint, and error codes. No redundancy or fluff.

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

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

For a simple single-parameter read-only tool with no output schema, the description adequately explains the return value, constraints on the data, and potential errors. It is complete enough for an agent to understand what to expect and how to interpret results.

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 100% coverage for the sole parameter (claim_id) with a clear description of its origin and format. The tool description adds no additional parameter semantics, so baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: it returns public tracking links for a courier that can be shared with the recipient. It provides the output structure (route_points with id, type, visit_order, sharing_link) and specifies that sharing_link is only available for destination points, which distinguishes it from sibling tools like express_get_claim or express_performer_position.

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 context for when to use the tool: to obtain public tracking links intended for the recipient. It does not explicitly name alternatives or when not to use it, but the context is clear and supported by the distinction of sharing_link for destination points only.

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 annotations (destructiveHint=true, readOnlyHint=false), the description discloses important behavioral context: the cancellation is conditional on order status, it returns specific fields (status, reason, description), and it lists error codes 403 and 404. This provides the agent with actionable expectations not present in the structured data.

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

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

The description is three concise sentences, each serving a distinct purpose: stating the action, specifying the cancellation scope and return values, and listing error codes. There is no redundancy or excessive detail.

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

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

For a single-parameter cancellation tool with annotations covering safety and destructiveness, the description provides all necessary operational context: the cancellation precondition, return shape, and error semantics. Even without an output schema, an agent can correctly invoke and interpret the result.

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

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

The single parameter request_id is fully described in the schema (id заказа в платформе (из platform_confirm_offer)), giving 100% coverage. The description adds no additional parameter-level detail, so the baseline score of 3 applies.

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

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

The description clearly states the action: 'Отменяет заказ в логистической платформе' (cancels an order in the logistics platform). It also distinguishes from siblings like express_cancel_claim by specifying 'Курьерский заказ' (courier order) and the platform context, making the purpose specific and unambiguous.

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

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

The description provides a clear usage condition: cancellation is possible only up to the status DELIVERY_TRANSPORTATION_RECIPIENT, which tells the agent when this tool is applicable. However, it does not explicitly mention alternatives (e.g., express_cancel_claim for express orders), so it lacks explicit 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 indicate readOnlyHint=false (mutation) and idempotentHint=false. The description adds behavioral details: it creates an order, returns a request_id, and can fail with 400 if the offer is expired. This goes beyond the annotations without contradicting 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?

Three sentences, each adding necessary information: purpose, return value and related tools, and a critical error condition. No fluff, front-loaded with the core action.

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 tool with one parameter and no output schema, the description covers all essential aspects: what it does, what it returns, how to use that return value, and when it might fail. The annotations cover idempotency and read-only hints, so nothing critical is missing.

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

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

The schema provides 100% coverage of the only parameter (offer_id) with a description tying it to platform_create_offers. The description adds extra semantic context: the offer must not be expired and should be the selected one, reinforcing the parameter's meaning beyond the schema.

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

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

The description clearly states a specific action: 'Бронирует выбранный оффер — СОЗДАЁТ заказ' (books the selected offer — creates an order). This distinguishes it from sibling tools like platform_create_offers (which creates offers) and platform_get_request (which reads requests).

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 clear usage context: it is used after receiving an offer from platform_create_offers, and the resulting request_id is meant to be used with platform_get_request, platform_request_history, and platform_cancel_request. It also mentions a precondition (offer not expired). No explicit exclusions for when not to use it, but the workflow is well implied.

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 important behavioral context beyond annotations: the order is not created until confirmation, offer is valid until expires_at, and money amounts are in kopecks. It also exposes the specific error case. While it doesn't enumerate all side effects, it clarifies the state lifecycle.

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

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

The description is a single, focused paragraph that front-loads the main purpose, then packs essential details (response structure, workflow, error, units) without redundancy or 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?

Given the lack of an output schema, the description provides a partial response structure, error handling, and workflow context, which is substantial for a 10-parameter tool. It misses explicit alternatives to express tools, but the sibling list helps fill that gap.

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

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

Schema description coverage is 100%, so each parameter is already explained in the schema. The description adds cross-cutting details (kopecks, error condition) but does not provide per-parameter meaning beyond what the schema offers, so baseline 3 is appropriate.

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

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

The description clearly states it calculates delivery options (offers) for 'another day' orders, using specific verbs and resources. It also distinguishes itself from the sibling tool platform_confirm_offer by explaining that the selected offer is booked there.

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 describes the workflow: calculate offers first, then use platform_confirm_offer to book. It also provides an error condition (400 no_delivery_options) for when no options exist. However, it does not explicitly contrast with express delivery siblings, so exclusion guidance is missing.

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. The description adds value by specifying the response fields (state, request, courier_order_id) and enumerating possible cancellation reasons (SHOP_CANCELLED, USER_CHANGED_MIND, etc.), which is useful contextual detail beyond the structured metadata.

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 dense sentence that efficiently lists key response elements. It's not overly verbose, though the inclusion of many cancellation reason codes makes it slightly run-on.

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 tool with no output schema, the description covers the main output structure and explains possible state reasons. It doesn't explain the slim parameter or request_code filter behavior, but those are documented in the schema, so the description is reasonably 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?

The schema provides complete descriptions for all three parameters (request_id, slim, request_code), so the description adds no additional parameter-level meaning. It mentions courier_order_id, but that is an output field, not a 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 names the resource (order) and lists the specific contents (state, request, courier_order_id), making it clear this is an order-information tool. However, it uses a noun phrase ('Информация о заказе') rather than an explicit verb like 'retrieve' or 'get', and it doesn't explicitly contrast with 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?

There is no guidance on when to use this tool versus alternatives such as platform_request_history, raw_request, or platform_cancel_request. The description doesn't state prerequisites, exclusions, or typical use-cases.

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 read-only, open-world, and idempotent behavior, so the description adds value by specifying the exact return fields, warning about the unbounded empty query, and explaining the id's role in other tools. It does not contradict annotations.

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

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

The description is three focused sentences: functionality and return format, cross-reference, and a critical usage warning. It is front-loaded and contains no redundant 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?

Given the read-only nature, complete schema coverage, and lack of output schema, the description adequately covers return structure and a key usage caveat. It doesn't elaborate on every field's semantics or pagination, but the schema sufficiently handles parameter details.

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

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

Schema coverage is 100% for all 11 parameters, so the baseline is 3. The description only generically mentions filters (geo_id, coordinate range, pickup_point_ids) and does not add per-parameter meaning beyond what the schema already provides.

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

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

The description uses the specific verb 'Список' (list) with a clear resource ('ПВЗ, постаматов и точек самопривоза') and distinguishes from express siblings by noting the platform contour and delivery 'в другой день'. This makes the purpose unambiguous.

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

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

It identifies the platform-specific context and cross-references platform_create_offers, indicating a concrete use case. The warning about empty bodies and filter recommendations provides practical guidance, though it doesn't explicitly state when to avoid this tool in favor of 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond annotations by detailing the return structure (status, description, timestamps, optional reason) and the temporal scope ('от создания до текущего момента'). This helps the agent understand what data will be returned without needing an output schema.

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

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

The description is one sentence and front-loads the purpose. It packs the output format into the sentence without excessive wording. The only minor issue is the unexplained acronym 'НДД', which might confuse agents unfamiliar with the domain, so it loses one point.

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

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

For a single-parameter read-only tool with strong annotations, the description is comprehensive. It specifies the output structure and temporal scope, which is essential since there is no output schema. The presence of siblings is well-handled by the clarity of the tool's unique purpose. No significant gaps remain.

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

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

Schema description coverage is 100% for the only parameter (request_id) and its description already explains that it is the order ID from platform_confirm_offer. The tool description does not add additional parameter semantics, so it does not exceed the baseline for full schema coverage.

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

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

The description clearly states the tool returns the history of order status changes ('История смены статусов заказа') and specifies the exact output structure (state_history array with fields). This distinguishes it from sibling tools like platform_get_request, which presumably fetches the current request state rather than its full timeline.

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

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

The description provides clear context: it is used to get the history of status changes from creation to the current moment. It does not explicitly name alternatives or exclusions, but the purpose is so specific that an agent can infer when to use this tool. The schema also hints that the request_id comes from platform_confirm_offer, which adds prerequisite context.

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 flag destructive/read-only nature, but the description adds important behavioral details: the retry policy (5xx/network errors only for GET) and host/path conventions for each contour. This goes beyond the structured 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, using only two sentences to convey purpose, param roles, and cautions. Every sentence is informative with no irrelevant 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 generic raw-request tool with 5 params and no output schema, the description covers purpose, usage, parameter roles, and security cautions. It does not mention auth prerequisites or error response structure, but these are not strictly required given the fallback nature.

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?

Although the schema covers 100% of parameters with descriptions, the description enriches these by explaining the mapping of `contour` to host and path prefix patterns, and clarifies that `body` is sent as JSON. This adds meaning beyond the schema.

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

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

The description clearly states it is a fallback tool for direct calls to any B2B API method not covered by dedicated tools, with a specific list of example endpoints. This clearly distinguishes it from siblings like express_create_claim or platform_get_request.

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

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

Explicitly states 'for endpoints without a dedicated tool' and labels itself as a fallback, giving clear when-to-use guidance. It also cautions about modifying operations and the GET-only retry policy, which helps avoid misuse.

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