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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the trailing "Только чтение" is largely redundant. What does add value is the disclosure of the returned content and its role as an id-prerequisite for the rest of the toolset, which is meaningful given there is no output schema.

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

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

Two sentences, both earning their place: the first declares the payload, the second gives the call-order guidance and the read-only guarantee. The routing advice is front-loaded rather than buried.

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

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

With no parameters and no output schema, the description carries the full burden of explaining what comes back, and it does so field by field. An agent has everything it needs to call this tool correctly and use its output downstream.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing to document and nothing is missing. The description's listing of returned fields is a substitute for the absent output schema rather than a parameter explanation.

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+resource: it returns an amoCRM/Kommo account summary, enumerating exactly what comes back (name, currency, managers with id/name/e-mail, all pipelines with stage ids and names). This identifies it clearly against siblings that operate on leads, contacts, tasks or reports.

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?

"Вызывайте первым" gives an explicit ordering instruction and the reason behind it: pipeline, stage and manager ids are required by the other tools for filtering and deal creation. It also states the read-only nature, leaving no ambiguity about when this lookup is the right call.

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, and the description is consistent with that ('Изменяет данные в CRM'). It adds genuinely useful context beyond the annotations by requiring the agent to surface the note text and obtain user consent before writing.

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

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

Two tight sentences, front-loading the action and example and ending with the consent requirement. No filler, though it is short enough that more useful detail could have been added without bloat.

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 no output schema, three parameters at 0% schema coverage, and a real write action, the description covers purpose and consent but leaves parameter meanings and result behavior unaddressed. Adequate but with clear gaps for the agent.

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

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

Schema description coverage is 0%, so the description must carry the load, but it only loosely alludes to the text and target entity. entity_id is never explained, and the entity_type values are indirectly described as deal/contact/company rather than the actual enum leads/contacts/companies, so it does not compensate for the coverage gap.

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

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

States a specific verb and resource ('Добавляет текстовое примечание') plus the target scope (deal/contact/company feed) and a concrete example, which separates it from the create_/update_/search_ siblings. The only wobble is that it names 'сделки' while the entity_type enum offers 'leads', a small mismatch an agent must reconcile.

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?

Gives a workflow instruction ('show the user what will be recorded and get consent') but no explicit when-to-use or when-not-to-use. Since no sibling also adds notes, usage is largely implied, which sits at the minimum-viable 3.

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, destructiveHint=false, openWorldHint=true, so the mutation nature is known. The description adds value beyond that by stating it writes the result text into the CRM and requires explicit user consent before proceeding, which is meaningful behavioral context.

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

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

Two tight sentences: purpose first, then the consent caveat. No filler and everything is front-loaded, though the second sentence mixes two instructions (change data + get consent) in one clause.

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

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

For a two-parameter mutation tool with safety annotations and no output schema, the definition covers purpose, the write target, and the confirmation requirement. It omits what happens on success, whether the task must exist, or how the id is obtained, but these 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 coverage is 50%: the 'result' param has a description and the description adds an illustrative example ('Дозвонился, отправил КП'). However the 'id' parameter is undocumented in both schema and description, so the description only partially compensates for the coverage gap.

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

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

The description states a specific verb and resource ('Закрывает задачу' = closes a task) and clarifies the required payload (result text), with a concrete example. It is clearly distinguishable from crm_create_task and crm_tasks, though it does not explicitly name sibling tools.

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

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

It gives a clear operational precondition: 'show the user what will be written and get consent' before invoking. It does not name alternative tools or state when NOT to use this one, so it falls short of full when/when-not 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=false, destructiveHint=false, openWorldHint=true. The description adds genuinely useful behavior beyond that: the default pipeline/status fallback and an explicit consent/prerequisite requirement ('покажите пользователю, что будет записано, и получите согласие'). Return semantics are not covered but annotations carry the safety profile.

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

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

Three tight sentences with no filler: core creation semantics first, then the default-stage behavior, then the write-consent warning. Each sentence earns its place and the important operational caveats are front-loaded.

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

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

