Server Quality Checklist

Tool Scores

• confirm_otpD
  1.8/5.0
  Behavior2/5

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

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

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

  Conciseness2/5

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

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

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

  Completeness2/5

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

  For a one-parameter tool, an output schema helps, but the description still leaves out the core flow: that an OTP was received by SMS and that calling this tool confirms it. It lacks any detail about prerequisites, errors, or integration with the login/session flow.

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

  Parameters2/5

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

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

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

  Purpose1/5

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

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

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus related auth tools such as login, confirm_password, confirm_pin, refresh_session, or session_status. The description neither explains that the user must have received an SMS code first nor describes what happens after confirmation.

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

• spending_categoriesD
  1.9/5.0
  Behavior2/5

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

  Annotations already convey readOnlyHint, idempotentHint, and non-destructive behavior. The description adds no behavioral context beyond the title, such as how categories are aggregated, which date range applies, or what response shape to expect.

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

  Conciseness2/5

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

  The description is short, but rather than being concise it is under-specified and effectively just repeats the title. The sole phrase does not provide enough useful information to earn its place.

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

  Completeness2/5

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

  Even though an output schema exists, this description leaves ambiguity about account scope, date handling, and the difference from siblings like operations_histogram or flows. Given the vast sibling list, an agent cannot reliably determine when to call this tool.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description provides no explanation of account_id or days. The only meaning comes from the default value 30 and the tool name, leaving both parameters ambiguous.

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

  Purpose2/5

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

  The description 'Траты по категориям' exactly restates the tool title, so it is a tautology rather than a proper definition. It identifies a domain (spending categories) but lacks a verb, scope, or differentiation from siblings like operations_histogram or list_operations.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool, what input it expects, or how it differs from other spending-related tools. No alternatives, exclusions, or intended use cases are mentioned.

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

• confirm_pinC
  2.4/5.0
  Behavior3/5

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

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

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

  Conciseness2/5

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

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

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

  Completeness2/5

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

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

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

  Parameters2/5

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

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

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

  Purpose3/5

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

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

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

  Usage Guidelines2/5

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

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

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

• bank_documentsC
  2.9/5.0
  Behavior2/5

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

  Annotations already communicate read-only, idempotent, and non-destructive behavior. The description adds only content-domain context ('statements ordered at the bank') and does not disclose any additional behaviors such as whether the list is filtered, paged, or limited to certain document types.

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

  Conciseness4/5

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

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

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

  Completeness3/5

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

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

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

  Parameters4/5

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

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

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

  Purpose3/5

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

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

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

  Usage Guidelines2/5

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

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

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

• invest_portfolioB
  3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered structurally. The description adds contextual behavior by indicating the result is period-based and includes historical/monthly valuations, but it does not disclose additional operational traits such as computed vs raw data, update timing, or limitations. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is short and front-loaded: it names the resource, enumerates the data categories, and gives the account ID source. It earns its place, though a touch more explicit parameter detail would improve it without bloating the text.

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

  Completeness3/5

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

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

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

  Parameters2/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines2/5

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

  The description gives a meaningful prerequisite — broker_account_id comes from invest_accounts() — but it does not state when to choose this tool over siblings like invest_operations or invest_securities. There is no exclusion guidance or alternative selection logic, so the usage guidance remains mostly implicit.

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

• session_statusB
  3/5.0
  Behavior1/5

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

  This is an Annotation Contradiction: the description says 'Сам поднимает уровень до CLIENT' — a state-changing action — while annotations declare readOnlyHint=true. That directly conflicts with the read-only contract. No other behavioral caveats are offered.

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

  Conciseness5/5

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

  The description is two short sentences with no filler. The first sentence states the primary purpose, the second adds the key time-relative exception, and the whole thing earns its place for a zero-parameter tool.

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

  Completeness3/5

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

  With no parameters and an output schema present, the call shape is sufficiently documented. However, the contradiction between the readOnly annotation and the described session-level mutation leaves the agent uncertain whether calling this has side effects. It also doesn't route the agent among session-related siblings, leaving a small but meaningful context gap.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema coverage is effectively 100%. There is no parameter information to add; the baseline of 4 applies because no parameter documentation is needed.

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

  Purpose4/5

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

  The description uses a concrete verb 'Проверить' (check) and a clear resource (session), so the core purpose is identifiable. It also adds a behavioral detail about raising the level to CLIENT after the ~11-minute portal-session window closes, which gives useful context. However, it does not explicitly distinguish itself from closely related session tools like refresh_session or keepalive.

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

  Usage Guidelines2/5

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

  The description does not say when to use this tool instead of alternatives such as keepalive, refresh_session, or login. It only states what it does, leaving the agent to infer the correct context and provide no exclusions or routing guidance.

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

• push_unread_countB
  3.2/5.0
  Behavior2/5

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

  The description merely restates the title and adds no behavioral detail beyond what annotations already convey. It does not mention aggregation scope, whether the count reflects only a current session, how fresh the value is, or any side effects, though annotations do signal read-only and idempotent behavior.

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

  Conciseness4/5

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

  The description is one short, front-loaded sentence and is easy to scan. It is very concise, though it largely duplicates the title and therefore adds little independent informational value.

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

  Completeness4/5

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

  Given zero parameters, a dedicated output schema, and strong annotations, the description is nearly complete for a simple read-only count tool. The main missing piece is usage guidance around when this count is relevant, but that is already reflected in the lower usage-guidelines score.

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

  Parameters4/5

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

  The tool has zero parameters and the schema coverage is 100%, so there is no missing parameter documentation for the description to compensate for. The baseline for parameter-free tools applies, and the description adds nothing harmful or confusing about inputs.

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

  Purpose4/5

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

  The description clearly communicates that the tool returns the number of unread push notifications, which is a specific resource and lightweight action even without an explicit verb like 'get' or 'count'. It distinguishes this tool from related 'unread' tools at least by the 'push' scope, though it does not mention any alternative.

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance about when to use this tool versus alternatives such as messenger_unread or other count-like tools. There is no mention of intended workflow position, prerequisites, or situations where this tool should be avoided in favor of another.

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

• messenger_unreadA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, fully covering the safety profile, so the description's remaining burden is low. The description adds one meaningful behavioral detail — labels are human-readable names and not raw IDs — but contributes nothing further about ordering, pagination, or the exact shape of the result.

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

  Conciseness5/5

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

  A single compact sentence conveys the resource and the key clarification, with the parenthetical positioned naturally after the main claim. Every word earns its place; there is no filler or redundancy for a 0-parameter tool.

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

  Completeness4/5

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

  Given zero parameters, fully protective annotations, and the presence of an output schema, the description supplies everything needed to call the tool. The only slight gap is that nothing clarifies whether the list is ordered or limited — but that information is likely covered by the output schema, so the definition is adequate.

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

  Parameters4/5

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

  The tool takes zero parameters, so per the rubric the baseline is 4. The description has nothing to compensate for since the schema is complete and empty; the names-vs-ids note is relevant to output, not input.

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

  Purpose4/5

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

  The description clearly identifies the returned resource — chats containing unread messages — and adds the decisive distinguishing trait that results are keyed by name rather than by raw id. It is obviously distinct from siblings like push_unread_count (a count) or messenger_conversations (all chats), though it does not explicitly name them and contains no verb.

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

  Usage Guidelines2/5

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

  There is no guidance about when this tool is appropriate versus alternatives such as messenger_conversations or push_unread_count. Usage is only implied by the title and phrase; the agent is not told which sibling to prefer in which scenario.

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

• account_requisitesA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the semantic context of which fields are exposed (recipient, BIC, correspondent account) and the acceptable currency formatting, which is useful. It does not disclose additional behavioral traits like response shape or provider-specific nuances, but with a low-complexity read tool and output schema present, a 3 is fair.

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

  Conciseness4/5

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

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

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

  Completeness4/5

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

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

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description carries the burden — and it compensates well. 'account_id — из list_accounts()' explains the parameter via provenance, and 'currencies — через запятую (RUB,USD,EUR)' provides both the serialization format and valid values. This meaningfully exceeds what the bare schema provides.

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

  Purpose4/5

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

  The description specifies the resource (account requisites — получатель, счёт, БИК, корсчёт, ИНН/КПП) and the intent ('для перевода извне' — for external transfers). It clarifies what the agent will receive, and the phrase 'для перевода извне' carries scope beyond the title. It does not explicitly name a sibling to distinguish from, leaving transfer_requisites/card_requisites selection partly to inference.

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

  Usage Guidelines3/5

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

  The 'для перевода извне' phrase implicitly scopes this tool to inbound-over-bank-transfer requisites, and 'account_id — из list_accounts()' gives concrete guidance on how to supply the required parameter. However, there is no explicit when-to-use versus alternatives such as transfer_requisites or card_requisites, so the agent must infer the selection logic.

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

• keepaliveA
  3.7/5.0
  Behavior3/5

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

  Annotations already cover the safety profile: readOnly, idempotent, openWorld, and non-destructive. The description adds that this is a ping that extends the current session, but it does not mention edge-case behavior such as handling an already-expired session.

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

  Conciseness5/5

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

  The description is a single short sentence that front-loads the core idea: ping, extend session. Every word contributes value and there is no redundancy.

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

  Completeness4/5

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

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

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

  Parameters4/5

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

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

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

  Purpose4/5

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

  The description uses a specific verb and resource: ping and prolong the session. It clearly separates the tool from a generic status check, though it does not explicitly contrast it with refresh_session.

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

  Usage Guidelines3/5

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

  The description implies usage as a lightweight keepalive heartbeat to extend an active session. It does not explicitly state when to prefer this over refresh_session or session_status, nor does it give exclusions.

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

• list_operationsA
  3.7/5.0
  Behavior5/5

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

  The description reveals behavioral details beyond the readOnlyHint and idempotentHint annotations: ordering (newest on top), a header showing total operation count to detect truncation, how limit=0 returns everything, and how desc_len=0 gives full description. This is exactly the kind of practical behavior an agent needs to interpret results correctly.

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

  Conciseness5/5

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

  The description is concise, front-loaded purpose, and then cleanly separate parameter notes. It avoids repetition and every part seems useful: the first sentence defines the operation, and the following lines parameter-wise cover edge cases.

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

  Completeness4/5

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

  Chain only handles truncation, ordering, and full description access, which is a strong foundation for a read-only operation. Still, it lacks explicit information about the period parameter (days) and the account classifier, and does not differentiate it from same-domain sibling tools that might be better used. Given the output schema and annotations cover many return-value and safety concerns, the missing pieces are small but noticeable.

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

  Parameters3/5

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

  The description explains limit and desc_len thoroughly, including truncation semantics, but says nothing about days or account_id. With 0% schema description coverage, the description only partially compensates; the remaining parameters must be inferred from their names and the title. So a mid score.

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

  Purpose4/5

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

  The description states what the tool does: lists operations for a period, newest-on-acc. However, it does not explicitly mention account-level focus (title 'Операции по счёту' clarifies) and does not distinguish it from sibling tools like card_operations or invest_operations, so it falls short of full 5.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives; there is no mention of account vs. card vs. investment operations, nor any exclusions or recommendations. The detailed parameter notes are about how to configure the call, not when it is appropriate. This is a clear gap.

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

• place_infoA
  3.7/5.0
  Behavior5/5

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

  Annotations already mark the tool read-only, open-world, idempotent, and non-destructive. Beyond that, the description reveals a non-obvious quirk: the address comes back EMPTY in captured responses, so with_halls=True is needed to fetch halls that carry the address. It also discloses limit semantics and the honest 'N total, shown M' reporting.

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

  Conciseness5/5

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

  The description is tight: one line establishes purpose, then two short notes cover important behavior. Every sentence earns its place, and there is no redundant restating of the tool name or annotations.

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

  Completeness4/5

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

  The output schema exists, so the description does not need to detail return values. It provides enough context for the key mechanics and known quirks, though an explicit mention of what object_id references and a routing hint relative to place-like siblings would make it fully complete.

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

  Parameters3/5

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

  This tool has 0% schema description coverage, so the description must compensate. It explains limit's special behavior (<=0 means all) and with_halls's relation to the missing address, but it never explains object_id, which is the only required parameter.

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

  Purpose4/5

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

  The description clearly states this is a venue card and enumerates the returned fields: название, город, метро, залы. It does not explicitly contrast with sibling tools like afisha_places or place_schedule, so it stops short of perfect differentiation.

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

  Usage Guidelines2/5

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

  There is no guidance about when to select place_info instead of related siblings such as afisha_places or place_schedule. The description implies the tool is for venue info, but it leaves tool-selection context entirely implicit.

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

