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

No annotations are provided, so the description carries the full burden. It discloses the date constraint and server rejection behavior, which is valuable. However, it doesn't mention response structure or potential side effects beyond the date restriction, though for a balance read it likely suffices.

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

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

The description is a single sentence that front-loads the purpose, then states the constraint, and concludes with the alternative tool. Every clause adds value, with no redundant information. It is efficient and well-structured.

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 one parameter, no output schema, and no annotations, the description covers the essential aspects: purpose, constraint, and alternative for other dates. It lacks explicit detail about the response format, but for a simple balance query, this is likely sufficient. The pointer to wata_finance_daily fills context for historical needs.

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

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

The schema already documents the date parameter with format and allowed values, and coverage is 100%. The description adds the specific constraint that only today's or yesterday's UTC date is accepted and that other values are rejected, which goes beyond the schema's baseline and helps the agent correctly construct the parameter.

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

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

The description clearly states the tool returns the terminal balance for a given date ('Баланс терминала на дату'). It distinguishes itself from sibling tools like wata_finance_daily by specifying the date constraint and explicitly naming the alternative for earlier periods, so an agent can tell them apart.

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 guidance: the date is mandatory and can only be today or yesterday in UTC, with other values rejected by the server. It also instructs to use wata_finance_daily for earlier periods, providing a clear when-to-use vs. when-not-to-use and an alternative.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It discloses the response contains a 'url' field that can be passed to the payer, and states limits on amount and expiration. It does not mention side effects beyond creation, potential errors, or authentication details beyond the token. This is moderate coverage, but not comprehensive, so a 3 is appropriate.

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

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

The description is a concise 4-sentence paragraph that front-loads the primary action, then explains token behavior, response content, and constraints. There is no redundancy or filler, though it could be slightly more structured with explicit sections, but it is efficient and readable.

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 15 parameters, including a nested subscription object, and no output schema, the description provides only high-level context: limits, response field 'url', and token-terminal relationship. It does not explain interactions between parameters, error semantics, or the full response structure. While the schema descriptions handle parameter meanings, an agent might still be uncertain about edge cases (e.g., how arbitrary amount settings interact), so completeness is moderate.

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 all 15 parameters already have descriptions. The tool description adds extra constraints for amount (minimum 10 RUB/1 USD/EUR) and expiration (10 minutes to 30 days), which are not in the schema. However, it does not add meaning for other complex parameters like subscription or arbitraryAmountPrompts. Since the schema already covers the basics, and the description adds some value, a 3 is warranted.

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 verb ('создаёт' - creates) and resource ('платёжную ссылку' - payment link), and adds distinguishing context: it works via the public API and uses the token to identify the terminal, which differentiates it from sibling tools like wata_link_create. It also mentions the response field 'url' that can be given to the payer, further clarifying the tool's exact role.

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 implicit usage guidance: it indicates the token determines the terminal and that the link is created via the public API, implying this is for ACQ terminal operations. It also provides constraints (amount, lifetime) that guide when the tool is applicable. However, it does not explicitly mention alternatives or when not to use this tool versus similar siblings like wata_link_create, 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?

No annotations are provided, so the description carries the burden of explaining behavior. It discloses that the returned link is complete and includes the digitalGood block, which goes beyond what the name alone implies. However, it does not mention authentication, error cases, or any other behavioral constraints, leaving some gaps typical of a read operation.

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, compact sentence that immediately states the main action and the key differentiator. There is no redundant wording, 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 simple getter with one well-documented parametercars, the description is nearly complete: it explains the main return value and the distinctive digitalGood block. It does not cover error behavior or detailed response structure, but these are less critical for this low-complexity tool.

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

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

The schema has 100% coverage for the single parameter 'id', which is described as the UUID of the payment link. The description adds no additional meaning to the parameter, 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 states a specific verb ('Возвращает'), a clear resource ('ссылку'), and adds a distinctive detail: the full link includes the digitalGood block, which search results omit. It clearly identifies the tool's purpose of fetching a complete payment link by ID, though it does not explicitly differentiate from the similarly named sibling wata_link_get.

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 'которого нет в результатах поиска' implies a key usage scenario: use this tool when the full link data, including digitalGood, is needed beyond what search/list endpoints return. It does not explicitly name the alternative tool or state exclusions, but the context is clear enough for an agent to make a reasonable 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that pagination is page-based via skipCount and maxResultCount, which is a meaningful behavioral trait. However, it doesn't mention default sort order, maximum result capabilities beyond the schema, or any operational characteristics like rate limits or response fields. For a read-only search tool, this is adequate but not thorough.

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

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

Two sentences with no wasted words. The core purpose is front-loaded, and the second sentence delivers a precise operational detail about pagination while contrasting with a sibling tool. Every sentence earns its place.

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

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

With 10 parameters and no output schema, the description is somewhat lean. It clarifies pagination but leaves out expected result shape, default result count, and the relationship to potentially overlapping siblings like wata_links_list and wata_acq_link_get. It's sufficient for a simple filtered list call, but the missing context around output and alternatives creates ambiguity.

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 80%, so most parameters are already described in the schema. The tool description adds value specifically for skipCount and maxResultCount, which lack descriptions in the schema, by clarifying they define page-based pagination. This compensates for the low-coverage parameters and raises the score above baseline.

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 and resource: 'searches terminal payment links'. The name and title are not just repeated; the description clarifies it's about searching terminal-specific payment linksancing. However, it doesn't explicitly differentiate from siblings like wata_links_list or wata_acq_link_get, leaving the agent to infer the distinction from the naming convention.

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 usage guidance is the pagination contrast: 'skipCount and maxResultCount, unlike transaction search where a cursor is used'. This hints at a use case but does not state when to prefer this tool over alternatives such as wata_links_list or wata_acq_link_get, nor does it provide exclusions or selection criteria. The agent is left to guess the appropriate 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?

With no annotations provided, the description carries the full burden. It discloses a critical behavioral constraint—the cryptogram must be generated client-side and cannot be assembled on the server—which is essential for correct usage. However, it does not mention any other behavioral aspects such as side effects, reversibility, or response format, leaving gaps for a mutation tool. The key prerequisite is disclosed, but the description falls short of full transparency.

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 most critical constraint (cryptogram cannot be server-generated). It wastes no words and efficiently conveys the prerequisite and the fallback option. Every sentence earns its place.

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

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

Despite the tool's complexity (9 parameters, no output schema, no annotations, low schema coverage), the description covers only the cryptogram prerequisite. It does not explain other parameters, expected response, error handling, or idempotency. For a payment mutation tool, this is significantly incomplete; an agent would need to infer much from schemas and external knowledge.

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 only 22%, so the description must compensate for undocumented parameters. It adds no new semantics beyond what the schema already states for cardCrypto (which is already described as coming from the client script). The other required parameters (amount, currency, ip) are not explained in the description. Given the low coverage and the lack of parameter elaboration, this dimension is weak.

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 performs direct card payment using a cryptogram. It specifies the verb (оплата) and resource (картой по криптограмме), and explicitly distinguishes it from the sibling wata_acq_link_create by stating the alternative when no cryptogram exists. This unambiguously differentiates it from other payment tools like SBP and TPay.

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 guidance: use this tool when you already have a cryptogram, and if not, use the payment link (wata_acq_link_create). It names the alternative tool directly and gives the condition that selects it, leaving no ambiguity for the agent.

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

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

With no annotations provided, the description bears the full burden of behavioral disclosure. It clearly explains that the tool creates a payment and returns a redirect link, and it adds important constraints: rubles-only, no currency field, and H2H integration required. It stops short of describing failure behavior or link lifetime, but the core behavior is well covered.

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, fully front-loaded with the primary purpose Apaand contains no filler or redundant repetition. Every sentence adds a distinct piece of 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 has 10 parameters, a nested deviceData object, no output schema, and no annotations, so a two-sentence description is insufficient. Missing information includes the meaning of several optional parameters, the expected structure of a successful response beyond sbpLink, and error or authentication requirements.

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 only 40%, and the description does not compensate for the six undocumented optional parameters such as orderId, email, phone, lastName, firstName, and description. The only parameter-level insight added is the rubles-only constraint, which clarifies the amount field.

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 and resource: 'Создаёт платёж по СБП' (creates an SBP payment). It clearly names the output sbpLink and the payment method, distinguishing it from sibling payment tools like wata_acq_pay_card and wata_acq_pay_tpay.

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 useful precondition ('Требуется прямая интеграция H2H') and a restriction ('Только рубли'), but does not explicitly state when to choose this tool over alternatives or when not to use it. The usage context is mostly implied from the tool name and description.

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

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

With no annotations, the description must carry all behavioral disclosure. It only adds the currency constraint (rubles, no currency field) and the return of tPayLink. It omits side effects, error cases, idempotency, or whether the payment is reversible.

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 brief and front-loaded, which is good, but it is also thin. It could have included key details without becoming verbose, so it earns a middle score for structure.

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

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

For a payment creation tool with 7 parameters and no output schema, the description is insufficient. It does not explain required fields, the deviceData structure, or the full response format beyond tPayLink, leaving significant gaps for correct invocation.

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

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

Schema coverage is 57%, yet the description adds no parameter-level details beyond noting the absence of a currency field. It does not compensate for undocumented params like email, orderId, or description, leaving agents without semantic guidance for those.

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 ('creates'), a resource ('payment via T-Pay'), and the return value ('tPayLink'), making its purpose unambiguous. It also distinguishes itself from sibling payment tools (SBP, card) by naming T-Pay explicitly.

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

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

