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

No annotations are provided, so the description carries the full behavioral burden. It discloses only the two operating modes; it says nothing about permissions, idempotency, what happens if chat_id is invalid or already attached, or whether attaching a new chat creates side effects in Telegram.

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 dense sentence with the verb and resource front-loaded and the parameter list demoted to a parenthetical. Nothing is padded, though the terseness contributes to the parameter coverage gap.

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 tool with zero annotation coverage, no output schema, and 0% schema descriptions, the description is thin. It omits how the project is identified (project_id vs project_name), what note does, and the required/optional nature of every field — all of which the agent must guess.

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% across 8 parameters, so the description must compensate. It names five of them (chat_id, title, kind, tg_chat_id, tg_link) and groups them by mode, but leaves note, project_id, and project_name completely undocumented — and the project-identification params are arguably the most important for correct invocation.

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+resource ('привязать чат к проекту' / attach a chat to a project) and clarifies the dual mode: attach an existing chat_id or create a new chat inline. An agent can distinguish it from the sibling bort_chat_detach, 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?

The parenthetical ('существующий chat_id или создать новый') implicitly tells the agent which parameter path to take depending on whether the chat already exists, which is useful branching guidance. However, it names no alternatives and gives no preconditions (e.g. whether the project must already exist, or how project_id/project_name select the target).

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

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

No annotations are provided, so the description carries the full burden. It does disclose one meaningful behavioral trait – the chat is not deleted, only unlinked, and remains in the catalog. However, it says nothing about permissions, reversibility, or whether both identifiers must resolve to an existing link.

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 sentence that front-loads the action and appends the key side-effect clarification in parentheses. Nothing is wasted, though the extreme brevity leaves little room for the guidance 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 two-parameter mutation tool with no annotations and no output schema, the description is thin: it omits parameter usage, preconditions, and failure behavior. Only the state outcome (chat persists) is 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?

Both parameters have 0% schema description coverage and no enums, and the description adds no meaning for chat_id or project_id. It is unclear whether either or both are required to identify the link, especially since the schema marks both nullable with default null.

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 (detach) and resource (chat from project) in one clear phrase, and the parenthetical clarifies the object that survives the operation. It does not name the inverse sibling bort_chat_attach, so sibling differentiation is only inferable from the name.

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 parenthetical implies when this is appropriate versus deleting a chat, but there is no explicit when-to-use statement, no mention of the alternative bort_chat_attach, and no prerequisites or preconditions described.

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

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

With no annotations present, the description carries the full behavioral burden and discloses only the shape of returned data (participants, project links). It says nothing about pagination, result limits, permissions, or ordering for a list endpoint.

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 compact clause pair with the filter behavior front-loaded after the returned-data summary. Nothing is wasted, though the semicolon construction packs two distinct ideas densely.

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 three-parameter list tool with no annotations and no output schema, the description covers only one parameter and the rough return shape. An agent must guess at q and project_name semantics and at pagination or result size.

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% across three parameters, and the description only explains project_id's filtering effect. The semantics of q (search query?) and project_name (filter vs lookup?) are left entirely undocumented, so the description does not compensate for the schema 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 the resource (chats) and what it returns (participants and project bindings), and the leading token of the name makes the list operation clear. It distinguishes scope via the project_id behavior, though it never uses an explicit 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?

It gives one conditional usage rule: passing project_id narrows results to that project's chats. There is no guidance on when to prefer this over siblings such as bort_project_summary or bort_chat_attach, and no mention of how q or project_name interact with that filter.

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

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

No annotations are provided, so the description carries the full burden. It helpfully discloses defaults (spent_on=today in BORT_TZ, category=other) and the return value (new project margin), but says nothing about how the project is identified (project_id vs project_name), currency handling, or required authorization for a mutation.

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 dense sentence with the core action front-loaded, followed by compact input-format and default notes and the return value. Efficient, though the packing of amount/currency/date/category details makes it slightly list-like.

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 annotations and no output schema, the description covers the financial input formats and defaults reasonably well. It is incomplete on project identification and currency, which an agent needs to call it correctly.

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

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