• travel_payment_optionsA
  3.7/5.0
  Behavior4/5

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

  Besides the existing readOnlyHint, idempotentHint, and non-destructive annotations, the description adds a clear semantic warning: 'Ничего не платит и ничего не меняет' - it neither pays nor mutates anything. This is valuable because the tool name may sound like an actual payment action, and the description prevents that misunderstanding. No contradiction with annotations was found.

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

  Conciseness5/5

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

  Two compact sentences cover purpose, key output topics, and the critical no-payment/no-mutation behavior. It is front-loaded and every phrase earns its place; there is no irrelevant detail or redundancy.

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

  Completeness3/5

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

  The tool is a simple read-only lookup, has an output schema, and explains the required amount parameter, so a basic call is feasible. The optional account_id is not explained, and there is no explicit context about where in the travel booking flow this tool should be invoked. Overall, the description conveys the main usage but leaves minor ambiguity about optional parameters and triggering conditions.

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

  Parameters3/5

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

  The required amount parameter is documented meaningfully: its source, the fact that it should be taken from flight_offer() or train_book(), and that it is non-mutating. However, account_id is completely undocumented, and the schema provides no description, so only half of the parameter space is actually covered by the description.

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

  Purpose4/5

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

  The description explains that this tool shows payment options for a trip: available accounts, bonus write-offs, cashback, and installment plans. It is clearly not a payment action and the final sentence explicitly clarifies it pays nothing. However, it lacks a direct verb like 'returns' or 'lists', and it does not explicitly distinguish itself from sibling tools such as train_pay or pay_bill by name.

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

  Usage Guidelines3/5

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

  The amount parameter is tied to flight_offer() and train_book(), and the description warns that the tool does not pay or change anything. This gives a reasonable hint of when to use it, but there is no explicit 'use this before payment' or 'do not use this when the user wants to pay; use pay_bill/train_pay instead.'

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

• concert_hallA
  3.8/5.0
  Behavior4/5

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

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

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

  Conciseness4/5

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

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

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

  Completeness3/5

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

  With an output schema present, the return shape does not need to be repeated. The description clearly covers the domain boundaries, the read-only nature, and the fallback for seats. However, it does not explain how an agent should obtain or interpret event_id, slot_id, and object_id, which is a necessary step for correct invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It does explain the meaning of the kind parameter, including the two valid kinds and their exclusions, but it gives no meaning or context for the three required parameters: event_id, slot_id, and object_id. The description is not enough to fully determine how those parameters should be supplied.

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

  Purpose4/5

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

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

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

  Usage Guidelines5/5

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

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

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

• insurance_policiesA
  3.8/5.0
  Behavior3/5

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

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

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

  Conciseness5/5

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

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

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

  Completeness5/5

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

  Given zero parameters, an output schema, and strong annotations declaring read-only and idempotent behavior, the description covers all required guidance. It explicitly states the scope and key output fields, so nothing critical is missing for correct invocation.

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

  Parameters4/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines3/5

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

  The description implies use for querying current insurance policies, but it does not explicitly state when to use it versus alternatives or what user questions map to this tool. There are no close insurance-specific siblings, so no explicit routing is needed, but the guidance is still more implied than stated.

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

• train_refundA
  3.8/5.0
  Behavior1/5

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

  The description correctly discloses an important behavior: the refund is irreversible and the seat returns to sale. However, the annotation destructiveHint=false directly contradicts this "irreversible" claim. This is an Annotation Contradiction and makes the risk signal unreliable for the agent.

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

  Conciseness5/5

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

  The description is short, front-loaded, and every sentence earns its place: irreversibility, confirm workflow, and ticket_ids semantics. There is no filler material or repetition of schema details.

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

  Completeness5/5

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

  For a mutation-style tool, the description covers the essential behavior: what happens without confirmation, the irreversible side effect, and the meaning of the optional ticket_ids parameter. The output schema is available, so return-value details are not required.

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

  Parameters4/5

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

  Although schema description coverage is 0%, the description compensates for two of three parameters: confirm is explained as the flag that switches between calculation-only and actual refund, and ticket_ids is explained as optional-with-empty-means-all behavior. order_id is not explicitly described, but it is required and self-explanatory.

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

  Purpose4/5

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

  The description clearly states the action — 'ВОЗВРАТ ЖД-билета' — and adds meaningful behavioral detail, so an agent knows this is the railway ticket refund tool. It doesn't explicitly contrast with sibling tools, but the action and subject are specific enough to prevent confusion.

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

  Usage Guidelines5/5

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

  The description gives a strong usage protocol: without confirm=True the tool only computes and shows the refund calculation, and the agent must show that to the user before calling with confirm=True. It also clarifies that an empty ticket_ids means all refundable tickets in the order are returned.

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

• grocery_cartA
  3.9/5.0
  Behavior4/5

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

  Annotations already mark this as read-only, idempotent, and non-destructive. The description adds contextual behavior beyond that: it discloses that each line prints trend-only countAvailable and explains the CART_QUANTITY_CONFLICT block and the instruction to resolve discrepancies. This is honest and informative.

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

  Conciseness5/5

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

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

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

  Completeness4/5

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

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

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

  Parameters4/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines3/5

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

  The description gives a concrete prerequisite: app_id/point_id must come from grocery_stores() and match those used in grocery_add_to_cart. That is valuable usage guidance. But it does not say when this tool should be chosen instead of checking the cart elsewhere, or when it should be avoided.

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

• grocery_searchA
  4/5.0
  Behavior4/5

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

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

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

  Conciseness5/5

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

  The description is compact and well-structured: purpose first, then parameter sourcing, result qualification, and limit behavior. Every sentence provides necessary information without redundant wording.

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

  Completeness4/5

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

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

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

  Parameters3/5

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

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

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

  Purpose4/5

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

  The description states a specific action ('search product by name') and resource (grocery item), which distinguishes the tool's basic purpose. It does not explicitly compare against sibling tools like grocery_good_info or grocery_rank, so a small ambiguity remains, but the core purpose is clear.

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

  Usage Guidelines4/5

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

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

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

• invest_operationsA
  4/5.0
  Behavior4/5

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

  Annotations already convey read-only, idempotent, and open-world behavior. The description adds valuable non-obvious traits: operation types are not a stable published enum, 0 is a special limit meaning 'all returned by the bank', and results are newest-first. This is consistent with the openWorldHint and readOnlyHint.

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

  Conciseness5/5

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

  The description is compact and front-loaded: the resource is stated first, then ordering, then parameter semantics, and finally the important 'first call without filter' discovery strategy. Every sentence contributes non-duplicative value, and no phrasing is wasted.

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

  Completeness4/5

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

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

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

  Parameters3/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

  The description provides actionable in-tool usage guidance: new operations are on top, limit behaves differently when set to 0, and operation_type should be left empty first so the agent can discover available values before filtering. It does not, however, discuss when to choose this tool over related investment or operations siblings, stopping short of full guidance.

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

• train_calendarA
  4/5.0
  Behavior4/5

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

  Annotations already cover read-only, idempotent, non-destructive, open-world behavior. The description adds useful behavioral details beyond annotations: it is a cheap/lightweight call, and an invalid station-code pair produces an empty response. This edge-case disclosure is valuable.

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

  Conciseness5/5

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

  The description is two short sentences, front-loads the core purpose, and then adds a key edge-case detail. Every sentence earns its place and there is no redundant wording.

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

  Completeness4/5

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

  For a simple read-only tool with an output schema and annotations covering safety, the description provides enough to call it correctly: the purpose, the station-code requirement, and the observed empty response for invalid codes. The only notable omission is contextual info about origin/destination code sources, but this is not a critical blocker given the simple design.

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

  Parameters3/5

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

  The schema has 0% description coverage, so the description must compensate. It does clarify that origin and destination refer to a pair of station codes and that input coordinates point to a direction. However, it does not explain that the limit parameter controls the number of returned dates or any format expectations, leaving a meaningful gap.

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

  Purpose4/5

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

  The description states what the tool does: it provides the dates for which train ticket sales are open for a given direction. The title confirms the resource (ЖД dates). It is clear enough to distinguish from siblings like train_search or train_seats, though it does not explicitly name any sibling.

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

  Usage Guidelines4/5

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

  It not only implies its main use — checking open sale dates for a route — but also explicitly offers a secondary use: a cheap way to validate a pair of station codes, since an invalid pair yields an empty response. It does not directly compare itself with alternatives, but the guidance is actionable.

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

• grocery_plan_orderA
  4.1/5.0
  Behavior4/5

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

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

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

  Conciseness5/5

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

  The description is compact and every sentence provides necessary guidance: output markers, matching behavior, and where to retrieve IDs/profile. It avoids fluff and front-loads the purpose before the more detailed semantics.

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

  Completeness4/5

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

  For a read-only planning tool, the description covers the essential preconditions, inputs, and output semantics. It relies on an external 'ladder' skill and does not repeat output schema details, which is acceptable given the output schema exists. The custom_ordered vs global distinction is mentioned though not fully defined.

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

  Parameters4/5

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

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

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

  Purpose4/5

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

  The description clearly states the tool's job: 'Спланировать заказ' and explains that it looks up each ingredient (custom_ordered → global). It is specific enough to be distinguished from sibling tools like grocery_search or grocery_checkout, though it never names a sibling to disambiguate further.

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

  Usage Guidelines4/5

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

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

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

• hotel_infoA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful context beyond annotations: rates are only included when dates are provided, and no API call exists to accept bookHash for booking. This is extra behavioral information that annotations do not convey.

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

  Conciseness5/5

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

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

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

  Completeness5/5

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

  For a read-only information tool with an output schema, the description covers the core usage pattern and an important edge case (no booking). It tells the agent where to get the required parameter and what to expect. Combined with annotations and the output schema, an agent can call the tool correctly without further assumptions.

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

  Parameters3/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

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

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

• ordersA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable behavior beyond this: results are sorted by creation date descending, limit=0 means 'show all', and an empty kind means no filtering. This gives an agent useful runtime expectations not present in the annotations.

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

  Conciseness5/5

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

  The description is compact: three sentences that cover scope, filter values, ordering, and limit semantics. Every sentence adds new and useful information without redundancy. This is well-structured and easy for an agent to parse quickly.

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

  Completeness4/5

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

  With only two optional parameters and an output schema present, the description covers the essential semantics: what kind values mean, how limit works, and that data is sorted newest-first. It does not mention pagination or the distinction between one order and many orders relative to siblings, but this is not a significant gap for a read-only list tool.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It explains that kind accepts 'афиша', 'кино', 'путешествия', 'продукты', or an objectType code, and that an empty value means all orders. It also explains limit=0 explicitly. The main limitation is that the list of possible objectType codes is not exhaustive.

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

  Purpose4/5

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

  The description states 'Все заказы клиента' (all client orders) and enumerates the domains covered: groceries, cinema, concerts, flights, rail, hotels. This clearly identifies the tool as a broad order-list endpoint, distinguishable from detail-focused siblings like order_details. It lacks an explicit verb for 'return' or 'list', so it stops short of a perfect 5.

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

  Usage Guidelines4/5

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

  The description makes the usage context clear: retrieve all client orders, with an optional category filter via kind. It also states ordering behavior and the special limit=0 meaning. It does not explicitly mention when to use a sibling tool instead, so no exclusions are given, but the context is strong enough for selection in most cases.

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

• payment_statusA
  4.1/5.0
  Behavior4/5

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

  The description adds important context beyond the readOnlyHint: it warns that the tool only surfaces what MCP recorded, which may differ from the actual account state, and that 'unknown' outcome is a possible return. This is valuable behavioral caveat for an agent choosing whether to trust the result.

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

  Conciseness4/5

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

  The description is two sentences, front-loaded with the core purpose and status categories. The second sentence adds useful cross-tool context but could be tightened without losing meaning. Overall, each sentence contributes, though it is slightly dense for a simple lookup tool.

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

  Completeness3/5

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

  Since an output schema is present, the return-value details may be defined elsewhere. Still, the description could be more complete by indicating where attempt_id typically comes from, such as from a payment initiation call, and by making clear what 'MCP attempted log' means to an agent without domain familiarity.

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

  Parameters2/5

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

  With schema description coverage at 0%, the description needed to compensate by explaining what attempt_id is, where it originates, and how it should be obtained. It merely repeats the parameter name in context, leaving the agent to deduce what kind of identifier this is and how to acquire it.

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

  Purpose5/5

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

  The description clearly defines the tool as a status lookup for a payment attempt by attempt_id, enumerates the possible states (pending, confirmed, unknown), and names the underlying resource it reads (MCP attempt log). It also implicitly separates this read-only status tool from executable sibling tools like confirm_payment.

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

  Usage Guidelines5/5

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

  The description explicitly tells the agent when information from this tool is not definitive, pointing to list_operations as ground truth. It also gives actionable guidance: if a pending payment has no corresponding charge in list_operations, the agent can confirm it via confirm_payment(attempt_id, otp). This is strong when-to-use versus when-to-cross-check guidance.

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