For a mutation tool with 11 parameters, no output schema, and low schema coverage, the description covers the critical gaps — composite creation, default stage routing, and consent. It is slightly short on parameter meaning for the remaining undocumented fields, but nothing essential to correct invocation 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 only 27%, so the description must compensate — and it does explain several parameters (name, phone, email, company, note, and the pipeline_id/status_id default behavior). But it omits tags, price, contact_name, and responsible_user_id, leaving a substantial share of the 11 parameters undocumented in both places.

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 ('создаёт сделку') and highlights the composite behavior: deal + contact + company in one request, optionally with a note. This implicitly separates it from crm_update_lead and crm_get_lead, though no sibling is named explicitly.

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

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

It gives concrete operational context: without pipeline_id/status_id the deal lands in the first stage of the main pipeline, and it tells the agent to confirm with the user before writing. It does not, however, name when to prefer this over crm_update_lead or crm_add_note.

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, openWorldHint=true, destructiveHint=false, so the write profile is partly covered. The description still adds valuable context: it explicitly warns that it 'Изменяет данные в CRM' and prescribes a show-and-confirm consent flow before writing, which the annotations do not express. Return format and idempotency remain undisclosed.

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, and the purpose is front-loaded ahead of the operational warning. The consent clause earns its place by guarding a mutation, so nothing reads as padding.

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?

No output schema exists, so the description should ideally cover the required inputs and the write's effect. It handles the mutation-confirmation angle well but omits the two required parameters (text, due) and the entity linkage fields, and the deal/leads terminology clash leaves the target entity ambiguous for a 6-parameter write tool.

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

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

Schema coverage is only 33%, so the description carries significant burden. It does add meaning for 'срок' and 'ответственный' and maps examples to task types, but it says 'сделке' (deal) while the entity_type enum offers 'leads/contacts/companies' — a mismatch that could mislead — and never mentions entity_id or the required 'text' parameter. Baseline 3 for a schema-led definition is generous here.

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 specific verb and resource ('Ставит задачу по сделке, контакту или компании') and enriches it with concrete task examples (перезвонить, отправить КП, встреча) plus the key scope fields (срок, ответственный). It is clearly a task-creation tool, though it never names the sibling it differs from (e.g. crm_complete_task for closing tasks, crm_tasks for listing), so full differentiation is left to inference.

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

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

The only usage instruction is the mutation-confirmation step ('покажите пользователю, что будет записано, и получите согласие'), which tells the agent how to invoke it safely but not when to prefer it over alternatives like crm_complete_task or crm_add_note. Usage context is implied by the entity types mentioned rather than explicitly scoped.

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 'Только чтение' simply restates it without adding anything. The useful addition is the disclosed return surface (phones, e-mail, owner, related deal/company ids), which matters because no output schema exists; auth, rate limits and pagination go unmentioned.

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 tight sentences with the search capability front-loaded and the read-only caveat last. No filler, though the parenthetical use case could be trimmed.

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?

Covers purpose, search fields, return fields, and safety, which is most of what a 2-param read tool needs when there is no output schema. The undocumented 'limit' and absent pagination behavior are the remaining gaps.

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

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

Schema coverage is 0%, so the description must carry the load. It explains that 'query' accepts a name, phone, or e-mail, which is genuinely useful, but says nothing about the 'limit' parameter or its 1-100 range.

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?

Clear verb+resource ('Ищет контакты') with the three searchable field types named. It implicitly distinguishes itself from crm_search_leads/crm_get_lead by operating on contacts rather than leads, but never names a sibling explicitly.

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

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

Gives a concrete use context ('удобно для входящего звонка или письма') that tells the agent when this tool is the right pick. No explicit when-not or named alternative, 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?

The annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'Только чтение,' which merely repeats readOnlyHint, and lists returned content but does not disclose additional behavioral traits such as authorization needs, rate limits, or what happens when the record is missing. With annotations covering the safety profile, the description adds only limited value beyond 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 front-loaded, beginning with the returned resource and its contents, followed by usage guidance. It is appropriately sized for the tool, though the final 'Только чтение' clause is redundant with the readOnlyHint annotation.

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?

