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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds useful behavioral context by specifying the returned profile fields: name, email, phone, and timezone. It also clarifies the scope as the token owner's profile. No contradiction with annotations.

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

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

One short, well-structured sentence conveys the resource, scope, and key response fields without unnecessary detail. The essential information is front-loaded and every word earns its place.

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

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

For a zero-parameter read-only profile getter, the description plus annotations are largely sufficient. It clearly identifies the target account and the returned fields. It could be more complete by explicitly distinguishing itself from accounts_list, but this is a minor gap for such a simple tool.

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

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

The tool has zero parameters, so the schema needs no augmentation. The description still adds meaning by indicating what data the returned profile will contain, giving the agent expectations for the response shape.

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

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

The description clearly states the resource and scope: 'Профиль владельца токена' identifies the current authenticated user's account, distinct from account_update and accounts_list. The title 'Моя учётная запись' reinforces the singular, self-scoped nature of the operation.

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

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

Usage is implied through the phrase 'владельца токена' and the sibling tool names, but the description does not explicitly say when to use this tool instead of accounts_list or account_update. No when-to-use or when-not-to-use guidance is provided.

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

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

Annotations already mark destructiveHint=true and idempotentHint=false, but the description adds meaningful behavioral context: the refusal behavior when operations exist, and the rationale that deleting such an account would undermine transaction history. This goes beyond what annotations provide.

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

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

The description is a single well-structured sentence that front-loads the core action and then adds the crucial exception and alternative. Every part earns its place; there is no filler or repetition of schema information.

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

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

For a destructive tool with no output schema, the description covers the main action, the failure condition, the recommended workaround, and the business rationale. Combined with complete schema documentation and relevant annotations, nothing essential is missing 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.

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

Schema description coverage is 100%, so the parameters account and business are already fully documented in the input schema. The description does not add extra parameter-level detail, which is acceptable given full schema coverage, so baseline 3 is appropriate.

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

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

The description opens with a clear verb+resource statement: 'Удаляет счёт' (deletes an account). It immediately distinguishes itself from related operations like accounts_save by explaining the archival alternative, so an agent can tell what this tool is for.

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

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

The description gives explicit guidance: if the account has transactions, deletion will be refused, and in that case the correct alternative is accounts_save with archived=true. This is a concrete when-to-use and when-not-to-use condition with a named sibling alternative.

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

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

Annotations already declare the operation read-only and idempotent, so the description adds useful behavioral context: balance is initial plus actual operations, planned operations are excluded, and currencies must not be mixed. This goes beyond what annotations provide and clarifies output semantics.

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

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

Three short sentences, each earning its place: the first states the resource, the second defines balance calculation, and the third gives a critical currency caveat. No filler or repetition.

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

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

For a simple read-only list tool with two optional parameters and annotations covering safety, the description is nearly complete. It does not describe the response shape or default archived-account behavior, but those gaps are minor given the schema and low complexity.

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

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

Schema description coverage is 100%, so the baseline applies. The description does not add parameter-specific detail beyond the schema; the business and include_archived parameters are already well documented in the schema.

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

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

The description clearly identifies the resource as accounts of a case with current balances, and the tool name accounts_list supplies the missing verb 'list'. It is specific about what is returned but does not explicitly distinguish itself from the sibling account_get.

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

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

The description implies this is the listing tool for accounts and gives important guidance about balance semantics and currency handling, but it never explicitly states when to prefer accounts_list over account_get or accounts_save. No alternatives or exclusions are mentioned.

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

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

Adds significant behavioral context beyond the annotations: currency is fixed per account and determines all operation currencies, the current balance cannot be edited because it is derived from operations, and only the initial balance can be changed. No contradiction with annotations.

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

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

Three compact sentences cover the core semantics without repetition. The create/update distinction is front-loaded, followed by currency and balance rules; no filler.

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

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

For a mutation tool with 11 parameters and no output schema, the description covers the key business rules and mode selection. It leaves details like account_type being required on creation to the schema, which is acceptable given full schema coverage.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the implications of currency and the distinction between initial and current balance, adding real value for the account, currency, and initial_balance parameters.

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

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

States a clear verb and resource: creates a new account when no account is provided and edits an existing one when an account is specified. However, with the sibling account_update also available, it does not explicitly distinguish why one would choose accounts_save over account_update for edits.

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

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

Provides clear conditional usage: omit 'account' to create, specify it to update. This is strong guidance for the tool's two modes, though it does not discuss alternatives such as account_update or any exclusions.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds genuinely useful behavioral context beyond that: PATCH-like partial-update semantics and an explicit scope boundary (password and 2FA excluded). This is the kind of detail an agent needs to call the tool safely and correctly.

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

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

Three short sentences, each earning its place: what the tool changes, how to invoke partial updates, and what it cannot do. The core action is front-loaded and there is no redundant filler or repetition of schema details.

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

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

For a 5-parameter optional-field mutation with annotations present and no output schema, the description covers the essential ground: scope of changes, partial-update behavior, and exclusions. Minor gaps remain — it does not describe the return value on success or error/validation behavior — but these are secondary for an update tool of this simplicity.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by mapping all five parameters to their semantic roles (full_name, phone, birth_date, bio, timezone) and, more importantly, by stating that all fields are individually optional and only passed fields are changed — a semantics the schema alone does not convey.

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

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

The description states a specific verb ('Меняет'), a specific resource ('учётной записи'), and enumerates the exact fields affected (name, phone, birth date, bio, timezone). This clearly distinguishes it from read-only siblings like account_get and from broader save tools like accounts_save.

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

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

The description gives explicit usage semantics: 'Передавайте только те поля, которые нужно изменить: остальные останутся как есть' instructs the agent to perform partial updates. It also provides a clear when-not condition, stating password and 2FA must be changed 'только из панели'. It does not, however, name sibling tools it should be preferred over.

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

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

Annotations already mark the tool destructive, but the description adds important behavioral specifics: the deletion cascades to the budget's discussion and explicitly does not cascade to operations. This gives the agent concrete knowledge of what will be affected beyond the raw destructive flag.

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

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

Two short sentences contain the action, the key side effect, and the key exclusion, with no redundant wording. All sentences contribute information an agent needs before calling the tool.

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

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

For a simple two-parameter delete operation with annotations marking destructiveness, the description plus schema is largely sufficient. The only minor gap is the absence of any statement about return behavior or error conditions, but no output schema exists and the core call semantics are clear.

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

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

Schema description coverage is 100%, so both parameters are already documented; the description adds no parameter-specific detail. Baseline 3 is appropriate because the schema carries the full semantic load.

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

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

The description uses a specific verb ('Удаляет' = deletes) with a clear resource ('бюджет') and explicitly delimits scope by stating the discussion is also deleted while operations are left untouched. This allows the agent to distinguish it from budgets_save and operations_delete.

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

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

The description makes the main use case obvious—delete a budget—and the 'operations are not touched' clause hints that this is not the right tool for deleting operations, but it does not explicitly state when to use it instead of alternatives. Usage guidance remains implied rather than explicit.

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

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

Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds that the result is a card with progress and notification thresholds, but it does not disclose error behavior, required permissions, or what happens if the budget identifier is not found. There is no contradiction with annotations.

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

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