• train_seatsA
  4.1/5.0
  Behavior4/5

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

  The description goes beyond the annotations by stating that prices and availability are fetched fresh on every call and that a seat could have been taken a minute ago. This warns about stale data and a race with train_book(), while remaining consistent with readOnlyHint, idempotentHint, and destructiveHint.

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

  Conciseness5/5

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

  The description is three short, purposeful sentences: one states the resource, one explains parameters and the internal seat format needed for booking, and one discloses freshness. Every sentence earns its place, with no repetition or filler.

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

  Completeness4/5

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

  With the output schema present and the workflow positioned between train_search() and train_book(), the agent gets the essential context for correct use, including the leading format '03/10,03/12'. The main missing piece is the semantic meaning of limit, and the defaults of car_type/max_price as 'no filter' are only implied.

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

  Parameters4/5

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

  The input schema has 0% description coverage, so the description compensates: it explains train_id's origin, enumerates car_type values ('плац', 'купе', 'сид'), and defines max_price as an upper price bound. The only parameter not explained is limit, which is a real but minor gap given its default and optional nature.

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

  Purpose4/5

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

  The description states the resource (train carriages and free seats) and the expected output format ('carriage/seat'), and distils it from siblings by linking the input to train_search() and output to train_book(). It lacks an explicit verb like 'list' or 'get', but the intent is unambiguous.

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

  Usage Guidelines4/5

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

  It explicitly places the tool in a workflow: train_id comes from train_search() and the seats format is what train_book() expects. There is no direct exclusion of alternatives such as train_calendar or flight_seats, but the upstream and downstream relationships are clear enough for an agent to know when to call it.

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

• cinema_bookA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate this is not read-only and not destructive, but the description adds behavioral context beyond those hints: it creates an order, does not collect money yet, and unpaid reservations expire automatically. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is front-loaded with the core behavior and then provides only necessary clarifying details about seat formats, seat_type, and payment flow. Every sentence adds value.

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

  Completeness4/5

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

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

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

  Parameters3/5

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

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

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

  Purpose5/5

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

  The description clearly states the tool books seats and creates an order, explicitly noting that it does NOT pay. It distinguishes itself from ticket_pay and sets the correct expectation for a booking operation.

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

  Usage Guidelines4/5

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

  The description explicitly says that payment is handled separately by ticket_pay and that unpaid bookings auto-cancel, which guides the agent on when and how to use this tool. It doesn't discuss all sibling alternatives like ticket_cancel, but the critical workflow distinction is clear.

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

• grocery_good_infoA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral detail beyond annotations: it lists the returned product fields, explains that КБЖУ is given both per 100 g and per package, and notes that in some chains КБЖУ exists only as text and is parsed. This is useful context not available from the annotations alone.

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

  Conciseness5/5

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

  Two sentences: sentence on the card contents and sentence on the source of good_id plus КБЖУ units and parsing behavior. Every part earns its place; there is no unnecessary repetition.

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

  Completeness4/5

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

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

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

  Parameters3/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

  It provides direct usage guidance: good_id must come from grocery_search() or grocery_plan_order(). This tells the agent when to call this tool and where to obtain the required input. However, it does not explicitly state when not to use this tool or mention alternatives, so it falls just short of a 5.

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

• refresh_sessionA
  4.2/5.0
  Behavior5/5

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

  The description goes beyond the annotations by revealing the exact fallback chain: refresh_token first, silent SSO_SESSION re-login on invalid_grant, and REAUTH_REQUIRED if both paths fail. This is valuable behavioral context, especially the fact that no OTP prompt is involved.

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

  Conciseness5/5

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

  The description is short, clear, and front-loaded with the core purpose. Every sentence adds necessary information: the action, the primary mechanism, the fallback mechanism, and the terminal failure condition. No filler or repetition.

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

  Completeness5/5

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

  For a zero-parameter tool with a known output schema, the description covers everything needed to invoke it correctly: what it does, how it handles failures, and what final state the agent should expect. The mention of REAUTH_REQUIRED is particularly useful for the calling agent.

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

  Parameters4/5

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

  The tool has zero formal parameters and the input schema is already complete at 100% coverage. The description correctly explains the internal refresh behavior without needing to document parameters. This matches the baseline for parameter-light tools.

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

  Purpose4/5

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

  The description clearly identifies the action: refresh a session, with a specific object and a concrete inner fallback flow. It stands out from generic 'login' or 'status' sibling tools, but it does not explicitly name the alternatives it differs from, so it stops just 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.

  Usage Guidelines3/5

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

  The use case is implied: an agent should call this to refresh an existing session, first by refresh_token and then by silent SSO re-login when invalid_grant occurs. However, the description does not explicitly say when to call this instead of `keepalive`, `session_status`, or `login`, nor does it mention conditions like an expired token.

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

• card_limitsA
  4.3/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the behavioral burden is largely carried. The description adds no contradiction and provides extra context about what data is shown, but it does not disclose other behavioral details such as freshness or authorization subtleties.

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

  Conciseness5/5

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

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

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

  Completeness5/5

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

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

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

  Parameters4/5

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

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

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

  Purpose5/5

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

  The description clearly states the tool's purpose: it returns card limits for purchases and withdrawals, plus the amount already spent. This goes beyond the title and is easy to separate from sibling tools like card_operations or card_requisites.

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

  Usage Guidelines4/5

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

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

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

• grocery_add_to_cartA
  4.3/5.0
  Behavior5/5

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

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

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

  Conciseness5/5

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

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

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

  Completeness4/5

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

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

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

  Parameters4/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

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

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

• grocery_rankA
  4.3/5.0
  Behavior5/5

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

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

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

  Conciseness5/5

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

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

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

  Completeness4/5

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

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

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

  Parameters4/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

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

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

• loginA
  4.3/5.0
  Behavior4/5

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

  Annotations already mark this as a non-read-only, non-destructive action. The description adds valuable behavior context: it sends an SMS OTP, returns the next authentication step, and indicates that password entry is out of the agent's scope. This goes beyond the structured annotations.

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

  Conciseness5/5

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

  The description is compact and every sentence carries actionable meaning. It front-loads the core action, lists expected behavior, and ends with the password fallback. No filler content is present.

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

  Completeness4/5

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

  The description covers the main flow, next-step routing, and manual fallback, and the output schema covers the return format. It would be slightly more complete with more detail on phone number formatting or failure handling, but these are secondary for this tool.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain the phone parameter format, validation rules, or expected normalization (e.g., +7 vs 8). For a single required parameter this is a notable gap, even though the title "Phone" gives some hint.

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

  Purpose5/5

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

  The description states a specific action—"Начать логин" and explains it sends an SMS OTP and returns the next authentication step. It also clearly distinguishes itself from follow-up tools like confirm_otp and confirm_pin.

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

  Usage Guidelines5/5

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

  The description gives explicit instructions on what to do after the tool runs: ask the user for the OTP and call confirm_otp, or confirm_pin if requested, and opens the password path by launching login_cli.py. This makes the workflow unambiguous.

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

• search_appA
  4.3/5.0
  Behavior5/5

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

  Beyond the annotations, the description adds key behavior: 400 for any non-enum screen value, the default screen being afisha, the output semantics for afisha (eventId suitable for schedule tools), and the deep-link requirement for services. This is exactly the kind of behavioral context an agent needs and is entirely consistent with the read-only, idempotent annotations.

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

  Conciseness5/5

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

  The description is compact and every bullet earns its place: the strict-enum warning, the default screen, and per-screen behavior are all useful and non-redundant. The most important guidance ('СТРОГИЙ enum, угадывать бесполезно') is front-loaded, and formatting is easy for an LLM to parse.

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

  Completeness4/5

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

  The description is sufficient for the core call: it lists the screens, gives their meanings, warns about invalid values, and points to specialized grocery tools. Since an output schema exists, the return shape does not need full explanation in the description. Minor gaps remain (e.g., query syntax and pagination limits), but they are not blocking for invocation.

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

  Parameters4/5

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

  With 0% schema description coverage, the description carries most of the parameter documentation. It enumerates all valid screen values, marks afisha as default, and clarifies what each screen returns. 'Полнотекстовый поиск' defines the query parameter in context, while limit is name enough to be understandable since its default is already in the schema.

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

  Purpose4/5

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

  The description opens with a specific verb and resource ('Полнотекстовый поиск по разделу приложения') and then details the distinct screen modes, so it is clear what tool does. It also distinguishes grocery from grocery_search/grocery_rank and ties afisha output to cinema_schedule/concert_schedule. However, it does not explicitly contrast itself with other search siblings like cinema_search or shop_search, so it falls just short of full sibling differentiation.

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

  Usage Guidelines4/5

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

  The text explicitly says grocery should use grocery_search/grocery_rank instead and explains the requirements for those tools. It also warns that screen is a strict enum and that invalid values produce 400, which guides safe invocation. Still, it does not lay out exhaustive when-to-use-versus-alternatives rules for all other searching siblings, so it is clear but incomplete.

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

• documentsA
  4.4/5.0
  Behavior5/5

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

  The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description adds substantial extra context: the data store contains documents belonging to relatives, they are filtered out by date of birth by default, and include_others=True changes their visibility. This subtle behavior is essential for correct invocation and is not derivable from the schema or annotations.

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

  Conciseness5/5

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

  The description is compact and front-loaded: it first enumerates supported document kinds, then explains parameter behavior, and finally reveals the subtle relatives filtering edge case. Every sentence carries meaningful information and there is minimal non-content language.

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

  Completeness5/5

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

  The description is sufficiently complete for a read-only list tool with two optional parameters and an output schema. It covers the document types, filtering semantics, and the unusual relatives-filtering behavior, leaving little room for an agent to misinvoke the tool.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description fully compensates by explaining both parameters: kind is a filter by name or code, with examples and an 'empty = all' rule, and include_others is the flag that surfaces relatives' documents. There is no ambiguity left about the meaning of the two arguments.

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

  Purpose4/5

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

  The description clearly identifies the resource by listing concrete client document types (паспорт, СНИЛС, ИНН, ПТС/СТС, etc.) and explains the filtering capability. It does not use an explicit imperative verb like 'list' or 'retrieve', so the exact action is slightly inferred rather than stated.

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

  Usage Guidelines3/5

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

  Usage is implied through the parameter explanations: kind filters by name or code with an explicit default of all documents, and include_others proactively shows relatives' documents when true. However, there is no direct comparison to sibling tools such as bank_documents or any when-to-use versus when-not-to-use guidance.

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

• invest_accountsA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare the tool readOnly, idempotent, and non-destructive, so the description doesn't need to repeat that. It adds meaningful behavioral context: the tool exposes brokerage and InvestBox accounts, and its output is a required dependency for investment operations. No contradiction with annotations.

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

  Conciseness5/5

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

  Two crisp sentences: the first defines the scope, the second explains the critical relationship to sibling tools. Every word serves a purpose and the information is front-loaded.

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

  Completeness5/5

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

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

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

  Parameters4/5

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

  The input schema has no parameters, so there is nothing for the description to explain on that side. The description adds value by naming the key output property 'brokerAccountId' and its role, though that is not input semantics.

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

  Purpose4/5

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

  The description identifies the resource explicitly — 'Инвест-счета' (investment accounts), qualified as brokerage and InvestBox. It further clarifies that the tool is the source of brokerAccountId for three sibling investment tools, which distinguishes it from them. Lacking an explicit verb such as 'list' or 'get', the purpose is clear but not fully stated.

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

  Usage Guidelines5/5

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

  The description states a precise usage rule: brokerAccountId from this tool is the only argument for invest_portfolio/invest_operations/invest_securities. This directly tells an agent when to call this tool instead of the sibling investment tools.

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

• order_detailsA
  4.4/5.0
  Behavior4/5

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

  Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description need not restate that. It usefully adds that the tool only serves entertainment orders and lists the kind of information returned, filling in behavioral scope without contradiction.

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

  Conciseness5/5

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

  The description is compact, grammatically efficient, and frontloaded. It covers the core behavior in the first sentence and immediately routes to the correct alternatives in the second, with no wasted words.

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

  Completeness4/5

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

  Given there is an output schema, the single required parameter, and read-only annotations, the description gives enough context for selecting and using the tool. It includes scope and alternative—only minor extra detail like error behavior for non-entertainment orders is missing, but that is not essential.

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

  Parameters3/5

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

  The input schema only has order_id string with no documentation, and the description adds no extra format, source, or validation details beyond saying this is for a single order. Since schema coverage is 0%, the description only provides minimal compensation, but order_id is a clear enough identifier in context.

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

  Purpose5/5

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

  Description states a clear resource (one order) and scope (entertainment orders: cinema/concerts), and lists the specific fields returned such as seats, hall, booking-code, and cart-composition. It explicitly differentiates from sibling tools, so an agent can select it without ambiguity.

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

  Usage Guidelines5/5

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

  The description explicitly says what it is used for, and gives direct alternatives for other cases: grocery_order_status for grocery orders and travel_order_details(order_id) for travel. This clearly covers when to use this tool vs its siblings.

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