Schema coverage is 0% across 8 parameters, so the description must compensate. It explains amount (ruble string format «1 200,50»), amount_minor (kopecks), spent_on default, and category_code default, but leaves comment, currency, project_id, and project_name completely undocumented.

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 + resource (add an expense to a project) and immediately scopes the operation to a project entity, which no other sibling tool handles. An agent can tell exactly what this does without opening the schema.

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

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

Usage is implied by the name and description, and no sibling tool competes for expense creation. However, there is no explicit statement of when to use this versus other write tools, nor any prerequisites such as project resolution or required permissions.

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

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

No annotations are provided, so the description carries full behavioral burden. It does disclose meaningful behavior: upsert semantics (create or update), the lookup precedence, and that it can attach to project and/or chat with a role. It omits what happens to existing fields on update, permissions/auth requirements, and reversibility, leaving notable gaps.

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

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

A single dense sentence using semicolons to front-load the core action and then the matching logic and side effects. Efficient with no redundant filler, though the parenthetical matching detail could be tightened.

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 and no annotations, the description should ideally explain the return value and update-overwrite behavior. It adequately covers the mutation and attach behavior but leaves the notes parameter and the result/response undefined for a 7-parameter mutation 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 0% across 7 params, so the description must compensate. It maps clearly to role, tg_username, full_name (via 'имени'), attach_to_project_id/name, and attach_to_chat_id, adding real meaning over the bare schema. Only the 'notes' parameter is unaddressed, a minor gap given the otherwise strong coverage.

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

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

The description states a specific verb+resource ('Создать или обновить человека') and clarifies the upsert matching logic (by tg_username, then by name), which distinguishes it from pure create/update tools. It does not name any sibling tool it competes with, but no sibling covers person entities, so the purpose is unambiguous.

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

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

The matching order ('ищется по tg_username, затем по имени') gives useful context for how the upsert resolves an existing record, which is a form of usage guidance. However there are no explicit when-to-use vs when-not statements or alternatives named, so it remains implied rather than directive.

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

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

With no annotations at all, the description carries the full disclosure burden, yet it says nothing about permissions, defaults for the seven optional fields, side effects, or what happens if both deal_amount and deal_amount_minor are supplied. Only the unit semantics of the two amount fields are disclosed.

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

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

Two short sentences, front-loaded with the core action and immediately followed by the highest-risk ambiguity (amount units). No filler, though the brevity is partly under-specification rather than discipline.

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?

An 8-parameter mutation tool with no annotations, no output schema, and zero schema descriptions needs far more than a purpose line and one unit note. Six optional parameters and the mutation's side effects are left undefined.

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% across 8 parameters, so the description must compensate, and it only covers two of them. Those two are handled well (rubles with '150 000,50' format example vs. kopecks in deal_amount_minor), but name, notes, status, currency, deadline, and priority remain entirely undocumented.

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 ('Создать проект' – create a project), so the agent knows exactly what the tool produces. It does not, however, distinguish itself from the sibling bort_project_update or explain scope relative to bort_project_list/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 when-to-use guidance, no prerequisites, and no mention of alternatives such as bort_project_update for existing projects. The only guidance is which amount parameter to pick, which is a parameter detail rather than usage context.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the shape of the returned data (tasks, costs, chats, people), which is valuable given there is no output schema, but it omits read-only status, not-found behavior, or what happens when both name and project_id are omitted.

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, no filler, with the scope of the returned project front-loaded ahead of the lookup mechanics.

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 annotations and no output schema, the description does the essential work by naming the returned entities and the lookup semantics. It lacks only edge-case behavior (both/neither parameter, not found), which is a modest gap for a two-parameter read 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 0%, so the description must compensate, and it does: it clarifies that name must be an exact match and that matching is case-insensitive, and pairs it with project_id as the two lookup paths. It doesn't explain precedence if both are supplied, but adds real meaning beyond the bare 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?

States a specific verb+resource: fetch an entire project including its tasks, costs, chats, and people. Clearly distinguishable from a plain list tool, though it doesn't explicitly contrast with the sibling bort_project_summary, which sounds very close in scope.

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

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