A single short noun phrase carries the key information with no filler and puts the resource first. It is easy to scan and earns its place.

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

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

For a simple read-only getter with fully documented parameters and strong annotations, the description explains the output shape at the right level: a card with progress and notification thresholds. It is slightly vague on what the thresholds mean and does not set expectations for missing budgets, but those are minor for this complexity.

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

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

Schema description coverage is 100%: both budget and business are documented with name-or-id semantics and defaulting for business. The description adds no parameter-level detail, so the baseline of 3 applies.

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

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

The description names the resource (budget card) and the distinguishing content (progress and notification thresholds), which sets it apart from budgets_list's overview. It is clear, but it is a noun phrase rather than an explicit verb+resource statement like 'returns' or 'opens', so it stops short of full clarity.

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

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

The intended usage is implied by the tool name and the sibling budgets_list: get a single detailed budget vs list budgets. However, the description gives no explicit when-to-use guidance, no conditions, and no mention of when to prefer budgets_save or budgets_delete.

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

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

Annotations already declare the call as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context: budgets carry progress, EXPENSE is a cap while INCOME is a target, fact and plan are separate, and forecast equals fact plus future plan. This helps an agent interpret the returned data and does not contradict any annotation.

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

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

Three short sentences, each carrying distinct and necessary information: what is listed, how budget directions work, and the unit of all amounts. The core idea is front-loaded and there is no filler or repetition.

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

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

For a simple read-only list with one optional parameter, the description plus annotations cover the essential interpretation: budgets belong to a business/deal, include progress, and amounts are in rubles. It could be more explicit about response shape and that it lists all budgets, but nothing critical is missing for tool selection.

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

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

The only parameter, business, is fully documented in the input schema with 100% coverage, including the default-business behavior. The description adds no parameter-specific meaning, so the schema-driven baseline of 3 is appropriate.

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

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

The description explains what the budget data means (budgets with progress, EXPENSE vs INCOME semantics, rubles) and identifies the resource, but it never uses a verb like 'list', 'get', or 'returns'. It also does not explicitly differentiate budgets_list from budgets_get, budgets_save, or budgets_delete.

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

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

No guidance is provided about when to use this tool instead of sibling budget tools. The name and readOnlyHint imply read-only listing, but the description does not state this or mention alternatives.

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

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

Beyond the annotations, the description adds a valuable behavioral invariant: exactly one identifier must be filled according to scope_type, with a specific mapping and the OVERALL case requiring none. It also clarifies that limits are in rubles. Annotations already establish that this is a write operation, so the additional context is meaningful.

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

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

The description is compact, front-loaded with the primary create/update behavior, and every sentence carries necessary information. No filler or repetition of schema content.

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

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

Given full schema coverage, the description covers the main upsert behavior and the key scope_type invariant. The only notable omission is whether omitted fields on update are reset or preserved, which is a minor gap for a tool with 11 optional parameters and no output schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds cross-parameter semantics not present in individual schema descriptions: the one-identifier rule tied to scope_type and the ruble denomination for limit_amount. This goes beyond what the schema alone communicates.

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

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

The description clearly states the tool creates or updates a budget and explains exactly how the two modes differ based on the presence of the 'budget' parameter. It is specific about the resource and action, which distinguishes it from sibling tools like budgets_list, budgets_get, and budgets_delete.

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

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

The description gives clear conditional usage: omit budget to create, provide budget to change. It does not explicitly point to sibling tools for alternatives, but the create/update distinction is actionable and not misleading.

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

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

Annotations already mark the tool as destructive and not read-only, but the description adds valuable behavioral context: it cascades to related entities and cannot be undone. This goes beyond the annotation flags and gives the agent a clear picture of consequences.

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

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

Two sentences with no filler. The first sentence states the destructive scope and irreversibility; the second gives the safer alternative. Everything earns its place.

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

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

For a delete tool with two fully documented parameters, required confirmation, and destructive annotations, the description covers all essential operational aspects: scope, irreversibility, and alternative behavior. No output schema is expected for a delete operation, so nothing critical is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description does not add extra meaning about confirm_name beyond the schema, but the baseline of 3 is appropriate because the schema carries the full parameter burden.

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

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

The description uses a specific verb ('Удаляет') and names the resource ('дело'), then enumerates exactly what is deleted: accounts, transactions, counterparties, warehouse, budgets, and documents. It also explicitly contrasts itself with businesses_save with archived=true, making sibling differentiation clear.

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

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

The description provides an explicit when-not-to-use condition: to simply remove the business from the list, use businesses_save with archived=true instead. It also signals that the operation is irreversible, which is essential usage guidance for a destructive action.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond those annotations: sections the user lacks rights to are marked unavailable, while the rest of the card is still shown. This is important for an agent to avoid assuming failure on partial access.

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

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

Two short sentences with no filler. The first sentence front-loads the resource and its key contents; the second adds an important edge-case behavior. Every sentence earns its place.

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

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

For a simple read-only getter with one optional parameter and no output schema, the description adequately covers both the response content and the partial-access behavior. The parameter fallback is documented in the schema, so nothing critical is missing 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.

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

The single optional parameter 'business' is fully described in the input schema (name or ID, with fallback to the default or the only business). The tool description adds no extra parameter semantics, so the baseline 3 for high schema coverage applies.

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

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

Description names the resource (business/file card) and explicitly lists its contents: requisites, the user's role and rights, and accounts with current balances. This makes it clearly distinguishable from siblings like businesses_list (list view) and accounts_list (accounts-only view), and aligns with the tool name businesses_get.

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

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

The description gives clear context for when to use this tool: when a detailed business card with rights and balances is needed, rather than listing or modifying businesses. It does not explicitly name alternatives or exclusions, so it misses the top score, but the usage context is evident.

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

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

Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds a non-obvious behavioral trait beyond those annotations: the returned set is token-limited, and if the token was issued for specific businesses, the panel returns exactly those and does not return the rest.

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

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

The description is one compact sentence that front-loads the key fact (token-accessible cases) and then adds a valuable scoping clarification. Every part earns its place and there is no filler.

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

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

For a simple read-only list operation with one optional parameter, no output schema, and safety annotations already present, the description is sufficient. It explains the important access model and does not leave critical gaps for selecting or invoking the tool.

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

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

Schema description coverage is 100%, so the single optional parameter is already documented in the input schema. The main description adds no extra information about include_archived, so the baseline of 3 applies. The schema text is slightly ambiguous about the default behavior, but that is not compensated by or contradicted in the main description.

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

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

The description clearly identifies the resource ('businesses/cases available to the token owner') and adds the important scope detail that token-scoped cases are returned exactly while others are omitted. It does not use an explicit verb like 'lists' or 'returns', but the name and title make the operation clear.

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

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

The description implies that this tool should be used to see the cases the current token can access, and it explains the token-scoping behavior. However, it never mentions alternatives such as businesses_get for retrieving a single business, nor does it state explicit conditions for preferring this tool over siblings.

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

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

Annotations already indicate this is a mutating operation (readOnlyHint=false) and not destructive. The description adds valuable behavioral context: the caller becomes the owner on creation, updates are partial, and the archived flag can move a business to or from the archive. No contradiction with annotations.

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

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