• travel_order_detailsA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description adds meaningful behavioral context: for rail it shows carriage, seats, and e-registration status; for air it shows route and documents; for hotel it shows dates, room, meals, and guests. It also clarifies that file generation is delegated to travel_ticket_file, a key boundary for agents.

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

  Conciseness5/5

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

  The description is compact and well organized: first line states the resource and categories, second line describes category-specific detail fields, third line routes ticket-file requests to a sibling tool. There is no repetition or filler, and each sentence adds new information.

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

  Completeness4/5

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

  Because an output schema exists, the description does not need to spell out return types. It covers the main invocation context: which order_id to use, what type-specific detail is shown, and where to get the actual ticket file. It does not mention trip-level status or payment-related context, but those seem out of scope for this tool.

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

  Parameters4/5

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

  The schema provides only a bare 'order_id' string with no further description, so the description must carry the meaning. It does this by saying the order_id comes from the orders() list for travel orders, and is the identifier of a specific trip. This is sufficient for the single parameter, though an example or format hint would strengthen it further.

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

  Purpose5/5

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

  The description states a specific verb and resource: it returns details of a travel order by orderId, covering hotel, train, and airplane. It also names the sibling travel_ticket_file as the path for obtaining a ticket file, which helps distinguish this tool from nearby alternatives.

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

  Usage Guidelines4/5

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

  The description gives clear context: use it when you have a travel order ID and need hotel/train/air details. It explicitly points to travel_ticket_file when the agent needs a ticket or receipt saved to a file. It does not list explicit exclusion cases like payments or bookings, so it is not a perfect 5.

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

• travel_ticket_fileA
  4.4/5.0
  Behavior5/5

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

  The description discloses valuable behavioral details beyond what annotations provide: the default output directory, 0600 file permissions due to personal passport data, the fact that existing files are not overwritten, and the overwrite=True opt-in. It also explains output structure differences between rail and air bookings.

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

  Conciseness5/5

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

  The description is front-loaded and dense: action, default path, source of order_id, vertical-specific output, file permissions, and overwrite behavior. Every sentence contributes operational value and none of it needlessly repeats the title.

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

  Completeness5/5

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

  For a file-creation tool with only one required parameter, an output schema, and non-destructive safety behavior, the description covers all essential invocation concerns: input provenance, output format, default location, permission handling, and overwrite semantics. No critical operational gap is apparent.

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

  Parameters4/5

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

  With 0% schema description coverage, the description carries the full burden for parameters, and it largely succeeds: order_id provenance is given, overwrite behavior is explicitly described, and the default save path clarifies the save_to parameter. However, save_to is only implicitly described through the default path, and it is not fully clear whether it is a directory or a file path.

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

  Purpose4/5

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

  The description uses a specific verb ('Сохранить') and a specific resource ('билет в файл'), and clarifies the supported verticals: railway tickets and flight route receipts. It establishes the tool's scope well, but it does not explicitly distinguish it from related sibling tools such as ticket_qr or payment_receipt.

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

  Usage Guidelines4/5

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

  The description clearly tells an agent how to source the required order_id: from orders('путешествия'), train_book(), or flight_book(). It also explains that the tool auto-detects the vertical. It does not explicitly name alternatives to avoid, but the sourcing guidance is strong enough for correct invocation.

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

• messenger_sendA
  4.5/5.0
  Behavior5/5

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

  Beyond the annotations, the description adds important behavioral context that the user message will be read by a live human, that the message is irreversible, and that user confirmation must be obtained beforehand. This is critical operational context not found in readOnlyHint, openWorldHint, or destructiveHint. The word "irreversible" is about being unable to retract the message, which does not contradict destructiveHint=false.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the most important warning: the action is irreversible and visible to a human. Each sentence contributes real guidance, though there is slight redundancy between "irreversible" and "cannot be recalled".

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

  Completeness4/5

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

  The definition is sufficiently complete for a simple two-parameter messaging tool. It covers the key prerequisite (conversation_id), the user confirmation requirement, and the irreversible human-facing nature. The existence of an output schema reduces the need to explain returns, and the description does not address errors or invalid conversation handling, but these are not needed for adequate invocation guidance.

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

  Parameters4/5

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

  With schema description coverage at 0%, the description compensates for conversation_id by stating it comes from messenger_conversations(), and for text by implying it is the content shown and sent to the user. It does not add formatting or length constraints, but the two plain string parameters are primarily clarified through this additional source and confirmation guidance.

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

  Purpose5/5

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

  The description clearly states the operation: sending a message into a chat, with a specific verb and resource. It differentiates itself from the sibling messenger_* tools, such as messenger_conversations, messenger_messages, and messenger_unread, which are read operations.

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

  Usage Guidelines4/5

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

  The description provides strong usage context: it is for sending a chat message to a human (usually bank support), it is not for moving money, and explicit consent is required before sending. It tells the agent to pull conversation_id from messenger_conversations(), and while it does not name explicit alternatives, it effectively separates this tool from money-moving tools like transfer.

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

• operations_histogramA
  4.5/5.0
  Behavior5/5

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

  The description adds several behavioral details beyond annotations: internal transfers are always excluded via config=allNotInner, max_chars caps the response and the header names any truncation, and the endpoint has only been verified with period=day and group_by=category. Annotations already confirm safety; the description enriches the operational picture.

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

  Conciseness4/5

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

  The description is longer than one sentence because there is genuinely complex behavioral context to convey. It is front-loaded: the first sentence states what the tool returns and which sibling to use instead. The later paragraphs are earned detail rather than padding.

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

  Completeness4/5

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

  It covers the raw output shape, the canonical alternative tool, the internal-transfers exclusion, response truncation semantics, and the risk of unverified parameter values. It remains short of complete because the semantics of days and account_id are never explained, and those parameters will affect what the agent requests.

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

  Parameters3/5

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

  With 0% schema description coverage, the description only partially compensates: it explains max_chars fully and warns about period/group_by behavior, but does not explain days, period semantics, or what account_id controls beyond its empty default. The defaults hint at meaning, but important params remain under-documented.

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

  Purpose5/5

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

  The description states a clear verb and resource: returns raw JSON of expenses grouped by the bank. It also actively distinguishes itself from spending_categories and list_operations, so an agent can identify this tool without opening the schema.

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

  Usage Guidelines5/5

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

  Explicitly instructs when to prefer spending_categories for ready-made category breakdowns and list_operations for a full transaction list including internal transfers. It also flags the only verified parameter combination and warns that other values may cause a 400.

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

• payment_qrA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds what happens beyond the annotation state: the tool queries the bank for the provider, is safe to run first as a preview, and may optionally need a user-provided comment if the QR lacks the payment purpose. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is longer than a simple sentence, but every phrase 'adds' something: the non-destructive note, the provider routing, the comment issue. It is front-loaded with the core purpose and read-only warning. It is somewhat cluttered in the paragraph, but not bloated.

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

  Completeness4/5

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

  The output schema handles formal return fields, while the description explains the practical flow: what recipient info is shown, which downstream sibling to pick, when to ask about comment. This is sufficient for an agent to call and use the tool correctly; additional nuance such as error handling for invalid QR codes would be a small bonus.

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

  Parameters4/5

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

  With 0% schema coverage, the description carries the full burden for `qr`. It identifies needed input as the payment QR from a receipt/invoice, formatted per GOST with the ST0001... payload. It implies this directly maps to the only parameter, though it never explicitly writes 'pass the QR payload in the qr parameter', which would make it clearer.

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

  Purpose5/5

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

  States a unique verb+resource: "Прочитать платёжный QR со счёта/квитанции" with the specific standard and format (ГОСТ Р 56042-2014, ST0001). It also differentiates itself from siblings like ticket_qr by scope (payment) and from pay_bill/transfer_requisites by role (parse/read vs. execute payment).

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

  Usage Guidelines5/5

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

  Explicitly says when to use: before transfer_requisites, to show the user recipient/amount/commission. It also contains a routing rule: legal-entity requisites → transfer_requisites, any other provider → pay_bill, plus a condition for when comment must be asked from the user. This makes alternatives and selection conditions clear.

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

• transfer_sbp_resolveA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnlyHint/idempotentHint annotations, the description explains behavior that matters for correct invocation: the tool is safe but not money-moving, it returns a ready provider_fields value that should not be hardcoded, T-Bank account candidates lack bank_member_id, and the tool may refuse if selection is ambiguous. No contradiction with annotations.

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

  Conciseness4/5

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

  The core purpose and read-only safety warning are front-loaded, and the second paragraph is dense with important nuances. There is some historical/explanatory context that is not strictly necessary for invoking the tool today, so the description is a bit longer than the ideal while still being well-structured.

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

  Completeness4/5

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

  The description covers the two critical halves, when to call and how to use the result, and it explains the confusing T-Bank-vs-SBP candidate split. It does not define the phone format or the exact behavior when no recipient is found, which is a minor gap given there is only one required parameter and the safety profile is covered by annotations.

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

  Parameters3/5

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

  The schema provides no description for the single phone parameter, so the description must compensate. It identifies the parameter as the recipient’s phone number, but it does not specify format, normalization, country-code expectations, or any validation rules, leaving partial ambiguity.

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

  Purpose5/5

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

  The description clearly states a specific operation: resolving a recipient by phone number, read-only, covering both T-Bank accounts and SBP banks. It also names the returned artifacts, masked name, bank, isDefaultBank, provider_fields, which is far more distinctive than the tool title alone.

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

  Usage Guidelines5/5

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

  It explicitly says to use this tool BEFORE transfer()/payment_commission() for a new unsaved recipient, and then gives the exact next steps for transfer(): pass pointer_link_id, add bank_member_id for SBP banks, or omit to use the default. This gives the agent concrete selection and invocation guidance rather than leaving it implied.

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

• afisha_placesA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, but the description adds useful behavioral detail not in annotations: query is local filtering only, no text-search bank exists, pages are read fully before filtering, and city is effectively required. A full picture is missing only for limit behavior, but the added context is meaningful.

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

  Conciseness5/5

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

  The description is compact, front-loads the core purpose, and each sentence adds a distinct fact. There is no fluff or repetition.

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

  Completeness4/5

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

  Given an existing output schema, the description covers purpose, upstream identification, downstream usage, required city, and page/filter semantics. The only missing operational detail is limit and its relationship to the pages parameter, so the description is nearly complete for correct invocation.

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

  Parameters4/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines5/5

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

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

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

• card_operationsA
  4.6/5.0
  Behavior5/5

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

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

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

  Conciseness5/5

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

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

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

  Completeness4/5

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

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

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

  Parameters4/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

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

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

• card_requisitesA
  4.6/5.0
  Behavior5/5

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

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

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

  Conciseness5/5

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

  Every sentence earns its place: first introduces the data, then default masking behavior, then the potential risk with `reveal=True` and a concrete example of what is NOT a valid request. The structure is front-loaded and reasonably compact with no fluff.

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

  Completeness5/5

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

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

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

  Parameters5/5

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

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

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

  Purpose4/5

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

  The description clearly identifies card requisites as the resource and lists what is provided (holder, expiration, number). It distinguishes this tool from account_requisites and transfer_requisites by explicitly mentioning card and the `ucid` from `list_cards()`, though it lacks an explicit verb like 'returns' or 'gets'.

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

  Usage Guidelines4/5

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

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

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

• cinema_seatsA
  4.6/5.0
  Behavior5/5

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

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

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

  Conciseness5/5

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

  The description is dense but well-structured: front-loaded purpose and side-effect-free behavior, then parameter semantics, then a short critical usage/format note. Every sentence adds useful information, and there is no fluff.

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

  Completeness4/5

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

  For an eight-parameter read-only tool with zero schema descriptions, the description covers a lot: parameter provenance, default display limits, kind aliases, filtering behavior, and the booking handoff requirement. The only meaningful omission is event_id, which remains a required parameter without any explanation.

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

  Parameters4/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

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

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

• diagnosticsA
  4.6/5.0
  Behavior4/5

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

  The annotations already declare readOnly, idempotent, and non-destructive behavior. The description then adds genuinely useful context: records are redacted and contain no secrets, the data comes from a local events file, and the header reveals total count so the user can see how many events are omitted by limit. There is no contradiction with annotations.

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

  Conciseness5/5

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

  The description is compact and information-dense: purpose, safety redaction, source path, and parameter semantics are all covered in two short sentences. There is no filler and the diagnostic intent is front-loaded before the limit explanation.

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

  Completeness5/5

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

  For a single-parameter read-only diagnostics tool with an output schema, the description is complete: it explains the event kinds covered, the source file, the no-secrets policy, possible diagnostic use, and how to interpret the output header. Nothing essential is missing for correct selection and invocation.

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

  Parameters5/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

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

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

• flight_bookA
  4.6/5.0
  Behavior5/5

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

  Annotations already mark the tool as destructive and non-idempotent, but the description adds much more: real money is spent in one step, a payment confirmation button appears, the client is refused without explicit elicitation, and the payment may be declined due to the unavailable travel session. The caveat that the signature was reconstructed but live payment was never executed is unusually explicit.

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

  Conciseness3/5

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

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

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

  Completeness4/5

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

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

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

  Parameters4/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines5/5

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

  The description gives explicit usage context: use the tool after offer_id and fare are known, show the final price and rules to the client, and let confirmation happen via the button. It explicitly excludes child bookings, refunds via MCP, and defines when force=True may be used after checking trips() and the app.

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