There is no guidance on when to choose this tool over alternatives like wata_acq_pay_sbp or wata_acq_pay_card. The description implies T-Pay is the method but does not state selection criteria or exclusions.

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

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

With no annotations provided, the description carries the full burden and does a good job: it explicitly warns that this is an irreversible monetary operation, notes that currency is inherited from the original transaction, details amount validation, and states a terminal product restriction. It does not describe response/return behavior, but the critical irreversible nature and operational constraints are clear.

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 a critical warning: 'НЕОБРАТИМАЯ ДЕНЕЖНАЯ ОПЕРАЦИЯ'. Each sentence covers a distinct requirement or constraint; there is minimal filler. It could slightly over-explain constraints already implied by the schema, but overall it is efficiently structured.

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 3-required-parameter mutation without output schema, the description gives enough operational context to execute correctly: required fields, constraints, irreversible flag, and a restriction. It still lacks what happens as result or how to identify the refunded transaction afterward, and it fails to connect to related refund endpoints, making it complete for calling safely but not fully complete for follow-up steps.

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 provides 100% parameter descriptions, the baseline is 3. The description adds semantic value by explaining that currency is taken from the original transaction, that the amount must not exceed the available balance, and that only two fields are required in practice. This goes beyond the schema's simple 'Сумма возврата'.

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 'Возврат через публичный API' and description clearly identify this as a refund operation that creates a refund using original transaction ID and amount. The verb/resource relationship is specific, but it does not explicitly distinguish itself from the sibling wata_transaction_refund, which also appears to handle refunds.

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 parameter constraints and a terminal type restriction, but it offers no guidance on when to use this tool versus alternatives like wata_transaction_refund. There is no explicit when/when-not statement regarding sibling tools, so the usage context is mostly unaddressed.

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 are absent, so the description carries the full behavioral burden. It does add a genuinely useful disclosure: the commission field is named totalCommission here but commission in the webhook payload. However, it says nothing about authentication, error behavior, response format, or other operational traits, leaving a thin behavioral 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?

Two compact sentences with the core purpose front-loaded and no filler; the webhook discrepancy note is placed second and earns its place. Slightly under-specified overall, but as far as economy of words it is tight.

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 fetch with the param fully documented, the description covers the essential use (supply an ID, get a transaction card) and flags the one likely-to-matter naming gotcha. Yet with no annotations and no output schema, it omits any return shape, error, or auth detail — adequate, not 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 coverage is 100% — the single required parameter id is already documented as 'UUID транзакции'. The description adds no parameter-level meaning beyond the schema, so the baseline 3 for high-coverage schemas 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 says only 'Карточка транзакции' (transaction card), a noun phrase rather than a clear verb+resource statement; purpose actually comes from the title 'Транзакция по идентификатору (публичный API)'. The description does convey a transaction-fetch operation but offers no differentiation from the sibling wata_transaction_get, which appears to perform a near-identical retrieval.

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 guidance on when to use this tool versus alternatives such as wata_transaction_get or wata_acq_transaction_find. The webhook note is about field naming, not usage selection. There is no when/when-not, no prerequisites, and no sibling 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?

With no annotations provided, the description carries the full burden, and it does add one important behavioral trait: cursor-based pagination and how to obtain the next page via cursorId and cursorAmount from previous response fields. However, it does not disclose other behavioral aspects like default result limits, whether filters are all optional, or any auth requirements.

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. The first sentence states the core purpose, and the second conveys the critical pagination behavior. Every word earns its place.

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

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

For a tool with 13 optional parameters, no output schema, and no annotations, the description covers the most important invocation detail (cursor pagination) but leaves the agent to infer much of the rest from schema property names and enums. It is adequate but not complete; absent return-shape details and more explicit filter semantics.

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 62%, so the schema already documents most parameters. The description adds meaningful semantics for cursor-related parameters by explaining their relationship to nextCursorId and nextCursorAmount, which goes beyond the schema. But it does not compensate for undocumented params like orderId, amountTo, or amountFrom.

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: 'Ищет транзакции терминала' (searches terminal transactions), which clearly identifies the action and scope. The title adds 'публичный API' to further characterize it, and the name distinguishes it from single-transaction getters like wata_acq_transaction_get, though it does not explicitly contrast it with sibling list 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 wata_transactions_list or wata_acq_transaction_get. The only usage hint is the cursor pagination instruction, which is about how to page through results, not about selecting this tool over 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It indicates a listing operation, which is read-like, but does not explain what 'extended' means, what data is returned, whether admin privileges are required, or how this list differs behaviorally from the standard subscription list.

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, compact sentence with no filler words. It front-loads the main purpose ('extended list of subscriptions') before the access context. It is concise, though very sparse.

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 only two optional pagination parameters and a clearly documented schema, the description is minimally adequate. However, the term 'extended' is vague, there is no output schema, and no information about return shape or admin requirements, leaving gaps for an agent deciding whether this tool meets its 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?

The input schema already documents both parameters (skipCount and maxResultCount) with descriptions and constraints, so schema coverage is 100%. The description adds nothing about pagination behavior or parameter usage, which keeps this at the baseline 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 names a specific resource ('subscriptions') and an action ('list'), and adds a distinguishing context: it is an 'extended list' available from the administrative section. It does not explicitly name a sibling like wata_subscriptions_list, so the differentiation is clear but not fully 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?

The phrase 'available from the administrative section' implies this tool is for admin-side views, but the description gives no explicit when-to-use guidance, no exclusions, and no reference to alternative tools such as wata_subscriptions_list or wata_subscriptions_counts. An agent would have to infer the intended use case.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool sends credentials, requires a second factor, and that arguments appear in plain text in conversation history – a critical security behavior. No annotation contradiction 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?

Two sentences with zero waste: the first states the action and required next step; the second delivers the preferred usage and security warning. Well front-loaded and to the 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 two-step authentication flow, the description tells the agent exactly what to do (send credentials, then call wata_auth_verify) and how to avoid leaking credentials. No output schema is needed for this step, and nothing an agent needs to call it correctly is missing.

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

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

The schema already provides per-parameter descriptions with the same guidance ('Лучше не передавать', use env vars). The description reinforces this and adds the security rationale, which is valuable beyond the schema but doesn't introduce new parameter semantics.

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

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

The description states a specific action ('Отправляет email и пароль') and resource (login step), and explicitly names the next step (wata_auth_verify), distinguishing it from auth_status and auth_logout 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?

It gives explicit when-to-use guidance: prefer calling without arguments to use environment variables, and warns against passing the password directly, with the condition 'только если другого способа нет'. This clearly routes the agent to the preferred invocation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does a good job by stating both the server-side effect (session termination) and the local side effect (cookie clearing). It does not mention idempotency or the result of calling logout without an active session, but the primary behavioral traits are transparent.

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

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

The description is a single concise sentence that front-loads the key action ('terminates the session') and adds the important side effect of clearing local cookies. There is no filler, repetition, or unnecessary detail.

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

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

For a zero-parameter, no-output-schema action, the description covers what happens both server-side and locally, which is sufficient for an agent to understand the operation. It could add a note about requiring an active session, but the lack of parameters and simple semantic scope keep this from being a significant 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 tool has zero parameters)Skip and no input schema properties, so there is nothing for the description to clarify. Per the baseline guidance for 0-parameter tools, a score of 4 is appropriate because no parameter semantics burden exists.

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 'Завершает' (terminates) against a clear resource: the session on the server, and additionally states it clears locally saved cookies. This clearly differentiates it from sibling auth tools like wata_auth_login, wata_auth_status, and wata_auth_verify.

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 intended use is strongly implied by the name, title, and description, but there is no explicit statement of when to call it, any prerequisite that an active session must exist, or a contrast with related auth tools. The tool is simple enough that the omission is not fatal, but guidance is still implicit rather than explicit.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does indicate this is a read-only status check that returns current user data, but it does not explain what happens when no session exists or whether the tool requires any prior authentication 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?

The description is a single focused sentence with no filler. It front-loads the core action and immediately states what information the tool reveals.

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 status tool, the description is mostly adequate: it names the check and the returned data. However, with no output schema or annotations, it would be more complete if it described the negative case (no active session) or the expected response shape.

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

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

The tool has zero parameters and the schema is empty, so schema coverage is effectively total. There is nothing for the description to add about parameter meaning; the baseline of 4 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 a specific verb and resource: checking whether an active personal-account session exists and showing the current user's data. It distinguishes itself from auth_login and auth_logout by focusing on status, though it does not explicitly differentiate itself from wata_profile_get.

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 instead of related auth or profile tools. An agent is left to infer that this is the 'check current session' tool without explicit routing or exclusion criteria.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly covers: session persistence (saved locally, ~60 days), code one-time nature and short validity, failure behavior (kills the 2FA request), and a security caveat (code appears in dialog history). This is exemplary transparency for a sensitive auth operation.

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, with each sentence adding meaningful operational or security context. It's slightly longer than strictly necessary, but every sentence earns its place by covering a distinct aspect: completion, session lifetime, code expiry, failure mode, and security note. The most critical operational detail (call immediately) 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 single-parameter auth completion tool with no output schema, the description covers everything an agent needs: what it does, when to call it, what happens on success and failure, and a security warning. The session lifetime and code expiry are critical operational details that are all present. No 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 coverage is 100%, so the schema already documents the 'code' parameter with its type, minLength, and description. The tool description adds context about the code's one-time nature and urgency, but doesn't add new parameter-level semantics beyond what the schema provides. 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 the tool's function: completing login by accepting a code from an email. It explicitly identifies this as step 2 of the authentication flow, which distinguishes it from sibling tools like wata_auth_login and wata_auth_status. The verb 'Завершает вход' (completes login) is specific and unambiguous.

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

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