The description tells the agent how to look a project up (by project_id or exact name), which is useful, but gives no explicit when-to-use guidance versus bort_project_list or bort_project_summary, nor any prerequisite or exclusion 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?

No annotations are provided, so the description carries the full burden. 'краткая форма' usefully signals that the output is abbreviated, but it says nothing about default/pagination behavior for limit, result ordering, or whether the list is scoped to a caller. For a zero-annotation tool this is a significant gap.

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

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

A single compact line with the purpose front-loaded and filters enumerated after. No filler sentences; 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?

With 4 optional params, no output schema, and no annotations, the description covers filter semantics adequately but omits limit/default behavior and any indication of what 'краткая форма' returns. Adequate but not fully self-sufficient.

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 compensate, and it does for three of four params: status enum values (idea|active|paused|closed), priority range with semantic inversion (1 — критичный), and q meaning (search by name). Only limit is left unexplained.

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+resource ('Список проектов') plus a scope qualifier ('краткая форма'), which distinguishes it from bort_project_get and bort_project_update. However, it never names the sibling it is contrasted with, so 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 filter semantics imply when to use it (filtered listing across projects), but there is no explicit when-to-use, when-not-to-use, or alternative routing to bort_project_get / bort_project_summary. Usage 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?

No annotations are provided, so the description carries the full burden. It does disclose the returned data categories (money, margin, task progress, cost breakdown), which is real behavioral content, but it omits permissions, read-only nature, and behavior when both or neither identifier is supplied.

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 compact sentence with the content enumeration front-loaded and the identifier options trailing. No wasted words, though it is terse to the point of under-specification.

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 and no annotations, the description must cover both selection and returns. It sketches the returned metrics but omits edge-case behavior and access requirements for a tool whose identifier is fully optional.

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?

Two parameters at 0% schema coverage, so the description must compensate. 'По project_id или названию' usefully signals that either identifier works, but it does not explain precedence when both are given or what happens when neither is provided, leaving a real 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+resource ('Сводка одного проекта') and enumerates what the summary contains (money, margin, task progress, cost breakdown by category). This differentiates it from a plain get, but it never explicitly contrasts itself with siblings like bort_project_get or bort_summary.

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

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

The clause 'По project_id или названию' explains how to identify the project but gives no when-to-use guidance or alternatives. An agent gets no help deciding between this and bort_project_get or the aggregate bort_summary.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the partial-update semantics (only changed fields are sent), which is genuinely useful and not inferable from the schema alone. It says nothing about required permissions, what happens when the identifier is missing, error behavior, or irreversibility of the mutation.

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 compact parenthetical sentence with no filler, and the core action plus the identifier caveat are front-loaded. Nothing is wasted, though the brevity is partly a symptom of under-specification.

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, 0% schema coverage, no annotations and no output schema, the description is far too thin. It omits field-level meaning, identifier requirements, and any behavior on partial failure, so an agent cannot confidently construct a call for anything beyond the identifier.

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% across 11 parameters; the schema supplies only titles, so the description must compensate. It clarifies only the identifier mechanism (project_id or name) and the partial-update rule; the other nine fields (notes, status, currency, deadline, priority, dates, deal amounts) and the distinction between deal_amount and deal_amount_minor are left entirely undocumented.

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+resource ('Обновить проект'), which distinguishes it from bort_project_list/get/create siblings. It also names the identifier options (project_id or name). No further sibling differentiation (e.g., vs bort_project_summary) is given, but the update verb is unambiguous.

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

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