• flight_offerA
  4.6/5.0
  Behavior4/5

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

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

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

  Conciseness5/5

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

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

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

  Completeness5/5

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

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

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

  Parameters5/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

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

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

• flight_searchA
  4.6/5.0
  Behavior5/5

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

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

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

  Conciseness5/5

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

  The core purpose is front-loaded in the first sentence, and the rest is parsed into compact sections: code resolution, offer policy, booking/payment recommendation, and endpoint caveat. Every paragraph carries decision-relevant info; there is no filler.

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

  Completeness4/5

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

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

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

  Parameters3/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines5/5

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

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

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

• flight_seatsA
  4.6/5.0
  Behavior5/5

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

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

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

  Conciseness5/5

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

  The description is compact and front-loaded: the seat map purpose comes first, then input provenance, then the one critical workflow detail. There is no filler or repetition of what the schema and annotations already state.

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

  Completeness4/5

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

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

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

  Parameters3/5

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

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

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

  Purpose5/5

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

  The name and first phrase clearly identify a seat map for a flight with prices ('Карта мест в салоне с ценами'). It ties the tool to flight_search() and flight_offer(), which distinguishes it from siblings like train_seats and cinema_seats while making the resource unambiguous.

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

  Usage Guidelines5/5

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

  The description gives the exact workflow placement: take offer_id from flight_search(), take fare from flight_offer(), and pass selected seats into flight_book(). It also gives an implicit when-not-to-use by noting seats are optional and a row will still be assigned at check-in.

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

• flowsA
  4.6/5.0
  Behavior4/5

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

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

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

  Conciseness5/5

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

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

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

  Completeness5/5

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

  Для простого инструмента с одним параметром описаны все ключевые сценарии использования и задокументировано поведение без параметра. Наличие output schema снимает необходимость описывать возвращаемую структуру, а фраза про фильтрацию разделов уточняет объём выводимых данных.

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

  Parameters5/5

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

  При schema description coverage 0% описание целиком компенсирует отсутствие описания параметра в схеме. Оно объясняет, что topic — это свободная формулировка, приводит наглядные примеры тем и детально описывает сценарий с пустым значением. Для одного необязательного параметра этого достаточно.

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

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

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

• grocery_attemptsA
  4.6/5.0
  Behavior4/5

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

  The annotations already declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description reinforces read-only behavior. It adds behavioral context about output shape and header count: limit=0 means all attempts and total count is shown in the header, which is useful beyond annotations.

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

  Conciseness5/5

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

  Every sentence earns its place: purpose, returned fields, use case, and parameter edge case are covered in three compact lines. The most important context (read-only, UNKNOWN reconciliation) is front-loaded, with no filler.

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

  Completeness5/5

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

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

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

  Parameters5/5

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

  The schema has one parameter, `limit`, with no schema-level description, but the tool description fully documents it: 'how many recent attempts to show (0 = all)' and notes the total count in the header. This adds real semantic value beyond the raw integer schema.

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

  Purpose5/5

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

  The description names a specific resource — recent grocery checkout attempts — and a specific verb: show/display. It also states the exact use case (reconciliation after an UNKNOWN checkout result) and the returned fields, which clearly separates it from siblings like grocery_checkout and grocery_order_status.

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

  Usage Guidelines4/5

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

  The description gives an explicit trigger condition: use it after checkout returns an indeterminate UNKNOWN result, when reconciliation is needed. It does not explicitly list sibling alternatives or exclusion conditions, so it falls just short of the strongest possible guidance.

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

• grocery_storesA
  4.6/5.0
  Behavior5/5

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

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

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

  Conciseness4/5

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

  The text is longer than average, but every sentence is load-bearing: result contents, dependency note, sort policy, parameter values, and the edge-case semantics. It is front-loaded with what the tool returns, and the sorting rationale is necessary to justify a non-obvious rule rather than filler.

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

  Completeness4/5

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

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

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

  Parameters5/5

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

  Schema description coverage is 0% and there are no enums, so the description carries the entire load. It fully documents sort_by (speed/price/min_sum with their meanings) and order (asc|desc), and even explains the behavior of borderline values. The descriptions' param info is high-value and completes the schema.

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

  Purpose5/5

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

  The description states a concrete verb+resource: the list of stores available at the user's address, with the delivery window, price, minimum order sum, and cashback. It also distinguishes the tool from its many grocery siblings by noting it provides the appId/pointId that all other grocery tools need, positioning it as the entry-point listing tool.

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

  Usage Guidelines4/5

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

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

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

• invest_securitiesA
  4.6/5.0
  Behavior5/5

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

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

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

  Conciseness5/5

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

  The description is compact and every sentence earns its place: it states the returned fields, defines the parameter contract, and warns about the multiple-portfolio edge case. It adds the important 'Учти' caveat without burying the primary usage information.

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

  Completeness5/5

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

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

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

  Parameters5/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

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

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

• messenger_conversationsA
  4.6/5.0
  Behavior4/5

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

  Annotations already mark the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context: pagination offset is relative to the beginning of the list, next-page offset comes from a prompt in the response header, and archive mode changes the visible set. This goes beyond what the annotations communicate.

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

  Conciseness5/5

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

  The description is compact, front-loaded with the purpose, and each sentence earns its place: purpose, parameter semantics, and sibling disambiguation. There is no redundant or boilerplate text.

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

  Completeness5/5

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

  Given that an output schema exists and the annotations establish safety and idempotence, the description is complete enough for correct use. It covers pagination, archive behavior, the query parameter meanings, and protects against a likely confusion with messenger_messages.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description fully compensates by explaining both parameters: offset means which chat to start from and carries pagination guidance, archived=True selects archived chats. It also warns about the offset trap with messenger_messages, which is critical for correct invocation.

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

  Purpose5/5

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

  The description opens with 'Список чатов', a clear verb+resource statement, and adds that it returns one page. It also explicitly distinguishes itself from messenger_messages on the offset semantics, so an agent can tell the two sibling tools apart.

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

  Usage Guidelines4/5

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

  The description gives concrete invocation guidance: how to compute the next page offset, what archived=True means, and explicitly warns not to reuse offset from messenger_messages because the counting direction differs. It makes the intended usage clear even though it doesn't enumerate all when-not-to-use cases.

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