The description provides explicit timing guidance: call immediately after receiving the code because it expires in minutes. It also states that a failed attempt invalidates the second-factor request, requiring a restart of the login process. This gives clear when-to-use and when-not-to-use context, though it doesn't name alternative tools explicitly, the flow context is sufficient.

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?

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It does not state whether the operation is read-only, whether authentication is required, what happens if the ID is not found, or what the response contains. The phrase 'по идентификатору' merely repeats the parameter name and adds no behavioral detail. This is severely lacking.

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 purpose. There is no wasted wording or irrelevant detail. While it is minimal, it is appropriately concise for a simple get-by-ID tool, though it could have included a bit more substance without sacrificing brevity.

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

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

With no output schema, no annotations, and a single parameter, the description should clarify what the tool returns and any additional behavior. It does not mention the return format, whether it returns a single chargeback object, or any error handling. The agent is left to assume it returns chargeback details, which is somewhat inferred from the title and sibling list, but the description itself is incomplete for a tool in a large API surface.

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 'id', which already has a clear description ('Идентификатор чарджбека'). The tool description adds nothing beyond 'по идентификатору', which is essentially a restatement of the schema. Since the schema fully covers the parameter, the baseline of 3 is appropriate; there is no additional semantic value.

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 indicates the tool retrieves a chargeback's details by its ID. It uses a specific resource (chargeback) and a clear lookup verb (implied by 'карточка' and 'по идентификатору'). However, it does not explicitly name the sibling list tool (wata_chargebacks_list) or otherwise differentiate itself beyond the by-ID scope, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., needing a valid chargeback ID), and no exclusions. The description only states what the tool does, leaving the agent to infer usage context from the sibling list. This is a clear gap for a get-by-ID 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only notes cursor pagination, which is already implied by the cursorId/cursorDate parameters. It does not disclose the response shape, ordering, date-filter inclusivity, or any side effects, and the single behavioral detail adds little beyond the 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 a single short sentence with no filler or redundancy. It front-loads the core operation and the notable pagination trait, 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?

There is no output schema, so the description should explain the return structure, but it only says 'list with cursor pagination.' It does not clarify what fields each chargeback contains, how to/from date filters interact with pagination, or what happens when no filters are provided. For a five-parameter listing tool this is incomplete.

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 baseline is 3. The description adds no parameter-specific meaning beyond the generic 'cursor pagination' phrase, which does not exceed what the schema already documents for cursorId and cursorDate.

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 a list of chargebacks and explicitly mentions cursor pagination, distinguishing it from the singular wata_chargeback_get sibling. Even though it is phrased as a noun phrase ('Список чарджбеков'), it unambiguously conveys the operation and resource.

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 guidance is provided on when to use this tool versus alternatives such as wata_chargeback_get for a single chargeback or wata_transactions_list for transaction lists. There are no use-case hints, prerequisites, or exclusions, leaving the agent to infer when this list endpoint is appropriate.

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?

There are no annotations, so the description carries the full behavioral disclosure burden. The phrase 'terminal revenue conversions' gives subject matter but does not explicitly state that the tool returns a list, that it is read-only, whether any filtering is implicit, or what happens for empty ranges; only the word 'history' in the title hints at non-mutating behavior.

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

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

The description is a single, short, front-loaded phrase; it wastes no words and gives the principal subject quickly. It is economical though lacking certain key details, so the structure itself is good.

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?

Without an output schema or annotations, a 4-parameter history/list tool needs a contract explanation. The description only hints at result fields, and never clarifies response shape, default date semantics, or how pagination/system interacting with period filters, making it insufficient for confident 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 input schema already covers all parameters with concise descriptions at 100% coverage, so the baseline is 3. The description adds no meaning to the date-range or pagination parameters; it only previews result fields, which is not enough to elevate the parameter semantics score.

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 as terminal-revenue conversions and even names key output fields (exchange rate and final amount). The title 'История конвертаций' supplies the missing verb, making clear this is a history/list operation and distinguishing it from transaction or payout history 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?

No guidance is given for when this tool should be used instead of sibling finance/history tools such as wata_terminals_finance, wata_payouts_history, or wata_transactions_list. The description does not even state a typical use case or implied date-range workflow.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It correctly frames the operation as a read-only list and adds a meaningful behavioral trait: the set of available items varies by payment method. It does not mention response shape, pagination, or auth, but for a simple catalog listing this is a reasonable level of transparency.

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

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

Two short, information-dense sentences with the core purpose front-loaded. Every clause earns its place, and there is no repetition of the tool name or the schema's already-obvious details.

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

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

For a low-complexity catalog query with two fully enumerated parameters and no output schema, the description adequately covers what the tool returns and its key dependency on payment method. It could mention whether items include prices/identifiers, but it is complete enough 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 already fully documents both enum parameters, but the description adds real semantic value by mapping each 'kind' to concrete content (topup = games/in-game items, vouchers = services/denominations) and by explaining that the result depends on the 'payment' value. This goes beyond the bare enum 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 clearly states the resource: 'Список доступных позиций' (list of available items) and defines what each kind contains — games/in-game items for topup and services/voucher denominations for vouchers. It is functionally distinct from the sibling order/price tools, but it does not explicitly name or differentiate against a sibling alternative.

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 a discovery/pre-order use case and notes that the returned set depends on the payment method. It does not explicitly state when to prefer this tool over related price or order tools, nor does it provide exclusions or prerequisites.

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

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

With no annotations provided, the description carries the full burden. It implies a read-only operation ('current balance') and clarifies a key behavioral nuance (separate from office wallet). However, it does not explicitly state that this is a safe, non-mutating call or mention any auth requirements, though these are reasonable inferences for a balance query.

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 core purpose and then adding the crucial distinction from the wallet. Every sentence earns its place; there is zero 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 parameterless balance query with no output schema, the description provides sufficient context: what the balance is, how it's used, and how it differs from the wallet. It does not mention the currency of the balance, which could be a minor gap, but it is not essential for calling this 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 tool takes 0 parameters, so schema coverage is effectively 100%. Per the rubric, 0 params sets a baseline of 4. The description adds no additional parameter meaning, which is unnecessary given the absence of parameters.

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

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

The description clearly states it returns the merchant's current deposit balance and specifies that this balance funds orders with payment=deposit. It also explicitly distinguishes it from the office wallet, which helps differentiate from sibling tools like wata_wallet_balances. However, it lacks a direct action verb like 'get' or 'retrieve', though this is implied.

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

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

The description implies when to use it (when checking deposit balance for payment=deposit orders) and contrasts it with the office wallet, suggesting it's not for general wallet balances. But it does not explicitly name alternatives or state when not to use it, leaving some inference required.

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?

No annotations are provided, so the description bears the full burden. It discloses that the tool creates an order and imposes a source constraint (item must come from catalog with same payment), but it does not describe side effects, idempotency, payment flow, error cases, or the response shape. For a mutating create operation, this leaves significant behavioral ambiguity.

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

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

Two sentences with no filler. The purpose is front-loaded, and the catalog pointer is the only additional guidance, so every sentence earns its place.

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

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

Despite a nested payload with additionalProperties:true and no output schema, the description provides only the core purpose and a catalog prerequisite. It omits the expected payload field formats, whether order creation is synchronous or requires confirmation, and what the response contains. This is insufficient for confident first-time invocation of a create-order endpoint.

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 all three parameters documented, so the baseline is 3. The description adds one meaningful cross-tool semantic: the payment value must match the catalog position fetched from wata_dg_catalog. It does not, however, clarify the exact structure of the nested payload beyond what the schema's generic 'позиция, количество, ваш orderId' already states.

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 and resource: 'Создаёт заказ на покупку игровой позиции (topup) или ваучеров' – creates a purchase order for topup or vouchers. It clearly identifies the operation and scope, and the second sentence points to the catalog source. However, it does not explicitly contrast with sibling order-creation tools like wata_dg_steam_order_create or wata_dg_stars_order_create, so differentiation is only implicit.

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

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

The second sentence, 'Позицию берите из wata_dg_catalog с тем же значением payment', gives a concrete prerequisite: fetch the item from the catalog with a matching payment value. This is clear procedural context for calling the tool correctly. There is no explicit when-not-to-use or alternative routing, but the catalog instruction covers the main setup step.

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

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

With no annotations, the description carries the burden, and it does add useful behavior: voucher codes are returned for acquiring-paid voucher orders, and the read-only nature is suggested by 'проверяет'. It does not disclose response shape, error cases, or required permissions, leaving meaningful gaps.

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

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

Two short sentences, front-loaded with the primary status-checking purpose; the second sentence adds the notable voucher-code behavior. 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 simple status-check tool with full schema coverage, the essentials are present, but the absence of an output schema and thin behavioral disclosure mean the description does not fully compensate for missing return-value documentation. It is adequate for a straightforward call but leaves the caller to guess at status values and edge cases.

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

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

Schema description coverage is 100% and both enums carry descriptions, so the schema already documents id, payment, and kind well. The description adds the relationship that kind is relevant to acquiring-paid voucher orders, which slightly enriches the enum 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 names a concrete operation (проверяет статус заказа) and the title scopes it to topup/voucher orders, which is enough to identify the resource. It does not explicitly contrast with sibling order-status tools such as wata_dg_steam_order_get or wata_digital_goods_order_get, so differentiation is partial.

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

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