Two concise sentences present the core create/update condition first, then the partial-update rule. Every word 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.

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

For a 13-parameter mutation with no required fields and no output schema, the description covers the key invocation decisions: create vs update, ownership implication, and partial-update semantics. It does not describe the response format or error conditions, but the schema documents all parameter meanings and annotations cover the mutation profile.

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

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

Schema description coverage is 100%, so a baseline of 3 applies. The description adds cross-parameter guidance: only pass fields that need changing, and the business field determines create-vs-update. This reinforces and extends the schema hints, particularly for partial updates.

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

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

The description states exactly what the tool does: it creates a new business when no business identifier is provided and updates an existing one when it is. This clearly differentiates it from sibling tools like businesses_list, businesses_get, and businesses_delete by focusing on create/update behavior.

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

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

It provides explicit conditions: omit the business field to create, include it to update, and send only the fields to change. It does not explicitly mention alternatives such as businesses_delete for deletion, but the create/update distinction is clearly actionable.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false. The description adds meaningful behavior beyond annotations: operations survive but lose the project reference, and subprojects are deleted along with the project. This is valuable cascade information not present in the structured metadata.

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

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

Two short sentences: the first states the core action, the second describes the consequences. There is no filler, repetition, or unnecessary elaboration.

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

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

For a simple destructive tool with a fully documented schema, the description supplies the critical semantic details: what is deleted, what remains, and how subprojects are handled. Nothing essential for correct invocation appears missing.

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

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

The schema provides descriptions for all parameters, covering both 'business' and 'category' at 100%. The description does not add additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description states a concrete action with a clear resource: 'Удаляет проект' (deletes a project). It immediately clarifies scope and side effects, distinguishing it from related tools such as categories_save.

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

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

Usage is reasonably implied: this is the deletion operation for projects, and the description notes that operations referencing the project are preserved. However, it does not explicitly contrast with alternatives like categories_save or state conditions for non-use, so the agent must infer some usage guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful domain context: categories are projects and the hierarchy is strictly single-level. However, it discloses no additional behavioral details like response shape or pagination.

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

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

Two short sentences carry the essential domain mapping and hierarchy constraint with no filler. The naming clarification is front-loaded and every clause earns its place.

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

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

For a simple read-only list operation with two optional, well-documented parameters and robust annotations, the description is nearly complete. The missing output-schema detail is a minor gap because the tool name and domain context make the return intent obvious.

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

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

Schema description coverage is 100% for both parameters, so the schema already documents business and include_archived. The description adds no parameter-specific meaning, which makes the baseline of 3 appropriate.

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

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

The description clearly identifies the resource ('Проекты дела' mapped to API 'categories') and adds a useful hierarchy note. It does not explicitly state the 'list' verb, relying on the tool name, and it does not contrast with categories_save/categories_delete, but the resource and intent are clear enough.

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

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

No usage guidance is provided. The description never states when to use this tool versus alternatives such as categories_save or categories_delete, and it gives no exclusions or conditions. Usage is only implied by the tool name and title.

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

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

Annotations already mark the tool as writable and non-destructive, so the description adds useful behavioral context: upsert semantics, the top-level-parent restriction, and the panel's rejection of invalid subprojects. It does not describe response format or partial-update effects, but there is no contradiction with annotations.

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

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

Three concise, front-loaded sentences. Each sentence carries operational value, and the repeated enum values do not create bloated text.

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

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

The description plus schema cover the core create/update semantics and parent constraint. However, the format of the category parameter (name vs id) is not specified, and partial-update behavior for omitted fields is not explained. For a tool with 7 optional parameters and no output schema, this leaves some ambiguity.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining that omitting category creates and supplying it modifies, and by adding the rule that parent_id must refer to a top-level project. Other parameters are already documented well in the schema.

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

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

The title and first sentence state an exact operation: create or update a project, with the category parameter deciding which mode is used. This clearly distinguishes the tool from categories_list and categories_delete by behavior.

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

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

The description explicitly defines how to choose between creation and modification: omit the project to create, provide it to change. It also states a hard constraint on parent_id. It does not explicitly name alternative tools, but the create/update rule is strong routing guidance for a save tool.

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

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

Annotations already declare destructiveHint=true, but the description adds meaningful behavior beyond that: deletion will be refused if references exist, and archiving is the fallback. This helps the agent anticipate failure and choose the correct path. No contradiction with annotations.

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

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

Two sentences, no filler. The primary operation is stated first, and the critical exception and workaround are packed into the second sentence without redundancy.

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

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

For a simple two-parameter destructive action, this description is complete: it states the operation, the failure condition, and the recommended alternative. The output schema is absent, but the failure behavior is disclosed, which is the main risk for this tool.

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

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

Schema description coverage is 100%, and both parameters already have clear descriptions in the schema. The tool description does not need to add parameter details, so the baseline of 3 is appropriate.

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

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

The description begins with a clear verb and resource: 'Удаляет контрагента' (deletes a counterparty). It also distinguishes this tool from counterparties_save by describing the conditional refusal and the archiving workaround, so an agent can distinguish them.

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

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

The description explicitly states when deletion works, when it will be refused (if operations or documents reference the counterparty), and names the exact alternative: counterparties_save with archived=true. This is strong, actionable routing guidance.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, and the description does not contradict them. However, it adds no behavioral information beyond those annotations: it gives domain categories rather than disclosing return behavior, filtering semantics, or any side effects.

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

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

The text is very short and easy to scan, which is a positive, but it is an under-specified fragment rather than a complete operational description. It uses its limited space for definitional content and omits the core action and usage context that an agent needs.

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

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

For a read-only list tool with no output schema, the description should at least state that it returns the list of counterparties and how the optional 'business' parameter scopes the result. The current description is too thin, forcing an agent to rely on the tool name and parameter schema to infer what the tool actually does.

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

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

Schema description coverage is 100%, so each parameter is already documented in the input schema. The tool description only repeats the 'дела' context already covered by the 'business' parameter and adds no new parameter-level meaning, so the baseline score of 3 applies.

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

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

The description 'Контрагенты дела: покупатели, поставщики, сотрудники, госорганы' is a noun phrase defining what counterparties are, not what the tool does. It lacks a verb such as 'list', 'return', or 'show', and mostly restates the resource named in the title while adding category examples rather than an operational purpose.

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

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

No guidance is given about when to use this tool versus sibling tools like counterparties_save, counterparties_delete, or counterparty_groups. The only contextual hint is the 'дела' scope, which is already present in the 'business' parameter description, so it does not help an agent choose between alternatives.

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

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

Annotations already indicate this is not read-only and not destructive. The description adds the important behavioral detail that the tool acts as an upsert and supports partial updates, which goes beyond the annotations. No annotation contradiction is present.

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

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

The description is two short sentences with no redundant wording. The most important behavior, create versus update, is front-loaded, and the instruction about passing only changed fields is immediately useful.

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

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

The description covers the core upsert behavior and partial updates, and the schema documents every parameter. However, there is no output schema and the description does not mention return values, required fields for creation, validation, or error behavior, leaving moderate gaps for an 18-parameter tool.

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

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