• pay_billA
  4.6/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description discloses that this operation moves real money, validates fields against a regex before sending, computes a commission, shows a payment confirmation button, may reject a payment without customer solicitation, and cannot itself confirm the payment — the agent should check list_operations. This is far richer than the annotations alone.

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

  Conciseness4/5

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

  The description is long but tightly packed with warnings and operational requirements, not filler. It front-loads the purpose and the “real money” risk, then flows through input requirements, confirmation, post-payment verification, and the force caveat. Some sentences could be clearer, such as the confusing “TBANK_CONFIRM_ABOVE” threshold, but all content earns its place.

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

  Completeness5/5

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

  For a financial mutation tool with a complex confirmation flow, the description covers the essential context: where the input comes from, validation behavior, user confirmation UI, post-payment verification, risks of wrong account numbers, and the strict meaning of force. An output schema exists, so it need not restate return values, and this description is complete enough for an agent to invoke the tool correctly.

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

  Parameters4/5

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

  Even though schema description coverage is 0%, the description compensates for the core parameters: provider_id and fields are explicitly described as coming from payment_providers, with a JSON example and a warning against guessing field names. It also explains force assignment. Less critical optional parameters like group and from_account are not covered, but the most important ones are explained.

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

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with the explicit purpose “Оплатить счёт” (pay a bill) and lists concrete categories: utilities, communications, internet, fines, and taxes. This clearly identifies both the resource and the action, distinguishing it from transfer, payment_qr, or confirmation utilities.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives strong when-to-use guidance: pull provider_id and fields from payment_providers, verify post-payment with list_operations, and only fall back to force=True when the user confirms the previous payment failed. It does not explicitly contrast with direct sibling payment tools, but it does cover the critical pre-conditions and confirmation flow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• place_scheduleA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds useful scoping behavior beyond that: the result set excludes cinema, and the required identifier is sourced from afisha_places() or search_app(). It does not describe pagination behavior or response details, but the presence of an output schema and defaults softens that gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it states the domain, flags the sharp exclusion of cinema, and gives the source of the required parameter. Every sentence earns its place, and the newline separation between the canvas scope and the cinema alternative makes it easy for an agent to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only schedule lookup, the message gives enough to invoke it correctly: content scope, negative case, and how to obtain object_id. The optional pagination fields are not explained, but their names, defaults, and the output schema mitigate ambiguity. It is nearly complete for this relatively simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries real parameter-semantics responsibility. It compensates for the only required parameter by stating object_id comes from afisha_places() or search_app(), which is the key call-blocking detail. The optional page/count/limit params are left to their self-explanatory names and defaults; adding one sentence about them would make it more complete.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description declares the resource explicitly: 'Что идёт на площадке: концерты, спектакли, выставки.' It names a specific verb intent (retrieve the venue's schedule) and the resource (the place). It also distinguishes itself from the cinema_schedule sibling by stating 'КИНО здесь НЕТ' and routing cinema queries elsewhere.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives direct when-to-use guidance: use this for venue events such as concerts, theater, and exhibitions, and explicitly says to use cinema_schedule instead for cinema. It also tells the agent where the required object_id comes from: afisha_places() or search_app(). This is actionable selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• shop_cartA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, it discloses the absence of a confirmed checkout step, the need to pay in the app, and the per-cart calculation with honest «N всего, показано M» counts. This gives agents practical knowledge of behavior and limitations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and information-dense, with the core purpose front-loaded and parameter semantics clearly separated. No sentence is wasted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only listing tool with one parameter and an output schema, it covers invocation limits, per-cart intelligence, and the critical checkout limitation. Missing return-value details are already covered by the output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only provides a default value for limit, but the description fully explains its meaning: number of items shown per cart, with <=0 meaning all items, and clarifies per-cart handling. This fully compensates for the 0% schema description coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the resource as marketplace carts, one per seller, and uses «показать» to convey a read/list operation. It does not explicitly contrast sibling tools like grocery_cart, but the marketplace scoping makes the object distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly states that order placement through MCP is unsupported and that payment must happen in the app, which is critical for setting expectations when to use this tool. It does not explicitly name alternatives, but the surrounding sibling list and resource scoping imply the boundary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• train_payA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the destructiveHint annotation, the description discloses the real-money confirmation dialog, the card_id-dependent failure behavior, the requirement for user elicitation, that the amount comes from the order and not an argument, and the exact meaning of force=True. This is substantially more transparent than the annotations alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded and comma-separated hard with concrete, security-sensitive details. It is longer than minimal, but every paragraph earns its place: confirmation UI, card selection flow, amount source, and force semantics. Minor redundancy appears in sometimes repeated warnings about card_id and imperatives, which keeps it just shy of 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers confirmation, absence of card_id, refusal behavior, buttoned elicitation, source of the amount, and the force parameter. The output schema exists, so the description does not need to detail return fields. The tool is fully safe in operational decisions despite 0% schema coverage for parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, but the description compensates well: it explains card_id (without it the tool returns a payment card list; only card_id is accepted), order_id as the existing booking/order, and force=True as a conditional explicit retry. It could be stronger by explicitly stating that order_id must come from train_book(), but it nonetheless carries the param meanings.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'ОПЛАТИТЬ бронь поезда', naming a specific verb, resource, and operation. The 'РЕАЛЬНЫЕ ДЕНЬГИ' warning and the explicit link to train_book() make the tool's purpose unmistakable and distinguishable from siblings like train_book, train_refund, pay_bill, and transfer.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives direct instructions: the tool itself shows a confirmation button, so the agent should not ask a textual yes/no; a card_id is required and the flow for obtain cards is described; force=True is restricted to uncertain outcomes after an in-app check. It does not explicitly route away from sibling payment tools, but its coupling to train_book and the condition context make the intended usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cinema_searchA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations cover read-only and idempotent status, and the description adds substantial non-obvious behavior: limit defaults to 20 but limit=0 shows the full poster, pages scans by slices of 30, default page cap, city default pitfalls, and eventId city-independence. This goes well beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficiently organized by parameter and includes essential caveats without fluff. The historical note about the old 8-page cap is slightly extra but still adds context to the default.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given five parameters with no schema-level descriptions and an output schema present, the description covers all operational nuances needed to invoke the tool: default city, city_id resolution, pagination and page scaling, eventId purpose, and warn-header hints. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must carry the load. It does: query, city, city_id, pages, and limit are all explained with practical details — mandatory status, default behaviors, fallback logic, and what values mean.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the specific purpose — find a movie in theatrical distribution and its eventId — and immediately links it to the sibling tool cinema_schedule, which makes call routing clear. It is not a tautology and distinguishes the tool from related cinema tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives strong usage guidance: empty query means the whole city poster, city is mandatory, city_id is the fallback, and pages must be raised if a header says unchecked results remain. It clearly explains why to use the tool, although it does not explicitly contrast it with every alternative cinema tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hotel_searchA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful context beyond that by stating that booking via MCP is impossible and that only search/compare is supported, which clarifies the practical scope.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the core search parameters are presented first, followed by the no-booking restriction and a sibling referral. Every sentence adds value and there is no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that the tool has an output schema and read-only annotations, the description provides all needed invocation essentials: query semantics, date format, child age format, and the alternative for deeper hotel details. It is complete for correct selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description compensates by explaining query values, checkin/checkout date format, and children format. It does not explicitly describe adults/limit, but these are inferable from their names and schema defaults, making the parameter guidance strong but not complete.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states a clear verb and resource ('Поиск отелей') and explicitly explains what the query accepts (city, region, or hotel name). It differentiates itself from hotel_info by adding that booking is not possible and that price/cancellation details belong to hotel_info.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly tells the agent this tool is only for finding and comparing hotels, not for booking, and directs specific rate/cancellation lookups to hotel_info(hotel_id, checkin, checkout). This gives a clear when-to-use and when-not-to-use routing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_accountsA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish readOnlyHint, idempotentHint, and no destructive effect, so the description only needs to add behavioral context beyond those. It does so by clarifying that the result is an account-level aggregate view containing balances, cards, and both id and ucid, which is useful context for downstream tool choice.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short, front-loaded, and every phrase earns its place: a summary of what is returned, then the identifier-to-tool mapping, then the pointer to list_cards(). No redundant wording or filler is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only, zero-parameter listing tool with an output schema and annotations covering safety, the description is complete. It names the return content and gives the necessary sibling tool routing hints, so an agent can invoke it confidently without additional implicit requirements.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema description coverage is 100%, so no parameter documentation burden exists. The description still adds semantic context by explaining what identifiers the result contains and how to map them to other tools, which compensates fully for the empty parameter surface.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool returns accounts, balances, associated cards, and the id/ucid identifiers. It explicitly contrasts this with list_cards() by noting that the full card list is provided by list_cards, so an agent can distinguish accounts and card listing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It directly maps returned identifiers to related tools: ucid is for card_limits/card_requisites, id is for card_operations, and list_cards() covers the full card list. This gives an agent actionable selection and follow-up guidance rather than leaving it to infer.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_cardsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable behavioral context: it returns cards from all accounts, marks externally-linked cards, and explains why ucid-related features fail for external cards.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two compact sentences contain the full scope, the key output fields, downstream tool mappings, and the external-car exception. Every clause earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given zero input parameters, a rich annotations set, and an output schema, the description is complete. It explains the most important behavioral edge case (external cards lacking ucid) and would allow an agent to call the tool correctly without any further context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the input schema is empty, so there is nothing to document. The description still adds semantic value by explaining what each output field (id, ucid) is for and how external cards are represented, exceeding the baseline for a zero-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'All cards across all accounts' and specifies exactly what the tool returns: id, ucid, balance, type. It distinguishes itself from list_accounts and list_operations by focusing on cards, including the external-bank card caveat.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives strong usage guidance by explaining that id is for card_operations and ucid is for card_limits/card_requisites, including the important exclusion that external cards have no ucid so those tools won't work for them. It does not explicitly say 'use this when you need a full card overview,' but that context is clearly implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• messenger_fileA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, the description discloses substantial behavior: the default save directory (~/.local/share/tbank-mcp/chat-files/), restrictive permissions (0600), the no-overwrite-unless-flag behavior, the 401 failure mode for cross-conversation file_ids, and a prompt-injection guardrail about treating document content as data. This is rich, actionable context that annotations alone would not convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core action and organized into short topic-focused paragraphs (purpose, local-read follow-up, parameter sourcing, storage semantics, security warning). Each sentence carries practical value; there is no tautology or filler despite the density of detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The definition covers the essential call path — where to get parameters, how the pair must originate, where the file lands, permissions, and overwrite rules — and an output schema exists to document return values, so return structure is outside the description's responsibility. Minor gaps remain, such as error handling for when save_to points to a nonexistent parent directory or what exactly happens when an existing file blocks overwrite, and permission sets or failed downloads are not spelled out.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries the full burden — and it delivers. It explains the exact format of the file_id line, that file_id+conversation_id must come from the same message, that mismatches produce 401, that save_to overrides the default path, and that overwrite=True is required to replace existing files. Every one of the four parameters receives semantic context beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The first sentence gives a concrete verb, resource, and outcome: download a chat attachment (statement, report, certificate) to disk and return a path. It also explicitly differentiates itself from readers/parsers by stating the tool does not parse the file's content, which distinguishes it from messenger_messages and other messaging siblings without needing to open their schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives strong practical context: take file_id and conversation_id from a single messenger_messages() message, warns that mismatched pairs return 401, and tells the agent what to do after the call (read the local file with its own tools). It does not explicitly name sibling alternatives or excluded cases, but the preconditions for correct use are stated precisely, which effectively routes the agent to the right tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• shop_searchA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Описание раскрывает важное дополнительное поведение: серверная пагинация, особое значение limit<=0, печать skuId/pointId/shopId, невозможность добавить в корзину и невозможность оформления заказа. Это далеко выходит за рамки аннотаций readOnlyHint и idempotentHint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Текст организован в короткие абзацы с полезной информацией, без воды: пагинация, limit, карта соответствует ограничению, невозможность оплаты. Каждая фраза приносит пользу и структура логична.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Для тула с 3 параметрами и существующей схемой результата описание покрывает все ключевые операционные предупреждения: пагинация, нестандартное поведение limit, идентификаторы результата, ограничения корзины и отсутствие шага оформления заказа. Ничего критичного для правильного использования не пропущено.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Для 0% покрытия в схеме описание компенсирует: явно объясняет смысл limit и offset, а также неочевидный дефолт (20). Параметр query не описан, но его смысл прямо выводится из названия и назначения тула.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Описание четко указывает действие и объект: «Поиск товаров в маркетплейсе Т-Банка (Город → Шопинг)». Это отличает его от соседних тулов вроде grocery_search и cinema_search, и ясно, что это поиск товаров в маркетплейсе.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Дает ясный контекст использования — поиск товаров в маркетплейсе, а также операционные замечания о пагинации и ограничениях. Не называет явные альтернативы, но контекст «маркетплейс» делает сферу использования однозначной.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• train_searchA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover the read-only, idempotent, and non-destructive nature of the tool. The description adds valuable behavioral context beyond those annotations: station codes must be numeric, there is no station-name resolver, and train_calendar returns an empty response for an invalid station pair.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact yet dense with actionable detail: the operation, the key parameter formats, the known limitation, and the next steps. Every sentence earns its place, and the most critical information is placed early.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description provides enough context for an agent to call the tool correctly, check unknown station pairs, and continue the travel flow with train_seats and train_book. Since an output schema exists, the absence of a verbose return-value explanation is not a gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0% property descriptions, so the description compensates by explaining the critical parameters: origin/destination as numeric station codes with concrete examples, and date as YYYY-MM-DD. The optional parameters limit, adults, and children are not detailed, but their names and defaults are self-explanatory enough for this search context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation as train search (Поиск поездов) with the required search criteria: origin, destination, and date. It also separates this tool from related siblings by naming the follow-up tools train_seats and train_book and the validation tool train_calendar.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly provides workflow guidance: use train_calendar to validate an unknown or unverified station pair, and continue with train_seats then train_book after a search result. This gives an agent concrete routing among sibling tools and clear conditions for using alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• transfer_requisitesA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations say only readOnlyHint=false and destructiveHint=true, and the description goes far beyond them: it reveals the built-in confirmation button, failure behavior without elicitation, pre-send bank validation, NDS '322' default logic, and the semantics of force=True. These are operational traits an agent cannot infer from 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but dense, structured into scannable blocks, and front-loaded with the most critical warning 'REAL MONEY'. There is no filler; each sentence adds concrete operational information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex, destructive 14-parameter money-moving tool, this description is unusually complete: it covers confirmation flow, error cases, default rules, formatting constraints, and even which companion tools to call (payment_qr, payment_receipt, list_accounts). The output schema already exists, so the explicit mention of paymentId is a bonus.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries the full burden, and it mostly does: it manually documents qr, account_number, bik, inn, name, corr_account, bank_name, comment, amount, nds, personal_account, from_account, and force. The only unexplained parameter is kpp, which remains ambiguous for a legal-entity payment tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: a transfer to a legal entity or individual entrepreneur using bank requisites (BIK + account + INN). This clearly distinguishes the tool from siblings like transfer or transfer_sbp_resolve, which use other payment channels.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives strong process guidance: show requisites first, use payment_qr for QR-based payments, and only set force after the user has verified the money did not leave the app. It does not explicitly state when to prefer an alternative tool, but the context of 'transfer to legal entity by requisites' is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tripsA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context: flights, trains, and hotels are aggregated, and the card includes route, status, and insurance. It does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences cover domain, call modes, and the key sibling distinction. The main behavior is front-loaded and no words are wasted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With one optional parameter, rich annotations, and an output schema present, the description covers everything an agent needs: what the tool returns, how the argument changes the result, and how it differs from orders().

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It explains that trip_id switches the response from list to card. It does not specify the id format or provenance, but for one optional parameter this is enough.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description says exactly what the tool returns: with no argument it is the list of trips, with trip_id it is a trip card with route, status, and insurance. It also names the closest sibling orders() and says the difference: it is only trips, not all verticals.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly gives the two call modes (no argument = list, trip_id = card) and an exclusion rule: use orders() when all verticals are needed, use trips only for trips. That is clear when/when-not guidance for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afisha_catalogA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Even though annotations already declare readOnlyHint, idempotentHint, and destructiveHint, the description adds substantial behavioral context: a multi-day range really expands results by including one-off events, cinema sessions are deliberately excluded, concert/theater nearest slots are visible immediately, and query is a local name filter. This goes far beyond the annotation safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the purpose and then uses short, scannable statements about kind, city, dates, and exclusions. Every sentence contributes useful information, but a few points could be merged, and the emphasis on 'Диапазон реально работает' is important but slightly verbose. Overall, it's appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 8-parameter tool with zero schema descriptions, the description explains required fields, date range semantics, accepted kinds, and explicitly plumbs the routing to sibling tools for excluded cases. With an existing output schema to cover return shape, nothing essential is missing for an agent to call this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries the whole burden for parameters. It covers kind values ('кино' | 'концерт' | 'театр'), city/city_id requirement, date details, and query semantics. But limit and pages are not explained, and the exact accepted enum literal for kind is not confirmed against the schema default of 'movie'. Minor gaps in an otherwise strong param description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the tool's purpose: 'Афиша вертикали за ПЕРИОД дат: что идёт с date_from по date_to'. It also distinguishes itself from siblings by naming exclusions — exhibitions go to search_app(screen="afisha") or place_schedule(), and cinema sessions go to cinema_schedule(event_id, date). This makes it clear what this tool does and what it does not do.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use and when-not-to-use guidance: it works for кино, концерт, театр; it does not work for выставки or киносеансы, with specific sibling tools named as alternatives. It also states that city is required and that date format is YYYY-MM-DD. An agent can select this tool without guessing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• confirm_paymentA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations by explaining that this operation continues a stored attempt, does not create a new payment, cannot double-charge, and does not advance state on an incorrect code. It also discloses that the code is never logged and that the final outcome is visible via payment_status(attempt_id). These are highly valuable behavioral details. No contradiction with the annotations was found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense and front-loaded, leading with the purpose and then covering the key behavioral guarantees. There are sentences that could be tightened, but the extra length is justified because it explains a bank payment flow, retry semantics, and side effects. Overall, it is well-organized and efficient for its complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive banking operation, the description covers the trigger condition, the origin and meaning of both parameters, the behavior on wrong and valid codes, the resend path, and the follow-up status-checking tool. With an output schema present, omitted return-value details are not a concern. Nothing critical is missing for an agent to invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 0%, so the description carries the burden of explaining parameters. It does clarify that attempt_id comes from the initiating transfer/pay_bill response and that otp is the SMS/push code. However, the schema marks otp as optional with an empty default while the description says to pass it as a required confirmation code, leaving a minor semantic mismatch. Still, the description compensates meaningfully for the schema gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific and unambiguous purpose: confirming a payment that the bank holds at WAITING_CONFIRMATION via a second factor. It also explicitly differentiates itself from confirm_otp, which handles login confirmation, making the tool distinguishable from the large sibling set. This is a strongly clear and purpose-oriented description.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage guidance is explicit: call this tool when transfer, transfer_requisites, or pay_bill return a “ТРЕБУЕТСЯ ПОДТВЕРЖДЕНИЕ” response. It also states exactly when not to use confirm_otp and provides a full workflow: ask for the SMS/push code, take attempt_id from the previous response, and pass otp. Guidance for retrying, resending, and checking status is also included.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• grocery_order_statusA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and idempotent annotations, the description adds crucial behavioral context: app_id is mandatory despite an empty schema default, and without it the bank returns a raw 400 instead of a meaningful error. It also explains how to derive the app_id from grocery_stores(), which is important operational knowledge.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it starts with the core purpose, then gives the expected usage context, then delivers the mandatory app_id caveat. Every sentence adds unique, useful information with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only order-status tool with an output schema, the description covers the purpose, the condition requiring invocation, the required parameters and their semantic quirks, and the source for deriving the app_id. Nothing essential is missing for correct use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It fully covers both parameters: order_id is the order identifier to query, and app_id is clarified as mandatory, not optional despite the default, and must be taken from grocery_stores() based on the store name from orders().

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the exact action: reconcile the status of a grocery order by orderId via GET /api/grocery/order. It also states why it is useful: checking whether an order was created or paid after an UNKNOWN checkout. This clearly differentiates it from grocery_checkout, grocery_attempts, and grocery_order_cancel.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit guidance: use this after an UNKNOWN checkout to verify whether the order was created or paid on the backend. It does not explicitly name sibling alternatives or explain when not to use them, but the trigger condition is clear enough to route an agent correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• messenger_messagesA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds significant behavioral context beyond the annotations: the bank returns one page, offset counts from the newest messages, truncation is always marked and reports full length, and the output names the next before_id when it reaches the edge of a page. This covers hidden behaviors an agent could not infer from the schema or annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, well-structured, and every sentence adds practical information. The core purpose is stated first, followed by a clear breakdown of pagination parameters and the distinction between local scrolling and cursored page navigation. There is no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's five parameters and complex pagination behavior, the description covers all important usage aspects: page boundaries, offset/limit semantics, before_id cursor, text truncation behavior, and ordering. The presence of an output schema also relieves the description of return-value details. No material gap remains for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries the full burden. It thoroughly explains limit, offset, max_chars, and before_id, including special values, counting direction, and cursor semantics. Only conversation_id is not explicitly annotated, but it is self-evident from the tool name and the required schema field.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as chat history with 'История чата, старые сверху', which an agent can understand and distinguish from sibling tools like messenger_send and messenger_conversations. However, it lacks an explicit verb such as 'get' or 'fetch', so purpose is clear in context rather than stated directly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit pagination guidance: limit and offset scroll within one bank page, while before_id loads an earlier page. It also directly warns that offset here is not the same as offset in messenger_conversations, which is exactly the kind of when/where/when-not guidance an agent needs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• payment_commissionA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite the annotations already declaring readOnly, idempotent, and non-destructive behavior, the description adds crucial non-obvious behaviors: pointerType:ACCOUNT causes the bank to return INVALID_REQUEST_DATA, unfinishedFlag:true means the result is not a valid quotable commission, and the accompanying «комиссия не взимается» message is not a reliable indicator of anything. It also discloses that paymentType is required here even though it must be omitted from the actual transfer.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The key message (preview, no money movement) is front-loaded, and every subsequent line earns its place by covering a real callability or interpretation trap. The embedded JSON template with comments is an efficient way to describe a one-string-parameter API that is actually structured, and nothing extraneous is included.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Because an output schema exists, the description does not need to restate the whole return shape, but it still explains the most important output interpretation rule about unfinishedFlag. It also ties the tool to its upstream dependencies, list_accounts() and transfer_sbp_resolve(), making the description sufficient for correct invocation without digging elsewhere.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only exposes a generic body string with zero description coverage, so the entire parameter semantics burden falls on the description. The description fully compensates by giving the exact JSON body shape: account, moneyAmount, currency, paymentType, provider, and providerFields, including concrete accepted values and the rule to copy providerFields whole from transfer_sbp_resolve().

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with «Предпросмотр комиссии (денег НЕ двигает)» — a specific preview/resource statement that also explicitly disclaims side effects. This distinguishes the tool from execution-style siblings like transfer or pay_bill, so an agent immediately understands this is a quote-only helper and not a funds-moving operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The text clearly frames the tool as a commission preview and notes that money does NOT move, which tells the agent to use it before an actual transfer/payment. It also gives valuable usage context by requiring providerFields to be copied verbatim from a transfer_sbp_resolve() candidate. It does not explicitly name a sibling alternative like transfer for actually executing the payment, 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.

• ticket_qrA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds valuable context beyond annotations: partner-dependent availability (e.g., Ticketland gives neither QR nor PDF), that QR is a payload string not an image, and that missing output is explicitly communicated. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded, starting with the core return value. The statistical detail about 75 afisha orders adds context but is slightly verbose; however it reinforces the behavioral nuance. Overall it is reasonably concise for the information it needs to convey.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a read-only ticket lookup with an output schema, and the description covers essential runtime concerns: what fields are returned, provider variability, relationship to order_details, and the meaning of empty responses. This is sufficient for an agent to select and interpret the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It clarifies that order_id refers to a paid order in the orders feed, that unpaid orders are not present, and how an empty response maps to the absence of a ticket. While it does not spell out the exact format or source of order_id, it provides enough context for correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool returns the ticket details for a paid order: booking code, QR and PDF link. It explicitly distinguishes itself from order_details(), which only returns the booking code, making the purpose specific and differentiating.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance on where the data lives vs. order_details(), which function not to use, and explains the empty-response meaning: 'ticket not yet available' rather than 'order does not exist'. This directly helps an agent decide when to call this tool and how to interpret results.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• concert_scheduleA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: there is no date parameter, all future showings return at once, touring events may have many venues, and the returned slotId/objectId are later used with cinema_seats(). This explains side effects and expected behavior beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is mostly efficient and front-loaded with the core purpose and key outputs. It loses a point because 'Даты в запросе нет — приходит всё будущее сразу' appears twice and could be streamlined. Otherwise, the structure is clear and well-sectioned by parameter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is fully self-contained for correct invocation: all parameters are described, the downstream use with cinema_seats() is identified, sibling routing is given, and the fact that the response is useful despite having no date-filter is clearly explained. An output schema exists, so return-value format is not needed in the text.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Even though schema_description_coverage is 0%, the description compensates fully: it explains event_id's source, kind's allowed values ("концерт" | "театр" | "выставка"), limit semantics (0 = all, default 15), and object_id purpose (filter to one venue). Every parameter is given operational meaning beyond raw schema field names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states a specific action: retrieving scheduled showings for a concert, theater event, or exhibition, including venue, date, slotId, and objectId. It also explicitly distinguishes itself from cinema_schedule by saying movies do not belong here, which differentiates it from likely siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage boundaries: use for concert/theater/exhibition but NOT for cinema, with a direct referral to cinema_schedule(event_id, date). It also explains that event_id comes from search_app(query, screen="afisha"), painting a clear flow of how and when to invoke this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• confirm_passwordA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by disclosing a critical security-sensitive behavior: the password is read from a terminal invisible to the model and must not be handled by the agent. This prevents a misuse that annotations alone could not express. It also clarifies the CLI's role and the intended execution context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short, information-dense sentences are placed in logical order: prohibition first, reasoning second, actionable alternative third. Every sentence earns its place and there is no filler or redundant schema repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter security-sensitive tool, the description is complete. It tells the agent why the tool exists, how the password is handled, when the bank may request it, and exactly what action the agent should take. The existing output schema covers any required return-value detail, so nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only provides a 'password' title with no description, but the tool description adds essential semantic context: this is the account password, it must not be transmitted through the agent, and for the CLI flow it is read directly from the terminal. It does not specify format constraints, but the security-critical meaning of the parameter is clearly conveyed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool is for: password confirmation for first login on a new device, but only for the login_cli.py flow. It also explicitly differentiates it from a chat-accessible tool by warning 'НЕ вызывай напрямую из чата'. The agent knows the tool's role and how it differs from a normal login/confirmation flow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use and when-not-to-use guidance. It says the agent must never call it from chat, explains the password must not pass through the agent, and tells the agent exactly what to do instead: ask the user to run login_cli.py when the bank requests a password on a new-device first login.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• flight_historyA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Although annotations already mark the tool as read-only, idempotent, and non-destructive, the description adds non-obvious behavior not present in annotations: the endpoint responds only under a mobile session with the X-Travel-Context='mb' header, and that header was discovered through live probing rather than passive traffic capture. This is genuinely useful operational context beyond the schema and hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it states the primary purpose, gives the unique lookup rule, and closes with an execution-critical technical note. Every sentence earns its place and no filler is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given zero parameters and an existing output schema, the description is complete. It covers purpose, the exact condition under which to use the tool, the fact that it is the authoritative IATA-code source, and the session/header prerequisite for the call.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero properties and 100% coverage, so there are no parameters to document. The description correctly says nothing about parameters; no additional semantics are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool is and what it offers: flight search history and, critically, the only source of IATA codes paired with city names. This differentiates it from travel sibling tools such as flight_search and flight_offer, and from generic list tools, because it flags a unique lookup responsibility.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit usage rule: if the user names a city in words, look up its code here rather than substituting from memory. It also explains that this endpoint, like flight_search, works through a mobile session via X-Travel-Context='mb', setting clear invocation expectations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_dataA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already indicate read-only, idempotent, non-destructive behavior, and the description substantially enriches the behavioral model: it discloses that invalid sections produce a refusal, that seven sections error without arg rather than returning empty, that obrezanie is unique to statements, and that response truncation is explicitly marked. This goes far beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long because it must enumerate a large section set and special cases, but the structure with bold caveats, a list of arg-requiring sections, and clear exclusions keeps it scannable. Every sentence earns its place; the slight lack of conciseness comes from the inherent breadth of the tool, not from redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's coverage of subtitle data and a large section list, the description is unusually complete: it considers edge cases, error behavior, response truncation, alternative tools, and ambiguous data location issues. The existence of an output schema means return value formats do not need to be encoded in the description. Agents can call this tool correctly with the information provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has no parameter descriptions (0% coverage), and the description fully compensates for this: section is mapped to its full valid value set, arg is refined per section with concrete meanings and examples, days is specified as the statement window with default 30 and no effect on others, and max_chars semantics including the 0 default are explained. This is a model of parameter-level documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a universal getter for bank data organized by sections, and enumerates the supported section values. It also explicitly names sibling tools that handle certain cases (payment_qr, transfer_sbp_resolve, account_requisites), preventing confusion with nearby tools. The scope and purpose are unambiguous despite the breadth of the tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance on when to use this tool and when to prefer alternatives: payment QR goes to payment_qr, recipient search belongs to transfer_sbp_resolve, and own account requisites belong to account_requisites. It also instructs agents to check both invoices and subscription_bills before concluding no unpaid bills exist. Required arg usage and error behavior are precisely defined.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• transferA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the annotations by disclosing that this is a real-money destructive operation that requires a button confirmation, that a client without elicitation will receive a refusal, that recipient resolution can be automatic and may return RECIPIENT_MULTIPLE_BANKS, and that force=True retries only after the user has verified the money did not leave. This is exactly the beyond-schema behavioral context an agent needs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but dense and front-loaded. The critical warning about actual money and button-based confirmation appears first; subsequent sentences handle defaults, edge cases, alternative tools, and failure modes. There is no filler — every sentence contributes operational meaning or a routing decision.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that this is a real-money destructive operation with 9 parameters, the description covers the majority of decision points: when to call, how confirmation works, what defaults and failure states look like, how to route the recipient, what not to use, and how to get the receipt after calling. The description fully compensates for the thin schema and provides critical context beyond the annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description must compensate, and it largely does. It explains the semantics of from_account (default rubbing Current account), to_account, pointer_link_id, bank_member_id, provider variants, description, and force. However, amount and masked_fio receive no explicit treatment, and the valid provider set is only partially implied rather than fully enumerated.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this is an actual money transfer tool: «Перевод (РЕАЛЬНЫЕ ДЕНЬГИ)». It defines the core action, the confirmation mechanism, and explicitly separates itself from related tools like transfer_requisites and transfer_sbp_resolve. It also explains what this tool is not for — legal-entity payments and inner transfers — so an agent can distinguish it from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use and when-not-to-use guidance: call when amount and recipient are known, not before elicitation; use transfer_requisites for legal entities/individual entrepreneurs; do not use for inner-account transfers. It also names the alternative tools (transfer_requisites, payment_qr, transfer_sbp_resolve) and specific conditions that route to them.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cinema_scheduleA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the read-only/idempotent annotations, the description adds several behavioral details: city is required unless object_id is provided, city is passed by name not numeric cityId, limit semantics with default 20, and the warning that schedule data sorted by a mismatched city center can look plausible but be meaningless. It also explains that returned objectId/slotId/eventId values are useful only when passed to cinema_seats() or cinema_book().

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but appropriately so: it documents an 8-parameter, 3-mode endpoint with conditional requirements. It is front-loaded with the core purpose, organized into bullet-style modes, and each line either explains a parameter, a mode, or a critical behavioral constraint. No filler is needed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the endpoint complexity, 0% schema coverage, and conditional parameter logic, the description is complete enough for an agent to choose the correct mode, fill the right parameters, and understand how results are used downstream. An output schema exists, so the description does not need to restate the return structure.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description is the sole documentation for parameters. It compensates by explaining date format, limit semantics including 0, cinema substring matching, around as a time like '17:00', window_min as allowed tolerance in minutes, city-as-name semantics, and the conditional roles of object_id and event_id across all modes.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly defines the tool as cinema showtimes for a date and expands into three explicit modes: entire cinema repertoire, one movie in one cinema, and one movie across a city. It also ties the output to objectId/slotId/eventId, making it distinct from sibling tools like cinema_search and cinema_seats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use each mode: object_id without event_id for a cinema's full day repertoire, event_id + object_id for a single film at a cinema, and event_id + city for a film across a city. It even gives a concrete 'what plays tomorrow in this cinema' scenario and warns against the costly alternative of scanning the city schedule.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• debug_reportA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behaviors beyond the annotations: traces are written automatically on every tool call, can be disabled with TBANK_TRACE=0, and contain no secrets or free text. It also explains how the report sections are intentionally structured, including the deliberate mixing of failures and successes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is comprehensive but disciplined: purpose and exclusions come first, then parameters, then how to interpret the output. Each block adds critical guidance without redundancy, and the structure makes it easy for an agent to extract the relevant information quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a debug tool, the description covers every important aspect: what data is captured, how to request it, why the output is structured, and what to do with the findings. The presence of an output schema further reduces the need to document return format in prose, and the description still explains the report's semantic sections.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Even though schema description coverage is 0%, the description fully defines both parameters: runs determines how many recent server runs to examine with 0 meaning all available, and top controls how many lines are shown per section. This fully compensates for the lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: it reports which tools were called, in what order, what responses were returned, and where agents got stuck. It also explicitly scopes the tool to debugging the MCP itself and contrasts it with banking tasks, which helps distinguish it from the large set of business-oriented sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage context: use this when debugging the MCP, not for banking tasks. It also maps each report section to a diagnostic interpretation, such as repeated identical calls indicating a poor docstring, and transitions diverging from an expected flow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• grocery_checkoutA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond annotations: it discloses that real money move, that a CART_QUANTITY_CONFLICT blocks the order before delivery and before any payment, that checkout makes its own backend-driven preview and only executes after a button confirmation, that the bank recomputes the cart after confirmation, that ambiguous results block retries, and that force only re-shows the confirmation button. This is exactly the behavioral context the agent needs for a destructive, non-idempotent operation. No contradiction with the annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every paragraph corresponds to a distinct decision an agent must make: high-level purpose, mandatory store identity, cart conflict handling, consent UI, dry-run behavior, account selection, multi-step idempotency guard, and failure diagnosis. It is front-loaded with the most critical fact: real money. This length is justified by the destructive nature of the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a payment-completing tool with no parameter descriptions and a large sibling family, the description leaves almost nothing unknown: inputs, side effects, failure modes, retry policy, confirmation requirement, and even Playwright failure remediation. There is no need to describe the return format because an output schema is provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Despite 0% schema description coverage, the description covers all 6 parameters: app_id/point_id are explained as mandatory and sourced from grocery_stores(), dry_run is described as preview without order or payment, account_id is described as overriding the default app payment account, expected_sum is the previously announced sum for reconciliation, and force is scoped to the explicit-no-previous-order case. Without this, an agent would be heavily constrained by these fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as the full grocery checkout flow: 'Полный чекаут: доставка → заказ → оплата'. It ties the tool to grocery context (корзина, grocery_stores, app_id/point_id) and emphasizes 'РЕАЛЬНЫЕ ДЕНЬГИ', which distinguishes it from non-payment grocery tools and from unrelated payment/purchase siblings such as train_pay, ticket_pay, and pay_bill.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage rules: app_id/point_id must come from grocery_stores(), the cart must match the same store, dry_run is for preview, expected_sum verifies a previously quoted total, retries are blocked pending grocery_attempts(), force=True is allowed only after explicit user confirmation, and user consent must be via button rather than text. It directly tells the agent when and how to use the tool and what to do when the invocation is unsafe.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• grocery_order_cancelA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses significant behavioral detail beyond annotations: paid orders are refunded to the debit account, the result must be evaluated from payload.status rather than the outer status, code 605 means already cancelled, and re-reading with app_id may be needed to confirm actual cancellation. This gives the agent a realistic model of the tool's side effects and response evaluation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every statement is functional. It front-loads the purpose, follows with refund and consent handling, then captures important parameter conditions and response semantics. There is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and a small parameter set, the description covers action, outcomes, return-behavior semantics, edge cases like already-cancelled orders, and handling when status is unknown. Even though there is an IS input schema, the description does not need to explain the return shape, but it also gives the critical interpretation of the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description carries the full burden for both parameters. The description explains that order_id is the sole cancellation key, that paymentId/payment_id is specifically NOT required, and that app_id is optional, sourced from grocery_stores()/grocery_attempt(), and improves status accuracy. This fully compensates for the unhelpful JSON schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and resource: cancel a grocery order, whether paid or unpaй. It additionally distinguishes itself from the sibling ticket_cancel by noting paymentId is not needed, and names the relevant order identifier, so an agent can correctly select this tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage direction: use this to cancel a grocery order, it requires consent from the user first, paymentId is not needed unlike ticket_cancel, and app_id is optional but beneficial. It also tells the agent what to do if the tool returns an error: check grocery_order_status or rely on the app, making whens and alternatives clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• grocery_set_cartA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds substantial behavioral detail beyond annotations: absolute quantity semantics, full-cart rewrite behavior, countAvailable rejection with CART_QUANTITY_CONFLICT, no silent clamping, and the post-change cart return value. No contradiction with annotations is present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact for its complexity, well-structured with line breaks, and each sentence adds functional value. It front-loads the key distinction from grocery_add_to_cart and does not repeat schema fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the output schema exists, return-value description is optional, but the tool still explains the post-change contents. Error behavior, full-rewrite mechanics, absolute semantics, and parameter semantics are all covered, making this complete for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has no parameter descriptions, but the description compensates well: items gets a JSON structure with count>0, count=0, and omitted-item semantics, and clear gets an explanation. app_id and point_id are not individually explained but are clear identifiers and optional with defaults.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: modify or remove cart items by overwriting quantities. It explicitly distinguishes itself from grocery_add_to_cart, which increments quantities, so an agent can tell it apart without opening the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains exactly when to use this tool vs grocery_add_to_cart, how count=0 removes items, how items omitted stay untouched, and how clear=True empties the cart. It also clarifies that there is no dedicated delete endpoint, so the tool must rewrite the whole cart.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• payment_providersA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already say readOnlyHint, idempotentHint, and destructiveHint false. The description goes beyond that by revealing the 60-second shared cache with pay_bill, the meaning of pages when searching by provider_id, and the fact that query filters only the current page. It even clarifies that catalog search scans pages; all this makes non-obvious behavior explicit with no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized by usage mode: no arguments, group/query/page, provider_id, and next steps. Every sentence delivers a concrete fact—read-only behavior, pagination, cache behavior, and the single-source-of-truth rule—without filler. It is longer than average but earned by the tool's multi-mode complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a multi-mode catalog tool with neither required parameters nor useful schema descriptions, this covers everything: it lists all modes, explains all five parameters, exposes the caching and search-boundary behavior, and ties into the next step pay_bill. The output schema is present so the description does not need to re-describe return shapes; the context around the tool is fully sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must carry the full meaning, and it does. It defines all five parameters: group is a group name not an id, query is a substring within the current group and page, page is the catalog page number, pages controls how many pages to scan for an id (default 5), and provider_id activates the payment-fields mode. This is more informative than the schema alone and compensates fully for the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description defines the tool as a catalog of payment providers (housing, communications, fines, taxes, internet), says it is read-only, and states concretely what it prints: groups when no arguments, and provider fields when given provider_id. It also positions itself as the only source of the payment form, which clearly distinguishes it from payment-processing siblings like pay_bill.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit start path ('с них и начинай', then payment_providers(group=...)'), explains the difference between group name and id, and provides a typical flow payment_providers(provider_id=...) -> pay_bill(provider_id). It also warns that 'not found' without a group is a search-boundary, not a fact, and directs the agent to get_payment_context when needed. That is precise when-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• payment_receiptA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description significantly enhances the annotations: it discloses the default save location, states that existing files are not overwritten, explains that overwrite=True is required to replace a file, and reveals the 0600 permission behavior. These side effects are not visible in the annotations or schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well organized: action first, then file behavior, then parameter source guidance. Every sentence carries essential operational information; there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 3-parameter tool with an output schema, the description covers default behavior, path customization, overwrite semantics, file permissions, and valid payment_id provenance. Nothing needed to invoke it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate, and it does: save_to is explained as a custom file path, overwrite is explained with its default behavior, and payment_id is precisely grounded in specific response fields and methods. The agent can reliably populate all three parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The first sentence states a specific, concrete action: download a PDF receipt for a payment. The object and format are clear, and the tool is effectively distinguished from broader siblings such as documents or ticket files.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance on where payment_id can and cannot be obtained, naming the five valid sources and explicitly excluding list_operations. This is strong when-to-use and when-not-to-use instruction that prevents a common agent error.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ticket_cancelA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  This is a strong disclosure beyond what annotations provide. The description reveals that the tool first checks the booking and does not even contact the host when cancellation is not available, explains force=True semantics, states that a refused cancellation leaves no state behind, and clarifies that an error does not mean 'still booked'. These are exactly the invisible behaviors an agent needs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured for agent consumption: a one-sentence summary up front, followed by the cancellation model, then parameter semantics, then failure handling. Every sentence adds a distinct actionable fact, and the repeated statement about ticket return and service fee is justified because that repeated notice is also user-facing consent guidance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for a complex, conditional cancellation flow. It covers cancellable and non-cancellable orders, partial cancellation, force behavior, payment_id derivation, unpaid bookings, host refusal behavior, and unknown status handling in an error case. It also points to order_details(), ticket_pay(), and orders() as exact orientation points for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, yet the description compensates fully for all parameters: kind is limited to movie or concert, force changes host call behavior, and payment_id is sourced from the order or ticket_pay() and is absent for unpaid bookings. The core parameter order_id is naturally understood as the ticket order identifier.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Отменить заказ билета'. It immediately distinguishes the domain by stating kind is 'movie' or 'concert', making it clear this is not the generic train, flight, or grocery cancellation tool. It also names the observable outcome — PARTIALLY_CANCELED — which disambiguates what 'cancel' actually does here.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use and when-not-to-use rules: call only when isCancelAvailable=true, do not call when it is false, and do not cancel unpaid bookings because they expire on their own. It also tells the agent to wait for user consent and provides a fallback: if an error occurs, treat the status as unknown, re-check via orders(), and cancel through the app if needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ticket_payA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations that already signal destructive/mutating behavior, the description actually adds critical context: real funds can move, a payment refusal appears without user elicitation, the payment token is available only once, and failed/unconfirmed outcomes must be checked carefully. This is substantial behavioral disclosure that helps the agent act safely.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but not bloated: every sentence carries an actionable instruction or warning. Important safety-relevant points are placed early, and each paragraph addresses a separate concern without unnecessary repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a payment tool of moderate complexity, the description covers the required parameters, the confirmation flow, the failure semantics, the precaution around the token, and the force retry logic. The output schema exists, so the return value is already specified; no essential decision or execution context is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  While the schema provides 0% description coverage, the description fully compensates by explaining where to get order_id, amount, and nfs_payment_token, what account_id defaults to, and what force=True means. Every parameter receives meaningful semantic context beyond its name and type.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: paying for a booked ticket, and highlights that real money is involved. It distinguishes this tool from booking, cancellation, and QR siblings by emphasizing the actual payment step.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit preconditions: use data from cinema_book(), do not ask for textual confirmation, the tool itself shows a confirmation button, and force=True should only be used after verifying no money has left the account. This is strong operational guidance for when and how to invoke the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• train_bookA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description clearly describes the behavioral side effects beyond annotations: no money is withdrawn, seats are held for about 15 minutes, passenger count must match seat count, and child bookings are refused. This gives the agent realistic expectations without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence adds essential value: core behavior, parameter formats, passenger mapping, child restriction, and the separate payment step. It is well-structured and front-loaded with the most important behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers everything an agent needs to call the tool correctly: input semantics, passenger specification, seat/passenger alignment, constraints, and the wasmer next step. The presence of an output schema means return values do not need to be described in the text.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema provides near the parameter descriptions: seats and train_id have no descriptions, and schema coverage is 0%. The description fully compensates by defining train_id as coming from train_search, seats with exact formatted examples like seats="03/10,03/12", and passengers with both "me" and full JSON examples including all needed fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: booking seats on a train. It distinguishes itself from related tools by stating it does not charge money and holds seats for about 15 minutes, and it references train_search and train_seats for the required identifiers and format.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells the agent where to get train_id and seats, how to specify passengers, and how the list order maps to seats. It also explicitly states when not to use it: children under 18 are not supported via MCP and require the app. A clear routing to train_pay for payment is included.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.