The description gives no explicit when-to-use instructions and names no alternatives or exclusions. It implies usage for checking order status and for obtaining voucher codes, but the agent must infer this from the title rather than from direct 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?

With no annotations provided, the description carries the burden of disclosing behavior. It adds the prerequisite that the order must be in Review status, which is useful. However, it does not mention side effects (e.g., whether the confirmation is irreversible), auth requirements, or what happens on failure. It provides some transparency but not comprehensive.

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

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

The description is a single sentence that is front-loaded with the verb and the critical condition (Review status). There is zero waste, and every word earns its place.

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

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

The tool is simple with one parameter and no output schema. The description covers the action and a key prerequisite, but it does not disclose any other operational details such as response format, error conditions, or whether the action is reversible. Given the lack of annotations, 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?

The schema already fully documents the single 'id' parameter with 100% coverage. The description adds no additional meaning beyond what the schema provides, so it meets the baseline without going further.

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 ('Confirms an order') and the condition (in Review status), which clearly distinguishes it from sibling tools like reject (opposite action) and get (read-only). However, it doesn't explicitly name or contrast with alternatives, so it stops short of a 5.

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

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

The description implies usage when an order is in Review status, but it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions (e.g., what to do if the order is not in Review). It lacks the 'use this instead of X' direction that would earn a 3 or higher.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses an important trait: the order may enter Review status and then requires explicit confirmation or rejection. However, it does not mention what the tool returns on success, any side effects, or error conditions. The Review behavior is useful but the description remains thin on other behavioral aspects.

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: two short sentences that front-load the core action ('Creates an order') and then add the key behavioral note about Review status. Every word serves a purpose, with no filler or redundant phrasing.

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 essential workflow (creation and possible Review status) and points to follow-up tools, which is helpful. However, it lacks information about the response format, which is not provided by an output schema, and the payload structure is left vague (open additionalProperties). For a creation tool with a nested object, more details on expected return values or payload structure would improve completeness.

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

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

The schema description for the payload states 'Recipient, number of stars, your orderId,' which provides basic meaning for the parameter. The tool description adds nothing beyond this. Since schema coverage is 100%, the baseline is 3, and the description does not enhance parameter understanding further.

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 with a specific verb and resource: 'Creates an order for buying stars.' It distinguishes this creation action from siblings like confirm, reject, and get by the act of creation itself. The mention of the Review status adds context without blurring the primary 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 implicitly indicates when to use this tool (to create a new order) and explicitly names the follow-up actions: if the order enters Review status, use wata_dg_stars_order_confirm or wata_dg_stars_order_reject. While it doesn't contrast with non-creation tools explicitly, the guidance about the Review status is a clear usage instruction.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'checks status' implying a read operation, but does not disclose potential errors, required permissions, or what happens if the order does not exist. It also does not indicate whether the operation is safe or idempotent. The description adds no behavioral context beyond the basic action.

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 concise sentence that immediately states the purpose. There is no filler or redundant information. It is front-loaded with the core action and object, making it easy to parse.

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 get tool with no output schema and no annotations, the description is minimal. It does not explain what the response looks like, what statuses are possible, or how this relates to other steps (e.g., order creation). An agent would not know if the result is a string, an object, or how to interpret it. This is a significant gap given the lack of 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?

The schema covers the single parameter 'id' with a description ('Идентификатор заказа'), and coverage is 100%. The tool description does not add any extra meaning about the parameter. According to the rubric, with high schema coverage the baseline is 3, and no additional explanation is required. The description is adequate but not enriching.

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

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

The description states a clear action and object: 'Проверяет статус заказа на покупку звёзд' (checks the status of an order for purchasing stars). It explicitly distinguishes this tool from siblings like create, confirm, and reject, and also from the Steam counterpart by naming 'Telegram Stars' in the title. The verb 'проверяет' is specific and unambiguous.

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

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

No guidance is given on when to use this tool versus alternatives such as wata_dg_stars_order_create or wata_dg_steam_order_get. The description only states what it does, not the context (e.g., after creating an order) or any exclusions. The agent must infer usage from the tool name and sibling list, which is not explicit 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?

Annotations are absent, so the description carries the full burden of behavioral disclosure. It does disclose a meaningful precondition (the order must be in 'Review' status), which is useful. But as a state-changing action, it omits key consequences: what status results from rejection, whether the action is reversible/final, and any effects on the order flow or payload. With zero annotation coverage, this is a significant gap for a mutation tool.

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

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

The description is a single, front-loaded sentence beginning with the action verb, with zero filler. It is efficient and well-structured for what it says. Its brevity is not a defect in structure but reflects the thinness of substance, which is penalized under other dimensions rather than here.

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?

Structurally the tool is minimal — one required parameter with full schema coverage, no output schema, no enums — so the bar for completeness is lower. The description adequately states the action and the single applicability condition. However, for an irreversible-feeling reject action it omits the outcome and whether the rejection is final, leaving the agent to guess post-call 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 100% — the single required `id` parameter is already documented as 'Идентификатор заказа'. Per the high-coverage baseline, a 3 is appropriate. The description adds nothing about the parameter beyond what the schema states, nor any format or provenance expectations for the id.

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

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

The description names a specific verb (Отменяет — cancels), a resource (заказ — order), and a scope constraint (only orders in 'Review' status). This distinguishes it from siblings like wata_dg_stars_order_confirm and wata_transaction_refund. However, there is a minor terminology mismatch: the title says 'Отклонить' (reject) while the description says 'Отменяет' (cancel), which could blur the tool's exact semantics. Purpose is clear but slightly muddied by the inconsistent action wording.

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 explicit usage guidance is provided — there is no statement of when to use this over the confirm sibling, no prerequisites, and no exclusions. The only implicit guidance is the 'Review' status constraint, which hints at applicability but says nothing about what to do for orders in other statuses or when wata_transaction_refund would be the better choice. The agent is left to infer selection logic entirely.

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?

No annotations are provided, so the description itself must indicate behavior. 'Возвращает стоимость' clearly communicates a query-like, read-oriented operation that returns cost and minimum quantity. However, it does not mention authentication requirements, side-effect guarantees, rate limits, or how the service responds on invalid parameters.

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 concise sentence with no filler or repetition. It front-loads the main return value and stays appropriately short for a straightforward price-query 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?

The tool is simpleable and the description gives the core return information, but there is no output schema and no mention of currency, parameter optionality, or usage context. Given the lack of annotations.Empty outcome, the description is minimally viable but leaves some room for correct invocation to be inferred.

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 descriptions already cover both parameters (quantity and username) with 100% coverage, so the baseline is 3. The tool description adds no extra meaning about how these parameters affect pricing or whether they are optional, despite both being non-required according to 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 that the tool returns the purchase cost of Telegram Stars and the minimum allowable quantity. It includes a specific verb and resource, and the result type is obvious. It does not explicitly distinguish itself from sibling order/price tools, but the 'stars price' wording makes the purpose sufficiently identifiable.

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 call this tool, e.g., before creating a star order, or how to choose it over related siblings like wata_dg_stars_order_create or wata_dg_steam_price. The agent must infer usage solely from the name and 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?

With no annotations present, the description carries the full burden. It discloses key runtime behavior: for payment=acquiring a payment link is returned, and for payment=deposit the amount is debited from the merchant's deposit balance. This is significant side-effect and response context beyond the schema.

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

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

Two tight sentences with zero filler. The first front-loads the core action and resource; the second efficiently explains the two payment-mode outcomes. Every part earns its place.

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

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

The description plus schema cover invocation needs: required parameters, enums, and the meaning of payment modes. The lack of output schema is partially mitigated by mentioning the acquiring link, but the deposit-branch response shape is not disclosed; still, this is a minor gap given a sibling get tool for later retrieval.

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

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

Schema description coverage is 100%, and the description merely echoes the payment enum semantics already present in the schema. It adds no new parameter-level meaning for by or payload, so the baseline 3 for schema-covered parameters 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 the specific verb «Создаёт» and names the precise resource: «заказ на пополнение Steam-аккаунта». This distinguishes it from sibling tools like wata_dg_stars_order_create and generic wata_dg_order_create without needing to inspect 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 use case is clear from the resource name, and the payment-mode sentence explains when each mode applies. However, the description does not explicitly state when to prefer this tool over alternative order-creation siblings or when not to use it, so guidance is implied rather than direct.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. It reveals that deposit orders have a distinct status location ('at the common address, not at the direction address'), which is a useful behavioral trait. However, it does not explicitly state that the operation is read-only, nor does it describe the return format or error conditions. It adds some behavioral context but is not comprehensive.

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 front-loads the purpose and then adds the critical usage nuance. Every sentence earns its place; it is efficient and well-structured.

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 2-parameter status check, the description covers the core purpose, parameter consistency, and a subtle behavioral difference. However, it omits any information about the response format or possible error states, which an agent might need to parse the result. Given the low complexity and no output schema, this is a minor gap but still leaves the agent without a full picture of what to expect.

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 descriptions for both parameters, so baseline is 3. The description adds value by instructing that 'payment' must match the one used at creation and explains the deposit-specific behavior. This goes beyond the schema's enum definitions and provides operational context that helps the agent use the parameter correctly.

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 checks the status of a Steam top-up order, which is a specific verb-resource pairing. It distinguishes from related tools like wata_dg_steam_order_create and wata_dg_stars_order_get by focusing on Steam top-up orders, though it does not explicitly name siblings. The purpose is 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 explicit guidance on the 'payment' parameter: 'Specify the same payment as when creating' and explains the deposit nuance about status location. This tells the agent how to use the tool correctly, though it does not discuss when to prefer this tool over other get-order tools. The parameter-specific guidance is valuable and contextually relevant.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states that it calculates cost and mentions two modes, but fails to declare whether the operation is read-only, what it returns, or any side effects. Since it's purely a calculation, an explicit statement of no side effects and a note on the output would be expected.

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 concise sentences with no fluff. It front-loads the core purpose (calculating cost) and immediately explains the key differentiator (two modes). Every word earns its place, making it optimally concise and well-structured.

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 does not explain what the tool returns, despite there being no output schema. It also omits any details about currency defaults, authentication requirements, or potential edge cases. Given that the tool is a simple calculation, the missing output specification is a notable gap, making the description insufficient on its own for a precise invocation.

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

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