The input schema has 100% description coverage, so all 18 parameters are already documented individually. The tool description only reiterates the counterparty selector behavior and the partial-update principle without adding new parameter-level meaning, which matches the baseline of 3.

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

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

The description clearly states the tool creates a new counterparty when no counterparty is specified and modifies an existing one when it is. It uses a specific verb and resource, and the create/update distinction separates it from sibling tools like counterparties_list and counterparties_delete.

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

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

The description gives clear usage context: omit counterparty to create, include it to update, and pass only fields that should change. It does not explicitly name alternatives or state when not to use the tool, so it stops short of a 5.

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

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

Annotations already communicate read-only, idempotent, and non-destructive behavior, and the description adds the conceptual context that counterparties are organized into groups per case. It does not disclose additional behavioral traits like response shape or completeness, but the annotation coverage lowers the burden.

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

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

The one-sentence description is compact and leads with the core concept 'Группы'. It contains no redundant words, though it is an elliptical noun phrase rather than a complete sentence, which slightly reduces structural clarity.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description conveys enough about what is returned: the groups by which a case's counterparties are arranged. Parameter defaults are covered by the schema, and nothing critical is missing for a basic call.

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

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

The input schema fully documents the single optional business parameter with 100% coverage, including default behavior when omitted. The description adds no parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description identifies the exact resource: groups into which a case's counterparties are classified, which is distinct from sibling tools like counterparties_list. It is clear but lacks an explicit verb such as 'returns' or 'lists', so it does not fully meet the specific-verb standard.

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

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

No guidance is given about when to call this tool versus alternatives such as counterparties_list or warehouse_groups. The only usage hint is the optional business parameter in the schema, not in the description, so an agent receives no explicit routing information.

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

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

Annotations already indicate this is not read-only and not idempotent. The description adds useful behavioral detail: it saves a ready .docx and states that the panel rejects required fields without values. No contradiction with annotations.

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

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

Two focused sentences: the first states the core operation and result, the second explains value mapping and validation. No filler or redundant restatement of the schema.

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

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

The description covers the essential invocation details: purpose, parameter semantics, key source, validation, and output artifact. With no output schema, a note on the exact return value would strengthen it, but it remains sufficient for correct invocation.

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

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

Schema has 100% parameter description coverage, so the baseline is 3. The description adds value by specifying that field keys come from templates_get and by explaining required-field validation behavior, which is not fully captured in the schema.

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

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

Description states a specific action: 'Подставляет значения в шаблон и сохраняет готовый .docx для контрагента.' This clearly identifies the verb, resource, and output, and distinguishes it from siblings like documents_send and templates_get.

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

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

Provides clear workflow context by instructing 'ключи берите из templates_get', which tells the agent where to obtain valid field keys. It does not explicitly contrast with documents_send or documents_list, but the intended use case is evident.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive, so the description does not need to restate safety. It adds useful context about document scope and signing status, but does not disclose potential limitations such as pagination, ordering, or permissions beyond what annotations already imply.

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

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

The description is one short, focused sentence with no filler. The important elements—one counterparty, collected documents, and signing status—are immediately visible and easy to parse.

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

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

This is a simple read-only list with two parameters and no output schema, and the description explains the core purpose. However, 'collected documents' is not defined, and since there is no output schema, a bit more detail about what the response contains beyond signing status would improve completeness.

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

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

Schema description coverage is 100%, so the schema already explains counterparty_id and business adequately. The description adds little beyond the schema, mainly reinforcing that the scope is one counterparty, so the baseline score of 3 is appropriate.

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

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

The description names the resource (documents of one counterparty) and the key attribute (signing status), which goes beyond the title. However, it uses a noun phrase rather than an explicit verb like 'list' or 'get', and 'collected documents' is slightly ambiguous, so it is clear but not perfectly specified.

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

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

No guidance is provided on when to use this tool instead of sibling tools such as documents_generate or documents_send. The counterparty focus implies a use case, but there are no explicit conditions, exclusions, or alternative tool mentions.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=false, but the description goes further by stating the concrete irreversible effect: 'письмо уходит получателю, и отозвать его одним вызовом нельзя'. It also adds the integration prerequisite, which is not structurally encoded elsewhere.

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

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

Two sentences with no filler. The first sentence states the action, and the second adds the most important behavioral warnings. Information is front-loaded and every clause earns its place.

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

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

The description covers the tool's purpose, prerequisite, and irreversible side effect, which is strong for a relatively simple action tool. It does not describe the return/confirmation behavior, but no output schema exists and the flat parameter set is fully documented, so this is a minor gap.

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

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

The input schema has 100% description coverage, with all six parameters documented. The description itself adds no parameter-level detail, so it relies on the schema for parameter semantics. This matches the baseline for full schema coverage.

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

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

The description clearly states a specific action and resource: 'Отправляет документ на подписание через Подпислон'. It is easily distinguished from sibling tools like documents_list or documents_generate, and the irreversibility note reinforces what the tool uniquely does.

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

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

The description gives clear context: use this to send a document for signature through Podpislon, and it requires a configured integration in the deal. It does not explicitly name alternative tools or when-not-to-use it, but the precondition and irreversible effect provide practical guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds the members.view permission requirement, a behavioral/access constraint not present in annotations. No other behavioral traits such as response shape or error handling are disclosed, so 3 is appropriate.

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

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

The description is a single, front-loaded phrase stating the core purpose, followed by a one-clause permission note. Every word adds information and there is no redundancy.

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

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

For a simple read-only list operation with one optional parameter, the description and schema together cover the essential information: what is returned (members and roles), the required permission, and parameter semantics. The lack of an output schema is mitigated by the description's clear indication of the returned content, though a more explicit mention of the response structure could push it to 5.

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

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

The only parameter, business, is 100% documented in the input schema, including default-resolution behavior. The description does not add any parameter-level detail beyond the schema, so the baseline of 3 applies.

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

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

The description identifies the resource (case members) and the attribute (role), which is specific and distinguishes this tool from siblings such as businesses_list or accounts_list. However, it lacks an explicit action verb like 'list' or 'returns', relying on the tool name to convey the operation.

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

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

The description implies usage when you need case participants and their roles, and states a prerequisite permission (members.view). However, it does not explicitly mention when-not-to-use or name alternative tools, leaving the selection guidance mostly to inference.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds specific notification types but does not disclose additional behaviors like pagination or response format. With annotations covering the safety profile, the description provides moderate added value.

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

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

The description is a single concise sentence, front-loaded with the subject and specific notification types. No unnecessary words or repetition; it is maximally efficient.

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

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

For a simple list tool with two parameters and no output schema, the description is adequate. It states what notifications are included, and the schema covers pagination and filtering. Annotations handle the read-only nature, so nothing critical is missing.

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

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

Both parameters (limit and unread_only) are fully described in the schema with clear meaning and defaults. The description adds no extra semantic detail beyond the schema, which already carries the heavy lifting.

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

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

The description clearly states the resource (account notifications) and enumerates the specific categories (invitations, role changes, budget thresholds, bank payments). The verb 'list' is implicit in the tool name and the description's scope, and it distinguishes from siblings like notifications_read which likely marks as read.

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

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