The phrase 'передаются только изменяемые поля' implicitly tells the agent this is a partial/PATCH-style update and that unset fields may be omitted, which is useful call-shaping guidance. However, there is no explicit when-to-use vs alternatives, no prerequisites, and no note on whether the identifier is required given 0 required parameters.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It describes the shape of the output (aggregates, deadline-state list), which is useful, but says nothing about whether it is read-only, permission requirements, cost/rate limits, or the effect of the scope parameter beyond its literal values.

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 padding; the core purpose is front-loaded before the scope values. Efficient, though the raw enum dump at the end is slightly terse rather than integrated.

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 and no annotations, the description must be self-sufficient, and it is not: the q parameter is undocumented, there is no differentiation from the near-identical sibling bort_project_summary, and no behavioral profile is given for a tool whose return content is only partially described.

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 compensate. It does add real meaning for scope by listing the enumerated values open|active|all, which the schema does not declare, but the q parameter (likely a search/filter string) is left entirely unexplained in both schema and 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 states a specific verb+resource (project summary) and enumerates what it contains: aggregates (money, overdue/burning counters) and a list with deadline state. It is clear what the tool does, but it never distinguishes itself from the sibling bort_project_summary, which appears to cover overlapping ground, so an agent cannot tell the two 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 only usage signal is the scope enumeration (open|active|all), which hints at filtering context but does not say when to use this tool rather than bort_project_summary or bort_project_list. No exclusions, prerequisites, or alternative-selection guidance are 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?

No annotations are provided, so the description carries the full burden. It does disclose one meaningful side effect ('проставляет closed_at'), which is real behavioral value for a mutation, but says nothing about permissions, reversibility, idempotency, or error behavior on an already-closed or nonexistent task.

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 compact sentence that front-loads the action and appends the side effect. Every clause earns its place, though the two inline glosses ('выполнено', 'отменено') are mildly redundant with the English tokens.

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 annotations and no output schema, the description must stand alone. It covers the action, the outcome vocabulary, and the closed_at write, but omits preconditions, failure modes, and return behavior — adequate but noticeably thin for a mutation 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 0% and the schema gives no enum for outcome, only a default of 'done'. The description compensates by defining both legal outcome values and their meanings, which is genuinely additive. However, task_id — the required parameter — gets no explanation at all.

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+resource: 'Закрыть задачу' (close a task), and enumerates the two outcome values with glosses. An agent can distinguish this from bort_task_update and bort_task_create, though it never explicitly contrasts with 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?

No when-to-use guidance at all: nothing says whether to call this instead of bort_task_update with a status field, whether the task must be open first, or what happens on re-closing. The outcome semantics are described, but the routing decision against siblings is left entirely to inference.

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

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

No annotations are provided, so the description carries the full burden. It does not state whether the call requires permissions, what defaults apply to the many optional fields (status, priority, deadline), or what is returned on success; for a mutation tool this is a significant gap.

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

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

It is a single front-loaded sentence with no filler, which is structurally clean, but for a 7-parameter mutation tool the brevity reads as under-specification rather than efficient conciseness.

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 7 optional parameters, no annotations, no output schema, and zero schema descriptions, the definition is far too thin for an agent to invoke it correctly. At minimum the field meanings and defaults needed documenting.

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% across 7 parameters, so the description must compensate. It only alludes to the project_id/project_name pair and says nothing about notes, title, status, deadline, or priority, leaving the majority of parameters undocumented.

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 ('Создать задачу' = create a task) and scopes it to a project, which is enough to distinguish it from siblings like bort_task_update and bort_task_close. It does not explicitly name those alternatives, so it falls short of the sibling-differentiation bar for 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 only guidance is the parenthetical '(project_id или project_name)', which hints at two ways to identify the project but never says when to use one over the other or when this tool applies versus task_update/task_close. There is no when/when-not context.

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

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

No annotations are provided, so the description carries the full burden. It conveys only that unspecified fields are left alone; it says nothing about permissions, whether omitted-vs-null fields differ, error behavior, or what a status change entails.

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 compact sentence that front-loads the identifier and the partial-update rule. Nothing is padded, though it is arguably too terse given the tool's complexity.

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 6-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, this is insufficient: the agent learns neither the updatable field set, the accepted values, nor the effect of the 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?

Schema description coverage is 0% across 6 parameters, so the description must compensate. It only names task_id and alludes vaguely to 'изменяемые поля' without listing or explaining any of the five mutable fields (notes, title, status, deadline, priority) or their formats.

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 ('Обновить задачу' = update a task) and identifies the key parameter (task_id). It does not, however, distinguish this from sibling mutation tools such as bort_task_close, which also acts on a task.

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 parenthetical '(передаются только изменяемые поля)' implies partial-update semantics, which is useful guidance. But there is no statement of when to use this versus bort_task_close or bort_task_create, nor any preconditions.

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