Schema description coverage is 100%, so all parameters already have detailed descriptions. The description adds the overall two-scenario context and clarifies the role of the 'by' parameter, but this information is also present in the schema's enum descriptions. Thus, the description adds marginal value beyond what the schema already provides, landing at the baseline for high 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 calculates the cost of Steam account top-up and explicitly distinguishes two modes of calculation. This specific verb-object pair (calculates cost) and resource (Steam account) leaves no ambiguity about its purpose, and it is distinct from sibling tools like order creation.

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 the two calculation modes and directs users to select the mode via the 'by' parameter. However, it does not explicitly state when to use this tool versus alternatives, such as wata_dg_steam_order_create, nor does it mention exclusions or prerequisites. Usage guidance is only implied through the calculation 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It weakly implies a read operation by saying 'card of the order to return', but it does not explicitly state read-only semantics, potential errors, required permissions, or any operational effects, leaving the agent to infer that this is a safe lookup.

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 brief and front-loaded with the core purpose in a natural sentence. It avoids redundancy but is somewhat terse; the ambiguous noun 'Карточка' could have been replaced with a more explicit verb such as 'Возвращает' or 'Получает'.

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 100% parameter coverage, no output schema, and a simple lookup role, the description is minimally adequate. However, it does not clarify the response format, whether it returns one order or a summary, or how this relates to closely named siblings, so it is 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?

The input schema already covers both parameters with 100% coverage. The description's phrase 'by terminal and order identifier' merely restates the schema, but it does reinforce the mapping between publicId as the terminal and orderId as the order. This lands at the baseline for high schema coverage.

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

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

The description states that this tool returns the card/details of a digital goods order identified by terminal and order ID, which is clear enough for a retrieval operation. However, it does not explicitly differentiate itself from sibling tools like wata_dg_order_get or wata_dg_stars_order_get, beyond the name itself.

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 guidance is provided regarding when to use this tool versus alternatives. The description only restates the lookup inputs (terminal and order ID) and does not indicate conditions, prerequisites, or exclusions that would help an agent choose between the many similar digital goods order 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?

No annotations are provided, so the description must disclose behavior on its own. It does not state whether the operation is read-only, whether it returns a list or a single item, or any pagination or sorting behavior. The date-range parameters are not described in the description either. This is insufficient for a tool that likely performs a read operation with optional filtering.

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, concise sentence that names the core domain and categories. It is efficient and contains no filler, though it could be more explicit about the action (e.g., 'list orders'). It is front-loaded with the domain, which is acceptable, but it lacks a verb that clearly indicates retrieval.

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 4 parameters, all optional, and no output schema, so the description must explain the purpose and return value. It only states the domain without clarifying that it returns a list of orders, how pagination works, or what filters are available. For a listing tool with no annotations, this is under-specified and would leave an agent uncertain about the expected result.

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

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

The schema description coverage is 100%—all four parameters (to, from, skipCount, maxResultCount) have clear descriptions. The tool description adds no additional meaning about the parameters, such as how date filters interact or the default result count. Per the rubric, a baseline of 3 is appropriate when the schema fully documents the parameters.

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

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

The description names the resource ('orders') and the domain ('digital goods') with specific categories (Steam, Telegram Stars, top-ups, vouchers). It distinguishes from the more specific sibling tools (like wata_dg_steam_order_create) by being a general listing, though it doesn't explicitly say 'list' or 'fetch'. The title and parameters imply a listing operation, so the purpose is mostly 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?

No guidance is given on when to use this tool versus the many order-related siblings (e.g., wata_digital_goods_order_get, wata_dg_order_get). There is no mention of alternatives or exclusions, leaving an agent to infer that this is for batch listing rather than single-order retrieval. This is a significant gap for a tool with many close relatives.

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

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

With no annotations, the description must carry the behavioral information, and it does indicate a read-only counting operation rather than a mutation. However, it does not disclose response shape, whether zero-count statuses are included, or how date bounds are handled in the aggregation, leaving some ambiguity in behavior.

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

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

The description is a single, tightly worded sentence that front-loads the core value (count by status). There is no filler or redundancy, and it is appropriately sized for its simple two-parameter interface.

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 simple optional date parameters, the definition omits any output specification (no output schema and no description of the returned status-to-count mapping) and provides no routing context among the many sibling count/list tools. An agent lacks enough context to confidently decide to call this vs. wata_digital_goods_orders or wata_transactions_counts.

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

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

The input schema already fully describes both parameters ('Конец периода' and 'Начало периода' with YYYY-MM-DD format), so the description carries no parameter-level burden. It also adds no parameter-specific context beyond the schema, which aligns with the baseline score for high schema coverage.

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

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

The description specifies that the tool returns the count of digital goods orders broken down by status, which is a concrete, unambiguous resource and grouping. It adds the 'по статусам' dimension that the title only implies, distinguishing it from the plain order-list sibling wata_digital_goods_orders, though it lacks an explicit action verb like 'returns'.

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 over alternatives such as wata_digital_goods_orders, wata_subscriptions_counts, or wata_transactions_counts. No exclusions, prerequisites, or 'prefer this for aggregate stats' hints are provided, so the agent must infer use from the name and one-line description.

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

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

No annotations are provided, so the description itself must carry the behavioral burden. It does not disclose side effects (e.g., whether this is read-only), permissions, response shape, or how from/to are used inclusively. The name implies a query but the description adds little beyond 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 a single, front-loaded sentence that communicates the purpose and a usage context without padding. It earns its place by hinting at graph/reconciliation use, though the phrase 'основа для графиков и сверки' is slightly promotional rather than purely functional.

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

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

For a simple two-parameter filter with 100% schema coverage, the description is minimally adequate but not complete. There is no output schema, so an agent might not know whether the response is a list of date-amount pairs, a map, or a series, and the description does not clarify response structure or error 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?

The input schema already documents both 'from' and 'to' with date format details at 100% coverage, so the baseline is 3. The description does not add any additional parameter semantics, such as inclusivity bounds or timezone handling, but it does not need to compensate because the schema is complete.

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

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

The description states the tool returns a daily breakdown of turnover and revenue, which is a clear resource and granularity. The phrase 'по дням' distinguishes it from summary or transaction-list siblings, though it lacks an explicit verb like 'get' or 'return'.

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 usage context ('основа для графиков и сверки'), indicating when the data would be needed. However, it does not explicitly mention when to prefer this over alternatives like wata_finance_summary or wata_transactions_list, nor does it state any exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what data is returned (turnover and revenue per currency) but does not explain what 'оборот' and 'выручка' include (e.g., refunds, fees), timezone handling, rounding, or the response structure. No mention of pagination or limits since it's a summary, but still lacking operational details.

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

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

The description is a single, front-loaded sentence with no filler. It states the core function immediately and nothing more, which is appropriately concise for a simple aggregate tool.

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

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

For a tool with only two date parameters and no output schema, the description is minimally complete: it tells the agent the tool returns a summary by currency. However, given the large set of finance-related siblings (e.g., wata_finance_daily, wata_terminals_finance, wata_transactions_list), it lacks clarity on scope (merchant-level vs terminal-level) and how this differs from those alternatives, which is a notable 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 describes both parameters with clear format hints ('Конец периода, YYYY-MM-DD' and 'Начало периода, YYYY-MM-DD'), achieving 100% coverage. The description does not add param details, but the baseline is 3 because the schema already provides sufficient semantics for an agent to pass correct values.

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 'Суммарный оборот и выручка мерчанта за период, по валютам' (total turnover and revenue for the merchant over a period, by currency). This is a specific verb (return/summarize) + resource (merchant finance) + scope (period, currency), and it distinguishes itself from siblings like wata_transactions_list (detailed list) and wata_finance_daily (daily breakdown) by being an aggregate summary.

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

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

The description gives no guidance on when to use this tool versus alternatives such as wata_finance_daily, wata_transactions_list, or wata_terminals_finance. It does not state prerequisites, exclusions, or context for selection, leaving the agent to infer from the name and 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?

No annotations are provided, so the description carries the full burden. It discloses the core behavioral effect (prevents further payments) and the requirement to pass certain fields. However, it does not mention error handling, idempotency, or any side effects beyond closure, which are relevant for a mutation with no annotation coverage.

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 sentences with no filler. The purpose is front-loaded, followed by the parameter sourcing requirement and the alternative tool. Every sentence contributes meaning without 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 simple close operation with no output schema and no annotations, the description provides the essential information: purpose, required data sources, and the alternative for creation. It lacks details about response format or error behavior, but these are not critical given the simple nature of the operation.

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

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