Because there is no output schema, the description usefully enumerates the main fields returned, which is important for an agent. It still omits any explanation of notes_limit and edge-case behavior when the record is not found, leaving a small completeness gap.

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

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

The schema describes the required id parameter but leaves notes_limit undocumented, giving 50% schema description coverage. The description does not mention either parameter directly or explain the behavior of notes_limit; 'последние примечания' is too vague to compensate for the missing parameter documentation.

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

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

The description clearly states that this tool returns a full deal/lead card and enumerates its contents (budget, stage, owner, custom fields, tags, contacts, company, open tasks, recent notes). This makes the resource and scope concrete. However, it does not explicitly distinguish this single-record fetch from sibling tools like crm_search_leads, 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?

It explicitly says to use this tool to prepare for a call or understand a client's history, which gives clear context for invocation. It does not name alternatives or state when not to use it, so it lacks the explicit routing guidance that would earn a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description's closing 'Только чтение' is consistent with that rather than contradicting it. It omits operational behavior the annotations don't cover — notably what the max_leads cap of 3000 (up to 10000) means for completeness of results, and whether output is paginated or truncated.

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

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

Two sentences front-load the metric inventory before the example questions, and the 'read only' note closes it. No filler, though the metric enumeration is dense and the example questions add modest value.

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

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

With no output schema, the description carries the burden of describing return content and does so thoroughly (stages, won/lost, conversion, averages, manager split). The main gap is behavioral: it doesn't explain the max_leads sampling limit or what happens when a large date range exceeds it.

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

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

Schema description coverage is 75%, just under the high-coverage threshold, so the schema itself documents created_from, created_to, and pipeline_id. The description only alludes to the date period conceptually ('за период создания сделок') and says nothing about max_leads, adding little beyond the structured fields.

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

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

The description states a specific deliverable: analytics on the sales funnel for the deal-creation period, enumerating the metrics returned (per-stage counts/amounts, won/lost, conversion, average check, average cycle days, manager breakdown). This clearly separates it from the CRUD-oriented siblings (crm_search_leads, crm_create_lead), though it never names them explicitly to draw the line.

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

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

It gives concrete use-case prompts ('how are sales going this month', 'which manager closes better'), which effectively signals when to reach for it. However, there is no explicit when-not guidance or reference to alternative tools such as crm_stale_leads for at-risk deals, so the routing is implied rather than stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered, and 'Только чтение' merely restates it. The description does add behavior the annotations don't carry: the exact fields returned and the ordering rule ('сначала недавно изменённые'), which materially affects how an agent consumes 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?

Two sentences, no filler: the first states the search scope and filters, the second states the returned fields, sort order and the read-only nature. Purpose is front-loaded and every clause carries 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?

There is no output schema, so the description correctly compensates by naming the returned fields and sort order, and it covers the main filter surface for a 7-parameter tool. Minor gaps remain around 'limit' behavior and the documented dependency of status_id on pipeline_id.

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

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

With 57% schema description coverage, the description usefully expands the sparse 'Поисковая строка' into the concrete fields searched (name, phone, e-mail of the contact) and maps the filter concepts to pipeline/stage/responsible/period. It does not explain 'limit' (default 50, max 250) or the pipeline_id+status_id pairing, but it adds real meaning over the schema for most parameters.

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

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

The description gives a specific verb+resource ('Поиск сделок amoCRM/Kommo') and enumerates the match fields (name, phone, e-mail) and filter dimensions (funnel, stage, responsible, creation period), so the agent knows exactly what this does. It never names or contrasts with siblings like crm_stale_leads or crm_pipeline_report, so sibling differentiation is only implicit.

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

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

Usage is implied by the described filters and the search-string capability, which is enough to infer 'use this to find leads by text/filters'. There is no explicit when-to-use statement, no when-not, and no routing to the specialized alternatives (crm_stale_leads, crm_pipeline_report) that also return lead sets.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description's 'Только чтение' merely repeats that. It does add real value beyond the annotations by disclosing the default 7-day threshold and, importantly, the return shape (sorted by budget, with responsible, stage, and days idle) since no output schema exists.

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

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