Usage is implied by the description, but there is no explicit guidance on when to use this tool versus alternatives such as notifications_read or other list tools. The description gives context on what it returns but does not state exclusionary conditions.

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

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

The description clearly states the behavioral effect: changing one notification's read state. This aligns with annotations such as readOnlyHint=false and is not contradictory, but it adds little beyond the basic action and does not cover side effects, return behavior, or idempotency nuances.

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

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

The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to stating the action and scope.

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

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

For a one-parameter status mutation with annotations and a well-documented schema, this description is nearly sufficient for correct invocation. It could be slightly more complete by noting what the caller should expect after the operation, such as whether the notification disappears from the unread list.

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

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

Schema description coverage is 100%, and the notification_id parameter is already documented as coming from notifications_list. The main description only adds the singular scope 'one notification,' which provides minimal extra meaning beyond the schema.

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

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

The description uses a specific verb (Помечает) and resource (уведомление) with a clear outcome (прочитанным), so the tool's purpose is unambiguous. It is distinguishable from siblings like notifications_list by the singular mutation action, though it mostly paraphrases the title without adding additional context.

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

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

Usage context is implied by the action itself: use this tool when a notification should be marked as read. However, the description does not explicitly state when to use it versus alternatives, and the only extra pointer is the parameter description saying notification_id comes from notifications_list.

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

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds useful scope context: only actual operations and amounts in rubles. It does not describe aggregation details, response shape, or edge cases, but the safety profile is already covered by annotations.

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

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

The description is a single compact sentence with no filler. Every part conveys meaningful information: period, dimensions, income/expense direction, actual operations, and currency.

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

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

For a report tool with no output schema, the description does not explain the exact response structure or how the two breakdown dimensions relate to each other. It is sufficient for basic tool selection but leaves some inference needed for an agent about the returned grouping shape.

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

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

Input schema coverage is 100%, with date_from, date_to, and business all described directly in the schema. The tool description adds no parameter-level meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description clearly states that the tool returns monetary amounts for a period broken down by projects and counterparties, with income and expense direction. It does not use an explicit verb like 'returns' or 'lists', but the meaning is unambiguous and distinct from simple list/detail operations tools.

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

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

The description implies the tool is for viewing income/expense breakdowns by projects and counterparties and emphasizes that only actual operations are included. However, it does not explicitly say when to choose this tool over related siblings like operations_stats, operations_list, or receivables_summary, nor does it provide exclusions.

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

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

Annotations already show readOnlyHint=false, and the description adds meaningful behavioral detail beyond that: the tool supports both reading and writing, and system-generated change records are read-only. This helps the agent understand edge cases 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.

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

The description is two sentences with no filler. The primary function is stated first, and the key caveat about system entries follows immediately. Every sentence earns its place.

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

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

For a simple three-parameter tool with clear schema descriptions, the description covers the essential behavior and an important restriction. It does not describe the return format or side effects of adding a comment, but given the tool's simplicity and annotation coverage, this is not a significant gap.

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

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

Schema description coverage is 100%, and the individual parameter descriptions already explain text, business, and operation_id. The main description does not add significant parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific action: reading an operation's correspondence or adding a comment to it. This clearly identifies the tool's resource and distinguishes it from sibling tools like operations_get or operations_save, even without naming them.

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

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

The description provides clear context for when to use the tool: to read or comment on an operation discussion. It also adds an explicit exclusion: system entries about changes are auto-written and can only be read, so they should not be commented on. It does not name alternatives, but context is sufficient.

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

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

The description adds meaningful behavioral context beyond the annotations: it affects balances and statistics, and related warehouse items are written off. It clarifies that despite destructiveHint=false, the write-off is an intended business consequence. However, it does not warn about the non-idempotent risk of double-confirmation even though idempotentHint=false, leaving a small transparency gap.

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

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

Two sentences with no filler: the core action and consequences are front-loaded, followed by a concise usage guardrail. Every sentence earns its place, and the temporal warning is placed efficiently at the end.

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

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

For a state-changing tool with moderate complexity (2 params, no output schema), the description covers the essential semantics: what changes, what side effects occur, and when not to call it. Minor gaps are the lack of any indication of return value/confirmation behavior and no idempotency warning, but the core is well covered.

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

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

Schema coverage is 100%, so the schema fully documents both parameters. The description references 'плановая операция' which maps to operation_id, but adds no parameter-specific detail beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description uses a specific transformative verb ('Переводит плановую операцию в фактическую') and clearly identifies the resource: planned operations. It distinguishes itself from siblings like operations_save, operations_delete, and operations_settle by specifying the unique state transition (planned → actual) and its consequences.

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

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

The description gives an explicit when-not instruction: future plans should not be confirmed until their date arrives. This is clear contextual guidance, though it does not explicitly name a sibling alternative for those future-plan cases, so it stops short of full alternative routing.

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

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

Annotations already mark the tool as destructive, but the description adds substantial context beyond that: it explicitly states the operation cannot be undone, that account balances will be recalculated immediately, and that if the operation is part of a recurring series, only that one instance is deleted. This gives the agent a much clearer picture of side effects and behavioral nuances.

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

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

Three concise sentences, each carrying meaningful information: the action, the irreversibility and recalculation side effect, and the recurring-series behavior. The core action is front-loaded, and there is no filler or redundant restating of the title or schema.

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

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

For a destructive operation with two parameters and no output schema, the description is complete enough for safe invocation. It covers what happens, what cannot be undone, what side effects occur, and a subtle edge case involving recurring series. The remaining details, such as exact response format, are not essential given the tool's simplicity and the schema's completeness.

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

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

The input schema already provides 100% parameter coverage with descriptions for both 'operation_id' and 'business'. The description does not add additional parameter-level meaning, so the baseline score of 3 is appropriate. It does slightly reinforce that 'operation_id' targets a single operation, but it does not clarify formats or defaults beyond the schema.

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

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

The description starts with 'Удаляет операцию', a direct verb plus resource that clearly states the tool's function. It is distinct from sibling tools like operations_list, operations_save, or operations_confirm because it explicitly says 'deletes'. The scope is unambiguous: the tool deletes an operation.

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

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

Usage is implied by the verb and resource: use this tool when you need to delete an operation. However, there is no explicit guidance about when to choose this over alternatives, nor any stated preconditions or caveats such as requiring confirmation before deleting. The information about irreversibility helps, but it is not phrased as usage guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail beyond annotations: the calculation method (opening balance plus daily movement), the inclusion of planned operations, and that amounts are in rubles.

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

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

The description is three short, information-dense sentences. It front-loads the core question, immediately contrasts with statistics, and ends with the output unit. Every sentence earns its place without redundancy.

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

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

Given there is no output schema, the description provides enough context by stating the output is in rubles and relates to daily movement. It could be more explicit about the exact return shape, but for a read-only forecast tool with rich annotations and fully documented parameters, the description is sufficiently complete.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description does not add parameter-specific semantics beyond the general date-based movement concept, which is appropriate for the baseline of 3 when the schema carries the detail.

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

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