Schema coverage is 100% and each parameter description already says 'from wata_link_get'. The tool description repeats this guidance but adds no new information about parameter meaning or format. The baseline of 3 is appropriate because the schema already documents the parameters adequately.

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 ('closes a payment link') with a clear consequence ('so it can no longer be paid'). It distinguishes from sibling tools by noting that creation is done via wata_acq_link_create, making 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 explicitly tells the agent to retrieve parameters from wata_link_get and clarifies that creation uses wata_acq_link_create, effectively routing the agent to the right tool for different operations. It doesn't explicitly state 'use this when you want to close a link', but that is implied by the purpose and the contrast with creation.

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?

No annotations are provided, so the description carries the transparency burden. It does disclose an important behavioral/authorization trait — creation is done on behalf of the cabinet without a terminal JWT token. However, it does not mention idempotency, response shape, side effects beyond creation, or error behavior, which remain gaps.

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 core action first, then the key context, then the alternative tool. Every sentence adds necessary value and there is no filler or redundant repetition of the name or 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 adequately covers purpose and use-case selection, but with no output schema and no annotations, it leaves out important operational context such as what the tool returns, error/condition cases, and redemption behavior. It is sufficient but not fully complete for an agent that needs to interpret the result.

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

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

Schema coverage is 75%, so the input schema already documents most parameters. The description adds contextual meaning for terminalId by explaining that the terminal must be explicit when no JWT token is available, but it adds little or nothing for amount, currency, expiration, redirects, and other optional 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 states a specific verb and resource ('Создаёт платёжную ссылку от имени кабинета') and clearly distinguishes this tool from the sibling wata_acq_link_create. It also explains the important nuance that no terminal JWT token is required, making 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 explicitly says when this tool is appropriate ('когда токен ещё не выпущен') and gives a direct when-not instruction: if integrating payment acceptance into your service, use wata_acq_link_create instead. This leaves little room for incorrect tool 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only says that the tool returns a 'карточка' (card/details) by identifier, which adds little beyond the title. It does not mention response shape, behavior for missing or invalid IDs, or any other side effects or requirements.

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 very concise—one short sentence with no filler. It is front-loaded with the resource and lookup method. It loses a point only because it is so terse that it does not convey more than the title already does.

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

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

For a simple one-parameter getter, the description is minimally sufficient: an agent knows to pass a link identifier and expect details. However, there is no output schema, no mention of possible errors, return structure, or how this getter relates to the many link-related sibling tools, leaving notable gaps.

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 documents the single id parameter with 100% coverage and a clear description ('Идентификатор ссылки'). The tool description merely restates the identifier concept and does not add new semantic detail, 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 names the resource (payment link) and the lookup criterion (identifier), and implies a read action returning details. However, it does not explicitly differentiate itself from similar sibling tools like wata_acq_link_get or wata_links_list, so it falls short of a 5.

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

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

No guidance is given for when to use this tool versus alternatives such as wata_links_list, wata_acq_link_get, or wata_link_create. The context in which this getter is preferred is left entirely to inference.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It does not indicate whether the operation is read-only, how pagination works, or any side effects. The description only states a condition (created links) but not the 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?

While the one-sentence description is brief, it is not appropriately concise because it omits essential information. It under-specifies the tool's purpose, making it less effective than a longer description with clear action and scope.

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 4 parameters, no output schema, and no annotations, the description is grossly inadequate. It provides no context about what the tool returns, how to use parameters, or when to invoke it, leaving an agent unable to correctly select and call 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 coverage is 100%, with each parameter having a description in the schema. The description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not enhance understanding.

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 'Созданные платёжные ссылки мерчанта' (Created payment links of the merchant) is a noun phrase without a verb, leaving the action ambiguous. It does not state whether this tool lists, retrieves, or counts links. It fails to distinguish from sibling tools like wata_link_get or wata_acq_links_find, which also deal with links.

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 guidance is provided on when to use this tool versus alternatives such as wata_link_get (for individual links) or wata_acq_links_find (for acquiring links). There is no mention of pagination, filtering context, 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?