Two front-loaded sentences with no filler: the first defines the stale condition, the second covers sorting and returned fields. Efficient, though the clause list in sentence two is slightly dense.

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

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

With no output schema, the description usefully sketches the return fields and sort order, and fully explains the staleness rule. However, it leaves the semantics of limit, pipeline_id, and responsible_user_id unexplained, which is a real gap for a 5-parameter filtering tool.

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

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

Schema coverage is only 40%: days and include_no_task are documented in the schema, but limit, pipeline_id, and responsible_user_id have no description anywhere. The description echoes the 7-day default and mentions 'с ответственным' (responsible), but does not compensate for the three undocumented parameters as a <50% coverage case requires.

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 resource (open deals) and the precise condition that makes them stale (no change for 7+ days by default, or no scheduled task), which clearly defines the tool's purpose. It does not, however, name or distinguish itself from the closest sibling (crm_search_leads), which also returns lead lists.

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

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

It defines the staleness criteria that trigger inclusion, which implies when the tool is relevant, but gives no explicit 'use this instead of crm_search_leads when...' guidance or exclusion conditions. The criteria are inferable rather than stated as usage rules.

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 openWorldHint=true, and the description's 'Только чтение' merely restates that rather than adding new behavioral context. It does add useful substance by enumerating the returned fields (text, due date, responsible, linked deal/contact), but says nothing about limits, ordering, 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?

Tightly written: the listing scope and filters come first, the return payload follows, and the read-only note closes it. No filler, though the final 'Только чтение' is redundant with the 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?

With no output schema, describing the per-task fields is genuinely helpful, and there are no required parameters or nested structures to explain. Still, the limit parameter goes undocumented and the deal/lead terminology mismatch leaves an agent guessing on one of four inputs.

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

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

Schema coverage is 0%, so the description must carry the load and it partially does: the scope enum is spelled out as 'все / просроченные / на сегодня', and the responsible and deal filters are described. However, the limit parameter (default 100, max 500) is never mentioned, and 'фильтр по сделке' is ambiguous against the actual lead_id parameter name.

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 specific verb and resource ('Список незавершённых задач') plus the three scope variants, so an agent can tell it apart from the write-side siblings crm_create_task and crm_complete_task by the listing/read semantics. It never names an alternative tool explicitly, which is the only thing keeping it from a 5.

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

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

The description implies when to use it — to enumerate open/overdue/today tasks, optionally filtered by responsible or deal — but gives no when-not guidance and never contrasts with crm_create_task, crm_complete_task, or crm_stale_leads. Usage is inferable but not spelled out.

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, destructiveHint=false and openWorldHint=true, so the write nature is covered. The description adds genuinely non-obvious behavior: tags replace the current set rather than appending, and status_id 142/143 mean won/lost, plus a consent requirement before persisting.

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

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

Two sentences, front-loaded with the operation and field list, followed by the safety instruction. The long field enumeration is dense but earns its place given the sparse schema, though it reads as one heavy run-on 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 an 8-parameter mutation with no output schema and low schema coverage, the description supplies the field semantics, the tag-replacement caveat, status codes and a consent step. It omits error/permission behavior, but nothing essential for invoking it correctly is missing.

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

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

Schema description coverage is only 13%, so the description carries the load — it maps nearly every one of the 8 parameters to a business meaning (name, price as budget, status/pipeline, responsible, tags, custom_fields by field_id). It still doesn't clarify units for price or how pipeline_id interacts with status_id, so it falls short of fully compensating.

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 specific verb (Меняет) and resource (сделку) and enumerates the mutable fields, so an agent can immediately separate it from crm_create_lead and crm_get_lead. The scope of the operation is unambiguous.

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

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

It gives one real workflow guideline — show the user what will be written and obtain consent before writing — but says nothing about when to prefer this over siblings or what prerequisites (permissions, pipeline existence) apply. Usage is implied by the verb rather than explained.

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