The description clearly states what the tool does: it forecasts how the total balance will change given planned operations, starting from the opening balance and adding daily movement. It explicitly contrasts itself with statistics by noting that the plan is included, which helps distinguish it from sibling tools like operations_stats.

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

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

The phrase 'В отличие от статистики, план сюда входит' provides a clear context for when this tool is appropriate: when planned operations should be included in the balance forecast. It does not explicitly name an alternative tool or state exclusions, but the contrast with statistics is sufficient guidance for an agent.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds value by enumerating the data domains returned, but does not describe response shape, pagination, or error behavior. No contradiction with annotations.

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

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

A single, front-loaded sentence conveys the purpose and contents without redundancy. Every word adds useful information.

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

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

For a simple read-only tool with two well-documented parameters and no output schema, the description adequately lists what the returned card contains. It is complete enough for an agent to understand the tool's scope, though it lacks explicit sibling differentiation.

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

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

Schema description coverage is 100%, so both operation_id and business are already documented in the schema. The description adds no parameter-specific meaning beyond identifying the operation card context, staying at the baseline.

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

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

Description clearly states the resource ('operation card') and the full scope of what is returned: amounts, accounts, links, warehouse positions, and memo. It is distinguishable from list/save/delete siblings, though it does not explicitly name a sibling alternative.

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

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

The description implies this is for retrieving a full operation card but gives no explicit guidance on when to use it versus operations_list or other operation-related tools. No alternatives or exclusion criteria are mentioned.

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

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

Annotations already mark the call as read-only, idempotent, and non-destructive. The description adds a valuable runtime behavior: the response is paginated and tells which next page to request. 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.

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

Three sentences with no filler: scope and filters, pagination behavior, and status enum meanings. Information is front-loaded and each sentence earns its place.

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

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

With the schema covering parameter details and annotations covering safety, the description supplies the missing runtime behavior (pagination). For a filtered-list tool this is sufficient for selection and invocation, even without an output schema.

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

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

Schema description coverage is 100%, so the schema fully documents all 12 parameters. The description mentions the filter dimensions and status meanings but adds no semantics beyond the schema.

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

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

The description clearly identifies a list of operations ('Операции дела') and enumerates the available filters (dates, type, account, project, counterparty, status), so an agent can distinguish it from operations_get/save/delete. However, it relies on the title for the 'list' verb and does not explicitly contrast a sibling like operations_get.

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

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

The intended use as a paginated list with many filters is implied, but there is no explicit 'when to use' or 'when not to use' guidance, nor a named alternative. An agent must infer that operations_get is for a single operation and operations_stats for aggregates.

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

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

Annotations only indicate flags like readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context: operation currency inherits from account currency, missing target_amount for cross-currency transfers causes incorrect balances, and planned operations are excluded from balances/statistics but included in forecasts. This goes beyond annotation signals and helps the agent anticipate side effects.

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

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

Three compact sentences deliver the core create/update distinction, currency inheritance rule, transfer requirements, and planned-operation behavior. Critical information is front-loaded and every sentence carries meaningful guidance without fluff.

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

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

For a 17-parameter tool with no output schema, the description covers the most complex cross-field rules: conditional required parameters, currency logic, and planned-operation semantics. Recurrence parameters are left to the schema, which is acceptable given their explicit self-contained descriptions. Minor gaps remain around response behavior and idempotency, but the essentials are present.

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

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

Schema coverage is 100%, so the baseline is 3. The description enriches several parameters: operation_id distinguishes create vs update, target_account_id and target_amount gain conditional transfer semantics, and is_planned gains balance/forecast implications. This adds real value beyond the schema's per-field descriptions.

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

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

The description clearly states a dual purpose: creates an operation without operation_id and modifies it with operation_id. It also distinguishes itself from sibling tools like operations_delete and operations_confirm by explaining the create/update semantics and planned-operation confirmation flow.

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

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

The description gives clear conditional guidance: for TRANSFER, target_account_id is mandatory; when currencies differ, target_amount must be provided. It also tells the agent that planned operations are confirmed via operations_confirm, which is a useful alternative reference. It does not explicitly enumerate when to avoid using this tool, but the conditional rules effectively scope its usage.

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

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

The description discloses important side effects beyond annotations: full payment confirms the operation, partial payment creates a new actual payment operation and reduces the planned balance, warehouse operations cannot be partially settled without hanging stock, and currency must match. This gives the agent a clear model of the tool's behavior and consequences.

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

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

The description is compact and front-loaded: primary purpose first, then behavioral rules, then constraints. Every sentence adds necessary operational information, and there is no filler or redundancy.

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

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

For a financial mutation tool with no output schema, the description covers the key behaviors, constraints, and side effects needed to invoke it correctly. Minor gaps remain: it does not state what happens on overpayment, whether multiple partial payments are allowed, or what the response looks like, but these are secondary to the core usage.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: 'amount' is explained as full vs partial, 'operation_id' is clarified as the planned operation/debt, and 'account_id' gets the currency-matching constraint. This goes beyond the schema without needing to restate every parameter.

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

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

The description opens with 'Оплата по плановой операции' — a specific verb ('pay') and resource ('planned operation') — and then clarifies the tool's role as settling debt. It distinguishes itself from the sibling operations_confirm by stating that full payment equals confirmation, so an agent can tell it apart.

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

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

The description gives clear context for when to use this tool: for paying planned operations, with full payment acting as confirmation and partial payment reducing the planned balance. It also provides exclusions and constraints: warehouse-item operations can only be settled fully, and the payment account must match the operation's currency. It does not explicitly name alternative sibling tools, but the behavioral guidance is strong.

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

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

Annotations already declare the tool read-only and idempotent. The description adds meaningful behavioral detail beyond annotations: transfers are excluded because they don't change total amounts, and all sums are converted to rubles at the CBR exchange rate. This gives the agent a clear model of the tool's data treatment.

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

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

Three short sentences deliver the core purpose, data scope, exclusions, and currency normalization. Every sentence earns its place, and the main function is front-loaded in the first sentence.

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

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

For a read-only statistics tool with 100% schema coverage and no output schema, the description sufficiently conveys the output concept (daily income/expenses) and important data semantics. It does not detail the exact response structure, but the annotations and simple return concept make this acceptable.

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

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

Schema description coverage is 100%, with all three parameters already documented in the schema. The description adds no new parameter-specific information, but such compensation is unnecessary given full schema coverage. Baseline 3 is appropriate.

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

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

The description clearly states the tool's resource and output: 'Доходы и расходы по дням за период' (income and expenses by day for a period). It also adds scope by restricting to actual operations and excluding transfers. It does not explicitly differentiate from sibling tools like operations_list or operations_breakdowns, so it misses the top score.

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

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

The description gives clear context about what data is included (actual operations only) and excluded (transfers), and implies this is the tool for daily income/expense statistics. However, it does not explicitly state when to choose this tool over alternatives or mention any when-not conditions, so usage guidance is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, covering the safety profile. The description adds useful context about the output composition (planned operations, amounts, terms) but does not disclose additional behavioral traits such as pagination or data freshness. No contradiction with annotations.

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

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

Two compact sentences: the first delivers the core purpose and content, the second gives an actionable cross-reference to operations_settle. There is no filler or redundancy.

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

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