No annotations are provided, so the description carries the burden. It discloses the data scope (organization-level merchant data) and the fields returned, which is useful. However, it does not state whether this is a read-only operation, whether it requires authentication, or what happens if no merchant is found. The description is honest but thin on behavioral detail.

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, compact sentence that front-loads the resource type and lists the key data fields. It is efficient and free of filler, though it could be slightly more explicit about the action (e.g., 'returns' vs '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?

For a zero-parameter, no-output-schema tool, the description is mostly adequate: it names the resource and the fields returned. However, it lacks any statement about authentication requirements, error behavior, or whether the data is current/live, which an agent might need to know when deciding 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?

The tool has 0 parameters, so there is no parameter semantics burden. The description adds value by enumerating the returned fields, which helps an agent understand what the tool provides. Baseline 4 for 0 params is appropriate.

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

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

The description states a clear verb-resource relationship: it retrieves merchant organization data, listing specific fields (name, status, assigned managers, creation/modification dates). It is distinguishable from siblings by the merchant-specific scope, though it doesn't explicitly name a sibling alternative.

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 a read-only lookup use case for merchant data, but provides no explicit when-to-use guidance or exclusions. With 0 parameters, the tool is self-contained, so usage context is less critical, but there is no mention of when to prefer this over other get-style 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool mutates the password, but does not mention whether the code is single-use, whether the old password is invalidated, whether the session is terminated, or any error conditions (e.g., expired code). For a security-sensitive operation, this is a significant gap.

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, concise sentence that front-loads the action. It is appropriately sized for a simple tool, though it could add a brief usage note without becoming bloated.

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 security-sensitive mutation with no annotations and no output schema, the description is too thin. It does not explain the expected payload structure beyond a vague hint, nor does it mention code expiry, error handling, or what happens after success. An agent would need to inspect the schema or guess at the nested 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 100% for the single payload parameter, which is described as 'Почта, код и новый пароль' (Email, code, and new password). The description adds the purpose of the code but does not detail the nested object's fields or formats. Baseline 3 is appropriate since the schema already covers the parameter at a high level.

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: 'Устанавливает новый пароль, используя код из письма' (Sets a new password using the code from the email). This clearly distinguishes it from the sibling wata_password_reset_request, which presumably initiates the reset. It could be slightly more explicit about the two-step nature of the flow, but the 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 implies usage context: it is the second step after receiving a code by email. It does not explicitly state when to use it versus wata_password_reset_request, nor does it mention prerequisites like having requested a reset first. The context is inferable from the name and description, but not explicitly 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?

No annotations are provided, so the description carries the burden. It discloses that it sends an email with a code, which is useful, but doesn't mention side effects like invalidating previous codes, email throttling, or errors for non-existent emails. That would be valuable 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?

One sentence, no fluff, front-loaded with the main action. Efficient.

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 there is no output schema and no annotations, the description is thin for a tool that initiates a password reset flow. It would benefit from noting that the code is sent for the reset_confirm step.svg.

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 a clear description of the email parameter (account email). The description adds 'password recovery' context, but the parameter is already well-documented in the schema, so minimal extra value.

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 action (sends a code to email) and resource (password recovery), but it doesn't explicitly name the tool's purpose relative to siblings like 'wata_password_reset_confirm'. It is clear what it does but doesn't distinguish it from the reset 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?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for starting password reset, but doesn't mention that it should be used before wata_password_reset_confirm, nor any conditions like account existence or rate limits.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only lists returned fields and does not mention pagination behavior, ordering, whether it includes pending or completed payouts, or any side effects. It is a read-only history tool, but that is not stated. The description adds little beyond the obvious.

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, efficient sentence that front-loads the core purpose and key fields. There is no fluff or redundancy. It earns its place by communicating the essential information without unnecessary detail.

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

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

Given the tool's complexity (simple listing with 4 documented parameters) and lack of an output schema, the description is notably sparse. It does not explain how payouts differ from transactions, what statuses exist, or how to filter effectively. It also does not mention default pagination or date range handling, relying entirely on the schema. For a tool with many sibling history tools, this is insufficient.

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

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

The schema already provides descriptions for all four parameters (to, from, skipCount, maxResultCount), so baseline is 3. The description does not add any additional meaning to the parameters; it simply repeats the field names in a different form. No extra semantics are provided.

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 (payouts to merchant) and lists the key attributes (amount, status, date, involved terminals). It distinguishes this tool from generic transactions or finance summaries, though it could be more explicit about the 'history' aspect. The verb is implied (view/list) but clear enough.

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 like wata_transactions_list or wata_finance_summary. The description does not mention any exclusions or prerequisites. An agent would have to infer its usage from the name and 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists the fields returned but does not state whether this is a read-only operation, whether it requires authentication, or what happens if the user is not authenticated. The description is a field list rather than a behavioral contract.

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 concise sentence that front-loads the key fields. It is efficient and free of filler. It loses one point because it is a bare list rather than a structured sentence, but it is appropriately sized for a zero-parameter getter.

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 profile getter, the description is mostly complete: it names the resource and the returned fields. However, with no annotations and no output schema, it does not clarify authentication requirements, error behavior, or whether the profile is for the authenticated user vs. a specified user. The 'current user' phrasing helps but leaves some context implicit.

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, so there is no parameter semantics burden. The description appropriately explains what the tool returns, which is the only semantic content an agent needs. Baseline 4 for zero-parameter tools 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 resource (current user profile) and the specific fields returned (name, email, phone, telegram, roles, identifier). It uses an implicit 'get' verb tied to the tool name, and the field list distinguishes it from other tools. It doesn't explicitly name a sibling alternative, but the resource is specific enough that an agent can tell it apart from the many unrelated tools.

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

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

The description implies this is a read-only profile retrieval tool, and the context of 'current user' suggests it is used for identity/account information. However, it provides no explicit when-to-use guidance, no exclusions, and no mention of alternatives. For a zero-parameter profile getter, the implied usage is adequate but not explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool handles the session, antiforgery token, and DDoS-Guard protection, and warns that non-GET methods modify account data. This is valuable safety context beyond the schema. It does not describe return format or error behavior, but for a raw request tool these are generally self-evident.

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 core purpose and followed by the critical safety warning. Every sentence adds value, and 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?

For a raw request tool, the description covers the essential behavioral constraints: session handling, DDoS protection, path prefix, and mutation warning. It does not explicitly mention the response format, but that is implied by 'любой запрос' and is typical for raw tools. It is complete enough 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?

Schema coverage is 100%, so the description adds little beyond the schema. The only additional parameter semantics is the constraint that the path must start with /api/, which is a useful rule but not extensive. The warning about mutation is more behavioral than parameter-specific. Given the high schema coverage, a 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?

Description clearly states it performs any request to the personal cabinet API, specifies it uses the current session, antiforgery token, and DDoS-Guard protection, and positions itself as the raw fallback for typed tools. It explicitly distinguishes itself from the many typed siblings by being the untyped, arbitrary-request tool. The requirement that the path start with /api/ further defines its scope.

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 it is for things not covered by typed tools, giving clear context on when to use it. It does not name specific alternative tools, but the general reference to 'типизированными инструментами' is sufficient given the large sibling list. It also warns about mutating methods, which is relevant guidance for safe usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('turns off') without revealing consequences such as whether the change is reversible, whether it affects only the current user or all users, or if there are any side effects. This ambiguity leaves the agent uncertain about the tool's impact.

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

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

The description is a single, front-loaded sentence that uses zero wasted words. It conveys the essential action and scope efficiently without 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 simple tool with no parameters and no output schema, the description is mostly adequate, but it leaves gaps about the scope and reversibility of the action. The agent might need to know whether the disable is persistent and whether it applies to the current user's cabinet globally. The description could be more explicit about these aspects, though the tool remains usable with the current level of detail.

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

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

The tool has zero parameters and an empty schema, so there is nothing for the description to explain. Per the baseline rule for 0 parameters, a score of 4 is appropriate since no additional parameter information is 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 a specific action ('Выключает' - turns off) on a specific resource ('баннеры-истории' - story banners) within a specific context ('в интерфейсе кабинета' - in the cabinet interface). It uniquely identifies the tool's function and is easily distinguishable from all sibling tools, none of which deal with story banners.

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 when to use the tool (when the user wants to disable story banners) but does not explicitly state usage scenarios, prerequisites, or exclusions. There are no alternative tools for this action, so guidance on when not to use it is minimal. The context is clear enough for a simple toggle, but it lacks any explicit direction.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It says nothing about what the tool returns, whether it is read-only, or any side effects. The agent cannot infer 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 extremely short, but this is under-specification rather than effective conciseness. It lacks essential information and does not front-load any useful 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?

Given the tool has a single parameter, no output schema, and no annotations, the description is completely inadequate. It fails to explain the tool's purpose, return value, or any usage context, making it impossible for an agent to understand what it does.

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 fully describes the subscriptionId parameter with 100% coverage, so the baseline is 3. The description adds no extra meaning about the parameter, but it does not need to compensate since the schema is complete.

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

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

The description 'Карточка регулярного списания.' is a vague noun phrase ('Subscription card') that does not clearly state the action (get) or the resource (subscription details). It fails to differentiate from siblings like wata_subscriptions_list, which also deals with subscriptions.

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 guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without any routing information.

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?

No annotations are provided, so the description carries the burden. It discloses that the tool returns counts by status, which is the core behavior, but it does not mention whether the counts are global or scoped to a merchant/terminal, whether failed/completed statuses are always present, or any pagination/response shape. For a read-only aggregate tool this is adequate but not rich.

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

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

One short sentence that names the resource, the aggregation, and the exact statuses included. No filler or repetition of the title.

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 read-only counts tool, the description is mostly complete: an agent knows what it returns. However, without annotations or an output schema, the description does not specify the response format (e.g., keys like active/completed/failed) or any scoping context, which is a minor gap for an aggregate endpoint.

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, so there is nothing for the description to explain about parameters. The description correctly implies the tool takes no input and simply returns status counts. Baseline 4 for zero-parameter tools is appropriate.

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

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

The description states a specific verb and resource: it returns counts of subscriptions grouped by status (active, completed, failed). It is clear enough to distinguish from wata_subscriptions_list, which presumably returns the subscriptions themselves, though it does not explicitly name that sibling.

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 this is for getting aggregate counts rather than the full subscription list, and the sibling wata_subscriptions_list exists as the likely alternative. However, it does not explicitly state when to choose this over wata_subscriptions_list or wata_subscription_get, leaving the routing mostly to inference.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly communicates a mutating operation and enumerates three supported status changes, but it does not reveal side effects such as whether cancellation is irreversible, whether resuming is always possible, or how errors are surfaced.

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

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

The description is a single front-loaded sentence with no filler or redundancy. It earns its place by specifying the exact actions rather than restating the title.

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

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

For a simple two-parameter mutation, the description is minimally viable: it states the operation and implied status values. However, it omits a full list of accepted statuses, potential constraints on state transitions, and return behavior, and there is no output schema to compensate.

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 already documents the two parameters. The description adds no additional parameter semantics beyond what the schema provides; the status example appears in the schema, not in the 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 names a specific verb and resource: it suspends, resumes, or cancels a subscription. This is more specific than the title alone and distinguishes the tool from read-only subscription siblings like wata_subscription_get and wata_subscriptions_list.

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 guidance is given about when to use this tool versus other subscription tools or what conditions apply. The description does not state exclusions, prerequisites, or alternatives, leaving the agent to infer context from the name and 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?

No annotations are present, so the description must carry the burden of behavioral transparency. The description provides no information about what the tool returns, how pagination works, ordering, or any side effects. It merely states a domain phrase and offers no behavioral detail. For a list operation that likely returns many records, this is a significant gap.

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 extremely brief, but brevity here is under-specification rather than conciseness. It provides no structure or front-loaded key information. Every sentence (or phrase) should earn its place; this one communicates only a topic, not a function. A well-structured description would lead with the verb and action, then 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?

Given the tool has no output schema and no annotations, the description should explain what is returned (e.g., list of subscriptions, fields, pagination behavior). It does none of this. It is completely inadequate for an agent to correctly invoke and interpret results. Sibling tools like wata_subscriptions_counts and wata_subscription_get suggest complexity that this description fails to address.

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?

Both parameters (skipCount and maxResultCount) have schema descriptions that fully explain their meaning; schema coverage is 100%. The description adds no additional parameter semantics. Per rubric, the baseline is 3 since the schema already handles parameter documentation; there is no extra value from the description. It does not clarify, for example, whether maxResultCount has a maximum or default, which the schema already states.

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 'Регулярные списания (подписки) мерчанта.' ('Regular charges (subscriptions) of the merchant') identifies the resource (subscriptions) but does not state the action (list). It essentially restates the title 'Подписки' (Subscriptions) without a verb or instruction. The tool name includes '_list' but the description should stand alone. This lacks the specificity needed to distinguish the operation from sibling tools like wata_subscription_get or wata_subscriptions_counts.

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 guidance is provided on when to use this tool versus alternatives. Sibling tools include wata_subscriptions_counts, wata_subscription_get, and wata_subscription_set_status, but the description offers no differentiation. An agent cannot infer whether to use this list operation for pagination, filtering, or other 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?

No annotations are provided, so the description carries the full behavioral burden. It states the exact effect (removes the unread marker), which is useful, but it does not mention idempotency, permissions, or behavior for invalid or nonexistent comments. This is adequate for a simple state change but not rich.

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

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

The description is a single short, direct sentence with no filler. The core action is front-loaded, and every word contributes to the meaning.

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

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

For a two-parameter tool with no output schema, the description plus schema cover the essential invocation details: what action is performed and which identifiers are required. The only minor gap is the absence of return-value or error behavior, which is less critical for such a simple operation.

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

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

Schema description coverage is 100%: both id and commentId are already described with meaningful Russian labels ('Идентификатор тикета' and 'Идентификатор комментария'). The description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description uses a specific verb ('снимает' — removes) and a specific resource ('отметку о непрочитанном ответе поддержки' — unread marker of a support reply), making the mark-as-read action clear. It is distinct from related support-ticket siblings like support_ticket_reply or support_ticket_get, though it does not explicitly name 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?

There is no explicit when-to-use or alternative-routing guidance. The intended use is implied by the action itself — call this when an unread marker should be cleared — and no sibling tool performs the same operation, but the description leaves the context to inference.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool creates a ticket (write operation) and implies routing, but does not mention authentication, side effects, or the response structure. This is a moderate gap for a mutation tool.

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

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

Two sentences, front-loaded with the primary action, including a concrete example and practical advice. No fluff 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 no annotations, no output schema, and the action's nature, the description covers the main parameters but omits expected response details and prerequisites (e.g., authentication). It's adequate for a simple action but not exhaustive.

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

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

Schema coverage is 100% and already describes all three parameters, but the description adds meaningful layers: it explains the purpose of category (routing) and advises on what to include in description (transaction/terminal IDs). This goes beyond the basic 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 explicitly states the tool 'opens a new WATA support ticket', a specific verb and resource. It differentiates from sibling actions like wata_support_ticket_get and wata_support_ticket_reply by focusing on creation, and even gives a concrete category example.

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 that category determines routing, provides a concrete example (MissingTransaction), and advises including transaction and terminal identifiers for faster resolution. This gives context but does not explicitly mention when not to use the tool or contrast with reply/get 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the return scope — the entire ticket including the conversation — which is useful. However, it does not explicitly confirm that the operation is read-only, nor does it describe error behavior or authorization requirements. For a get operation, the risk is low, but the description itself is minimal.

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 with no filler. It conveys the key distinguishing detail, 'включая переписку', without redundancy or unnecessary elaboration.

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 get operation with one required parameter and full schema coverage, the description is largely sufficient: it tells the agent what will be returned. No output schema exists, so the return description adds necessary value. It does not cover error cases or link to sibling tools, but the low complexity of the tool makes this acceptable.

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

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

The input schema has full coverage: the single required parameter 'id' is described as 'Идентификатор тикета', which is sufficient. The description adds no additional meaning to the parameter itself, so the baseline score of 3 is appropriate.

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

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

The description 'Обращение в поддержку целиком, включая переписку' clearly identifies the resource as the full support ticket, including the correspondence thread. This distinguishes it from the list sibling wata_support_tickets, which likely returns a summary of tickets. However, it is a noun phrase rather than an explicit verb statement, so the action is mostly inferred from the tool name and title.

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 no explicit guidance about when to use this tool versus alternatives such as wata_support_tickets, wata_support_ticket_create, or wata_support_ticket_reply. There are no exclusions, prerequisites, or stated conditions. The only usage signal is the 'get' suffix in the tool name.

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?

No annotations are provided, so the description carries the full burden. It discloses an important behavioral trait: the cabinet expects multipart/form-data and the tool assembles the form itself. However, it does not mention any side effects, authentication requirements, or the nature of the response (success/failure), leaving gaps for a write operation.

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

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

The description is a single sentence that front-loads the purpose and includes a key implementation detail (multipart/form-data). Every word earns its place, with no redundancy or unnecessary 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 2-parameter mutation with no output schema, the description covers the essential purpose and the unusual encoding behavior. It does not mention error handling or prerequisites, but given the tool's simplicity and lack of annotations, it is reasonably complete 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?

Schema description coverage is 100%, so both parameters (id and text) are already documented. The description adds minimal extra meaning—it clarifies that 'text' is a comment, but that is already implied by the tool name and schema. It doesn't provide additional syntax or usage details 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 verb ('adds a comment') and resource ('support ticket'), and specifies the actor ('on behalf of the merchant'). It distinguishes this from sibling tools like ticket creation or marking as read by its focus on adding a comment.

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 when to use it (to reply to an existing ticket) but provides no explicit guidance on when not to use it or how it differs from related tools like wata_support_ticket_create. The verb 'reply' makes the intent clear, but there's no explicit routing to 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?

No annotations are provided, so the description carries the full behavioral burden. It only lists data fields and does not disclose that the operation returns a paginated list, whether it is read-only, how the 'unread' flag is determined, or any scope/side-effect behavior.

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

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

The description is a single sentence with no filler, front-loading the resource and its key attributes. It is appropriately sized for the tool's low complexity, even though the brevity contributes to semantic gaps elsewhere.

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 list tool with no output schema and no annotations, the missing explicit verb, pagination behavior, and scope (whose tickets are returned) are significant gaps. The two parameters are well documented, but the description alone is not enough for an agent to call the tool with full confidence.

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%: both skipCount and maxResultCount already have explicit descriptions. The tool description adds no parameter-level semantic detail, so it contributes no value beyond the input schema, matching the baseline for high 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 names a specific resource (support tickets) and enumerates key attributes (topic, category, status, unread replies), but it never states a verb such as 'list', 'get', or 'return'. The plural name and pagination parameters imply a list operation, but the purpose remains implicit and is not explicitly distinguished from the singular wata_support_ticket_get sibling.

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 the related ticket tools (get, create, reply, mark read). No conditions, alternatives, or exclusions are mentioned; an agent must infer usage solely from the tool name and sibling set.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the most important non-obvious behaviors: the token value is shown exactly once (save to WATA_ACQ_TOKEN), the valid lifespan (1–12 months), the per-terminal limit (1–5 tokens), and the IP whitelist condition. That is substantial behavioral detail beyond trivial 'creates a token' wording.

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 written on 3 sentences with no fluff. The most operationally important fact (one-time display, save it) is front-loaded, followed by constraints and IP requirements. Every sentence carries weight.

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 3-parameter creation tool with no output schema, the description covers the main concerns: what it does, the safety constraint, the limit, the lifetime, and the IP restriction. It doesn't explain the response structure, but that's acceptable since no output schema is provided and the token visibility warning is the essential runtime detail.

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

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

The schema description coverage is 100%, so the schema already documents each parameter. The description adds meaning by explaining the purpose of the token, the one-time display behavior, the IP restriction, and the expiration constraints, which enriches the agent's understanding of expirationMonths (1–12) and validates the meaning of name for distinguishing tokens.

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 creates a new JWT for the acquiring public API, and the title 'Выпустить API-токен терминала' matches. The generic tool name is clarified by the concrete statement of what it produces, and the sibling list (wata_terminal_api_tokens_list, wata_terminal_api_token_revoke) clearly contrasts this creation tool from listing/revoking tokens.

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 context for when this tool is applicable: creating a new API token for a terminal, with a constraint of 1–5 tokens per terminal. It doesn't explicitly say 'use list instead' or 'use revoke instead', but it implies the creation purpose and the limits are useful for deciding before calling.

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

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

With no annotations provided, the description carries the full behavioral burdeneds and it does disclose a critical trait: the action is irreversible ('Безвозвратно'). This goes beyond the tool name alone and helps an agent understand the consequence before invoking it. It does not cover permissions or response behavior, but the irreversibility disclosure is substantial for a revocation operation.

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

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

The description is a single sentence with no filler. The key qualifier 'Безвозвратно' is front-loaded, and the object of the action is clearly stated. Every word contributes meaning.

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 operation is simple, has only two required parameters, and the schema fully documents them. The description provides the essential context—irreversible revocation of an API token—which is sufficient for a low-complexity destructive action. It does not detail post-conditions or response format, but given the simplicity and full schema coverage, this is not a significant 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 both parameters (tokenId and terminalId) are already documented in the schema. The description adds no parameter-specific details, but the baseline of 3 is appropriate when the schema fully covers parameter semantics.

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

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

The description states a specific verb ('отзывает' / revokes) and a clear resource ('выпущенный JWT публичного API' / issued public API JWT), making its function unmistakable. It naturally distinguishes the tool from related siblings like wata_terminal_api_token_create and wata_terminal_api_tokens_list.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It defines the action but does not help an agent decide between revoking, creating, or listing tokens.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It usefully notes that token values are usually not returned again by the server, which prevents an agent from expecting secrets in the response, but it does not address auth requirements, pagination, or response structure.

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

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

The description is a single compact sentence that front-loads the core purpose and adds a valuable caveat in parentheses. Every part contributes useful information, and there is no 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?

For a simple one-parameter list operation, the core information is present: what is listed, for which terminal, and an important caveat about token values. However, with no output schema and no annotations, the description could still be more complete about the response contents or any pagination/limitations.

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

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

Schema description coverage is 100%, with terminalId already documented as 'Идентификатор терминала'. The tool description adds no further meaning to the parameter, so the baseline of 3 applies.

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

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

The description states a specific operation — 'Список выпущенных JWT-токенов публичного API для терминала' — clearly identifying a read-only list action on terminal API tokens. This is readily distinguishable from sibling create/revoke token tools by the verb and resource.

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 list semantics imply this tool should be used to retrieve existing API tokens, and the sibling names create/revoke suggest alternatives. However, the description provides no explicit when-to-use guidance, conditions, or exclusions, so usage is only implied rather than stated.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'Полная карточка' and the listed output fields indicate a read-style retrieval, but the description does not disclose error behavior, auth expectations, or confirm absence of side effects.

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 concise sentence with no filler. The core concept 'Полная карточка терминала' is front-loaded, and the following field list adds concrete value without 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 simple one-parameter get operation with no output schema, the description provides enough return context by naming key fields (webhook, success/error pages, allowed domains). It does not mention error cases or explicitly relate to list/update siblings, but the low complexity makes this a minor gap.

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

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

The input schema fully documents the single required parameter 'id' with a helpful clarification ('field id, not publicId'), so schema coverage is 100%. The tool description itself adds no parameter-specific meaning, which matches the baseline score of 3 for high schema coverage.

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

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

The description clearly identifies the resource as a terminal and specifies the scope as 'Полная карточка терминала' (full terminal card) with concrete fields: webhook address, success/error pages, and allowed domains. This is a specific, informative statement, though it does not explicitly name sibling tools to differentiate itself.

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 siblings like wata_terminals_list, wata_terminal_update, or wata_terminal_rates. The description implies a detail-retrieval purpose but provides no explicit conditions, exclusions, or 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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions that only one rate is changed per call, which is a useful constraint, but it does not describe side effects (e.g., does it override existing rates?), reversibility, permission requirements, or error behavior. For a mutation tool, this is a significant gap – the description is too brief to fully inform the agent about what happens when the tool is called.