For a simple read-only detail tool, the description is complete: it identifies the selected counterparty, states what the response contains, and routes the settling action to the correct sibling. The input schema and annotations cover parameters and safety behavior, so no critical information is missing despite the absence of an output schema.

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

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

Schema description coverage is 100%, so counterparty_id and business are already documented, including the default-business behavior. The description does not add further parameter-level details, so it stays at the baseline.

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

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

The description names a specific action and resource: it details a debt for a single counterparty and shows the planned operations, amounts, and terms that compose it. It also positions itself as the read-side counterpart to operations_settle, which separates it from the mutation sibling.

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

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

It explicitly states when this tool fits (one counterparty debt detail) and gives a when-not instruction: to settle a specific line, use operations_settle. This is clear routing for an agent choosing between tools.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful computation semantics: aging is calculated from the transaction date and amounts are normalized to rubles. This goes beyond annotations and helps interpret results.

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

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

The description is compact and front-loaded, immediately conveying the core output (who owes whom) and then the aging breakdown and currency normalization. No filler or redundant statements.

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

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

For a read-only tool with one optional parameter and no output schema, the description adequately conveys the result shape: counterparty direction, aging categories, and currency normalization. Missing details like output formatting are minor given the tool's simplicity.

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

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

Schema description coverage is 100% and already fully documents the optional business parameter, including default behavior. The tool description adds no parameter-specific detail, so the baseline score of 3 is appropriate.

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

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

The description clearly states what the tool produces: an accounts receivable/payable summary with aging buckets (not due, 1–30, 31–60, 61–90, 90+ days). It is specific enough to be distinguished from the sibling receivables_counterparty by its aging breakdown, though it lacks an explicit action verb.

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

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

The intended use case is implied by the description, but there is no explicit guidance about when to choose this tool over alternatives such as receivables_counterparty or operations_stats. No exclusions or alternative conditions are stated.

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

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

Annotations already mark the tool as read-only, idempotent, open-world, and non-destructive. The description adds value beyond those annotations by explaining what the tool returns and why it matters before generation, 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.

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

The description is two short, purposeful sentences. The core purpose is front-loaded, and the usage hint is directly actionable with no filler.

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

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

For a simple read-only tool with two well-documented parameters, the description is largely sufficient: it states the output content and when to call the tool. It does not describe the exact output format or error/empty cases, but given the annotations and schema, this is a minor gap.

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

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

Schema description coverage is 100%, so both parameters (business and template) are already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides.

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

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

The description clearly states the tool's result: it returns which fields a template expects and what those fields look like. It ties the tool to documents_generate, though it does not explicitly contrast it with templates_list.

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

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

The description gives an explicit usage trigger: 'Смотрите сюда перед documents_generate' and explains the practical consequence about required fields. It does not mention when not to use this tool or name alternative tools, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds no behavioral detail such as pagination, ordering, default business resolution, or what happens when no templates exist. It only adds domain context about .docx templates and counterparty documents, which is not a behavioral disclosure beyond annotations.

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

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

The description is a single short sentence with no redundant words. It front-loads the core resource and adds one useful piece of context about how the templates are used, making it highly efficient.

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

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

The tool is simple, the parameter is fully documented, and annotations cover safety and world behavior. However, the description does not explicitly state that this tool returns a list of templates or when to prefer it over templates_get, so an agent must rely on the tool name for part of the operational meaning.

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

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

Schema description coverage is 100%, so the single 'business' parameter is fully documented in the schema. The tool description does not mention the parameter, but the schema already explains that omitting it uses the default case or the sole case. This meets the baseline without requiring additional description.

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

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

The description identifies the resource clearly — 'Шаблоны .docx дела' (case .docx templates) and adds context about what they are used for. However, it contains no explicit verb such as 'list' or 'returns', so the action must be inferred from the tool name. It also does not distinguish this from the sibling templates_get.

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

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

No guidance is given about when to use templates_list versus templates_get or any other tool. The description explains what templates are, but not the conditions under which this list endpoint should be selected.

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

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

Beyond destructiveHint=true, the description discloses a meaningful behavioral constraint: deletion is blocked for cards referenced in operations, and it explains the rationale. This adds real context the annotations alone do not provide, though it does not cover side effects like reversibility, which destructiveHint already implies.

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

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

Two short sentences with the core action front-loaded, followed by the critical limitation and the alternative path. No filler, no repetition of schema content, and every sentence earns its place.

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

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

For a destructive two-parameter mutation with a fully described schema, the description covers the main failure mode and the correct fallback action. No output schema exists, but this simple call does not require return-value detail to be invoked correctly.

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

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

Schema description coverage is 100%, and both parameters (item and business) already have clear descriptions in the schema. The tool description itself adds no parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Удаляет товар или услугу' (deletes a product or service). It also clearly differentiates deletion from archiving by mentioning warehouse_save with archived=true, so an agent can distinguish this tool from its sibling.

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

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

The description explicitly gives a usage condition: a card used in any operation cannot be deleted, because stock history would lose its foundation. It then points to the correct alternative — archive via warehouse_save with archived=true — making the when-to-use and when-not-to-use decision explicit.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds a small behavioral detail—that the result includes the current balance—but does not disclose error behavior or any additional side effects.

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

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

The description is a single short sentence that front-loads the core object and the distinctive current-balance detail. It is appropriately sized, though the mismatch in terminology with the title slightly reduces its overall clarity.

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

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

For a simple read-only getter with rich annotations and fully documented parameters, the description conveys the main return value and the notable extra detail (current balance). A more detailed response shape would help since there is no output schema, but the essential calling intent is clear.

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

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

The input schema already documents both parameters, item and business, with 100% coverage. The description adds no extra parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states that the tool returns the complete product/service card along with the current balance, and the title adds the 'open card' intent. It is specific about the resource and return content, though it does not explicitly differentiate itself from sibling tools and has some terminology ambiguity between 'склад' and 'товара или услуги'.

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

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

The description gives no guidance on when to use this tool versus alternatives such as warehouse_list, warehouse_save, or warehouse_delete. An agent must infer from the name and schema that this is the read/get variant.

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

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

Annotations already cover the safety profile with readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds the useful domain fact that groups are shared between goods and services, which clarifies the data scope, but it discloses no additional behavioral details such as pagination, ordering, or business-context handling.

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

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

The description is very short and has no filler; the second clause earns its place by defining scope. However, the initial clause largely repeats the title, and the overall text is under-specified, making it concise but not fully informative.

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

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

With only one optional parameter, no output schema, and read-only annotations, the tool is relatively simple. Still, the description does not state what the tool returns, such as a list of warehouse groups, and it lacks an action verb. The missing return description is a moderate gap, though the annotations and simple schema help compensate.

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

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

The only parameter, business, is fully described in the schema with 'Дело: название или идентификатор...', so schema description coverage is 100%. The description adds no parameter-level information, so the baseline score of 3 is appropriate.

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

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

The description is 'Группы склада. Общие для товаров и услуг.' It names the resource and adds a scope qualifier, but it never uses an action verb such as list or get, and the main phrase duplicates the title/name. An agent can tell it concerns warehouse groups but not what operation is actually performed.

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

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

The phrase 'Общие для товаров и услуг' provides a minimal usage signal: these groups apply across both products and services, so the tool is relevant when such cross-cutting groups are needed. However, it does not explicitly say when to prefer this tool over siblings like warehouse_list, warehouse_get, or counterparty_groups, nor does it mention exclusions.

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

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

The description adds meaningful behavioral detail beyond the annotations: the balance formula, the fact that only actual operations are considered, and that services have no balance. Annotations already signal read-only, idempotent, and non-destructive behavior, so the description complements rather than repeats them.

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

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

The description is two sentences with no filler. It front-loads the core purpose and then supplies only the most relevant behavioral detail.

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

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

For a simple list tool with three optional parameters and no required arguments, the description gives enough context to call it correctly: what is returned, how balances are computed, and the service exception. It could be more specific about output fields or pagination, but those are not essential for invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra domain meaning, especially for kind=SERVICE by explaining that services have no balance, which goes beyond the schema's simple 'products or services' wording.

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

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

The description states that the tool returns warehouse cards with current balances, which clearly identifies the resource and purpose. It does not explicitly differentiate from warehouse_get, so it stops short of a 5.

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

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

There is no guidance about when to use this tool instead of warehouse_get, warehouse_save, warehouse_delete, or warehouse_groups. The intended use is implied from the name and the balance description, but alternatives are never mentioned.

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

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

The description adds meaningful behavior beyond annotations: current stock is computed from operations and cannot be set, only initial_stock can be changed, and VAT is specified as a percentage while omitting it means 'no VAT'. This significantly clarifies side effects and constraints 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.

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

Three short, front-loaded sentences cover the core behavior and the most important caveats. There is no filler and every sentence earns its place.

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

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

For a 13-parameter upsert tool with 100% schema description coverage, the description is complete enough. It covers the central create/update distinction and the non-obvious domain constraints, while the schema already documents parameter-level details such as kind being required at creation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining that 'item' is the update selector, that 'initial_stock' is the only stock-related field that can be changed, and that 'vat_rate' uses percentage semantics with omission meaning no VAT.

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

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

The description states exactly what the tool does: creates a new warehouse card when no card reference is given and modifies an existing one when a card is specified. This clearly distinguishes it from sibling read/delete tools like warehouse_list, warehouse_get, and warehouse_delete.

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

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

The first sentence gives explicit decision logic: use it to create when no card is specified, and to update when a card is specified. It also warns that current stock cannot be set, which prevents misuse. It does not explicitly name read/delete siblings as alternatives, but the usage context is clear.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral guidance beyond that: the returned values are not merely examples but the complete accepted set, with case-sensitive exact spelling required. This is useful operational context an agent would not otherwise know.

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

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

Two compact sentences convey the entire purpose, scope, and usage caution with no filler. The list of catalog sections is necessary rather than verbose, and the critical 'look here before guessing' guidance is placed prominently.

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

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

For a simple optional-parameter read-only catalog, the description adequately covers content, purpose, and exact-match behavior. The only minor gap is the lack of any description of the response format, but no output schema exists and the tool's simplicity makes the return shape reasonably inferable.

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

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

The input schema is fully self-documenting: one optional property with an enum of ten values and a description explaining that omitting it returns all sections. The tool description's category list mirrors the enum values and does not add meaningful per-parameter semantics beyond what the schema already provides.

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

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

The description clearly identifies a reference catalog: it lists the exact categories of valid values the panel expects, and positions the tool as the authoritative lookup before guessing field values. This distinguishes it from sibling list/CRUD tools like categories_list or counterparty_groups, which fetch business data rather than canonical accepted strings.

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

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

The description explicitly tells the agent to consult the catalog before guessing a field value and warns that the panel accepts only these exact strings in this exact spelling. It does not name alternatives or exclusions, but for a read-only reference tool this is sufficient and clear context.

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

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

Adds useful behavior beyond annotations: the token is shown only once, is entered by a human, and does not appear in the conversation. This gives the agent important interaction context and complements the openWorldHint and readOnlyHint annotations without contradicting them.

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

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

Four focused sentences, no filler. The primary action is front-loaded, and the credential-handling guidance and trigger condition are presented efficiently.

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

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

For a login tool, the description fully covers when to call it, what the agent should expect (window, human-entered token), and how credentials are handled. The absence of an output schema is not a serious gap here, and the parameter schema covers the remaining details.

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

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

Schema coverage is 100%, so the schema already documents url and switch_account. The description adds context about the token and window flow but does not substantially deepen understanding of the two parameters beyond what the schema provides.

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

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

Description states a specific action: opens a window for entering panel address and access token. This clearly distinguishes it from sibling data-management tools and from logout, even without naming alternatives.

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

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

Explicitly tells when to invoke: when other tools report access is not configured or the token is no longer valid. It also explains that the human must enter the token, providing clear context for agent behavior, though it does not explicitly name alternatives or when-not-to-use conditions.

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

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

Beyond the destructiveHint annotation, the description clarifies exactly what is destroyed and, importantly, what is not: the token remains valid after this action. This prevents the agent from assuming the user is fully logged out everywhere.

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

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

The description is two short sentences, front-loads the core action, then adds the essential nuance about token validity. Every sentence earns its place with no repetition of title or annotations.

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

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

For a zero-parameter destructive tool, the description covers the action, the scope, the limitation, and the remediation path. Nothing critical is missing 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.

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 are no parameter semantics to clarify. The description still usefully scopes the action to 'this machine', giving context beyond the empty schema.

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

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

The description uses a specific verb and resource: it erases the saved token from this machine. It clearly distinguishes this local logout action from broader account or token-revocation operations, and from sibling tools like ychetlab_login and ychetlab_whoami.

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

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

It explicitly explains when this tool is appropriate: when you want to forget access on this machine only. It also gives a clear alternative for the opposite need: to stop the token working everywhere, revoke it in the panel (profile → Integrations).

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

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

Annotations already declare readOnly, non-destructive, idempotent, and open-world behavior. The description adds useful behavioral context beyond annotations: a token issued for specific cases will only reveal those cases, and the panel will not show others. This meaningfully informs the agent about visibility constraints.

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

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

Three sentences, each earning its place: what the tool returns, when to call it, and the token-scope caveat. The most important information is front-loaded and there is no filler.

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

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

For a zero-parameter, no-output-schema tool, the description is quite complete: it names the returned information and gives clear guidance on ordering and token limitations. It could be slightly more explicit about the exact output shape or authentication prerequisite, but these are minor given the simplicity of the tool.

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

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

The tool has zero parameters, so the schema is fully covered and there is nothing for the description to add about parameter meaning. The description focuses on output and usage, which is appropriate for a parameterless call.

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

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

The description clearly states what the tool returns: the server's account, the connected panel, and available cases. This distinguishes it from the many business-operation siblings; it is the only identity/scope introspection tool.

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

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

It explicitly advises calling this tool first, and explains why: subsequent tools can then reference cases by name. It also notes the token-scope effect on which cases are visible. It does not mention when not to use it or name an alternative, but no direct alternative exists among siblings.

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