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

The readOnlyHint annotation already establishes safety; the description adds useful behavioral context by explaining that autoFilterSettings is the board's own filter that shows which issues the board collects. It also discloses the board subcomponents returned, which helps set expectations without contradicting the 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?

Two dense sentences with no filler; the core action and scope are front-loaded, and the second sentence adds value by explaining a non-obvious field. The parenthetical Russian term is a small, purposeful addition for localization.

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 a read-only annotation, an output schema, fully described parameters, and a clear purpose, the description is mostly sufficient. It could be more complete by explicitly routing to boards_get_all or board_get_columns when only IDs or columns are needed, but 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 coverage is 100%, and both parameters already have meaningful descriptions, so the tool description adds little beyond schema. The description's focus on board contents does not explain the fields/board_id parameters further, keeping this 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 uses a specific verb-resource pair ('Get a single Yandex Tracker agile board') and enumerates what is included: settings, columns, estimation field, and working calendar. It also defines autoFilterSettings, which differentiates this tool from listing tools like boards_get_all and narrower tools like board_get_columns.

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

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

The description gives a concrete use case: read autoFilterSettings to learn which queue a board is about, and it implies single-board retrieval rather than listing. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

The description adds useful behavioral context beyond the readOnlyHint annotation by clarifying that results include status mappings and are richer than simpler board column endpoints. It does not mention auth or rate limits, but for a simple read-only lookup with a readOnlyHint, the safety profile is already clear.

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

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

Two dense sentences with no filler: the action is first, then the use case, then the comparison to sibling tools. Every sentence contributes 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?

The tool has one fully documented parameter, a readOnlyHint annotation, and an output schema, so the description does not need to explain return values. The provided use case and sibling differentiation make the description complete for an agent to select and call 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?

Schema description coverage is 100%: the only parameter, `board_id`, is described as an agile board identifier returned by `boards_get_all`. The tool description adds the Yandex Tracker context but does not need to compensate for missing parameter documentation because the schema already covers it.

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: getting the columns of a Yandex Tracker agile board, including the statuses mapped to each column. It also explicitly distinguishes this tool from `boards_get_all` and `board_get`, so an agent can tell them apart without opening their schemas.

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

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

The description gives a concrete use case: see which status an issue needs to show up in a given column. It also names alternatives and explains why this tool is preferable when status mappings matter, since sibling board endpoints carry columns without statuses.

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 declare readOnlyHint=true, and the description adds valuable behavioral context beyond that: it explains how to identify the currently running sprint ('status in_progress') and how the returned sprint id should be used downstream. This helps the agent understand the data semantics without contradicting the read-only 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?

The description is two sentences with no filler. The core action is front-loaded, followed by a useful status clarification and a concrete downstream instruction. 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 list operation with a complete input schema and an output schema present, the description covers what an agent needs: how to find the board, what the status field means, which fields are typically sufficient, and how to use the result. No critical information 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 coverage is 100%, so the schema already documents both parameters. The description adds meaningful context beyond the schema by explaining the status semantics for the returned sprints and clarifying the practical use of the id field, which is more useful than the bare field names.

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 a precise action and resource: 'Get all sprints' of 'a specific Yandex Tracker agile board.' It also clarifies that the running sprint is identifiable by status 'in_progress', which further distinguishes the tool's purpose from board-level tools like board_get or boards_get_all.

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 the tool—when sprint data for a specific board is needed—and explicitly connects the output to downstream issue creation/update tools: 'Use the returned sprint id to put an issue into a sprint with the issue_create or issue_update tools.' It does not explicitly discuss exclusions or alternatives, but no direct alternative for retrieving sprints appears among 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 declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral nuance: matching relies on each board's own filter, so boards filtering by other criteria will be missed. This goes beyond the schema and helps set expectations.

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 main action comes first, followed by the key parameter guidance, then an important limitation and workaround. 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 read-only listing tool with a rich schema and output schema, the description covers purpose, usage, a key behavioral caveat, and an alternative route. Pagination and field selection are already documented in the input schema, so nothing essential 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 coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining the queue parameter's behavior (matching against the board's filter) and by suggesting `issues_find` plus the `boards` field as a fallback when queue-based lookup is incomplete.

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 operation: retrieving all agile boards of the organization, with an optional queue filter. It also distinguishes itself from related tools by pointing to `board_get` for reading a single board in full and to `issues_find` for discovering boards via issues.

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 to use this tool (get organization boards, optionally scoped by queue) and provides a practical alternative when a board's own filter does not match. The caveat about queue matching and the recommendation to inspect issues' `boards` field gives concrete 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 readOnlyHint annotation already communicates the non-mutating nature; the description adds that the returned template includes the inserted comment text, which is useful behavioral context. It does not mention not-found or error behavior, but the output schema and simple read-only nature reduce that need.

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 carry the full message: first the core function, then the dependency workflow. There is no filler or redundant restating of the title.

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

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

For a one-parameter, read-only tool with an output schema, the description gives enough context to invoke correctly and understand the primary return content. Minor gaps around error cases exist but are acceptable for this 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 both the schema and description point to comment_templates_get_all as the source of template_id. The description adds no new meaning beyond what the schema already provides, 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 uses a specific verb ('Get'), names the exact resource ('single Yandex Tracker comment template by its id'), and clarifies that the returned object includes the comment text. This clearly distinguishes it from list-style tools like comment_templates_get_all and other template 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 explicitly instructs the agent to call comment_templates_get_all first to obtain the template id, giving the tool a clear prerequisite and placement in a workflow. Since this is a simple single-item fetch, this is sufficient 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 the description adds meaningful behavioral detail: all pages are fetched by default, passing page returns a single page, and templates bound to no queue are included when queue is provided. This goes beyond the annotation without contradicting it.

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

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

Three short sentences with no filler: purpose first, usage context second, pagination behavior third. Every sentence contributes new, actionable information.

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

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

The definition is complete for a read-only listing tool. It covers purpose, usage timing, queue scoping, and pagination; the output schema handles return-value documentation, and the annotation covers safety. No critical guidance 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 coverage is 100%, so the baseline is 3. The description adds value by explaining the queue fallback behavior and reinforcing the default all-pages behavior for the page parameter, which helps an agent choose parameters correctly even when skimming 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: comment templates configured in Yandex Tracker, including their content and associated users/mailing lists. It is a specific verb+resource statement, though it does not explicitly differentiate itself from the sibling comment_template_get beyond the plural 'get_all' framing.

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 practical context: 'Read one before adding a comment' tells the agent when this tool matters, and the queue guidance clarifies scoping. It stops short of explicitly naming alternatives or exclusion criteria, so it does not 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?

The annotation readOnlyHint=false already signals a mutation, and the description is consistent with that, so there is no contradiction. However, the description discloses no behavioral traits beyond the act of creation — no note on duplicate-name handling, permissions, or side effects on the queue's component list.

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

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

A single sentence that front-loads the verb and resource and keeps the domain definition tight. The Russian parenthetical ('компонент') and the trailing lead note are marginal additions but do not bloat the description.

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 5 parameters all documented in the schema, an output schema present, and a readOnlyHint annotation, the structured context is strong, so a short description is acceptable. The clear gaps are the absence of sibling routing (when to use component_update instead) and any disclosure of creation constraints such as duplicate names.

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 each parameter individually explained (e.g., lead's login/uid format, assign_auto's create default, description clearing behavior), so the schema carries the load. The description's only parameter note, '`lead` is a user login', merely restates what the lead schema description already says.

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: 'Create a component ... in a Yandex Tracker queue' and defines the domain concept ('a label grouping the queue's issues by product, process or owner'), which separates it from sibling operations like component_update, component_delete, and component_get. The verb 'Create' plus the container context leaves no ambiguity about what the tool 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?

Usage is only implied by the verb 'Create' and the component definition; there is no explicit statement of when to prefer this over component_update or component_delete, and no exclusions. The parameter descriptions hint at update semantics ('on update, unchanged', 'clear_lead'), which subtly distinguishes create from update, but the description itself gives no 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 mark the operation as destructive, and the description adds the important behavioral detail that the action 'Cannot be undone.' This goes beyond the annotation by emphasizing irreversibility, which is valuable for an agent deciding whether to call this tool.

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

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

The description is two short sentences with no wasted words. The action and target are front-loaded, and the irreversibility warning is concise but essential.

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

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

For a single-parameter destructive operation with annotations and an output schema present, the description covers the necessary details: what is deleted, how the target is identified, and that the operation is permanent.

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% coverage for component_id, including its type and how it is obtained. The tool description adds little beyond restating 'by its numeric id,' so the schema carries the parameter semantics.

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

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

The description uses a specific verb ('Delete') and resource ('Yandex Tracker queue component'), and explicitly states the identifying key (numeric id). It clearly distinguishes this tool from sibling tools like component_update or component_create.

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 clearly indicates this tool is for deleting a component by its numeric id and notes irreversibility. It does not explicitly name alternatives or when not to use it, but the context is clear enough for an agent to select it for deletion tasks.

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?

readOnlyHint=true already communicates safety; the description adds value by naming the returned fields (queue, lead, assignAuto, version) and noting the version is the one component_update consumes. It does not cover missing-id error behavior, but for a simple read with annotations this is a useful and non-redundant disclosure.

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 front-loads the action and resource, then packs the id source, returned fields, and compatibility with component_update. Every clause contributes useful information 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 one-parameter, read-only getter with an output schema and sibling context, the description is complete: it explains what is returned, where the id comes from, and how the result relates to component_update. Nothing essential 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?

With 100% schema description coverage, the schema already documents component_id as numeric and from queue_get_components or an issue's components field. The description repeats this rather than adding new parameter semantics, 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 uses a specific verb (Get), identifies the resource (one Yandex Tracker queue component) and gives the exact identifier type. It distinguishes itself from queue_get_components by emphasizing 'one' component by numeric id, and the sibling list/create/update/delete tools are clearly different operations.

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 clearly states the input required (numeric component id) and where ids come from (queue_get_components or an issue's components field), which tells an agent how to obtain a valid input. It does not explicitly state 'use queue_get_components for listing' or list exclusion cases, so it stops short of a full when-to-use/when-not-to-use guide.

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 readOnlyHint=false annotation, the description discloses important partial-update semantics and the special behavior of `clear_lead`. It does not discuss version-conflict failure behavior, but that is fully covered by the well-described `version` parameter in the schema.

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

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

The description is a single front-loaded sentence that states the action, resource, editable fields, and the most important update semantics. The parenthetical Russian term adds a useful domain cue, and there is no redundant wording.

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 that all seven parameters have rich schema-level descriptions and an output schema exists, the description does not need to repeat parameter details. It provides the high-level behavioral context an agent needs to understand that this is a partial-update operation on an existing component.

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 value by summarizing the cross-cutting rule that omitted fields retain their values and that `clear_lead` is the explicit removal mechanism, complementing the per-parameter schema documentation without repeating it.

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

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

The description names a specific verb ('Change'), a precise resource ('Yandex Tracker queue component'), and enumerates the exact fields that can be modified. This clearly distinguishes it from sibling tools like component_create, component_get, and component_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 clearly frames this as an update to an existing component and states the central usage rule that omitted fields keep their value, with `clear_lead` as an explicit removal mechanism. It does not explicitly name alternatives, but the mutation semantics make it clear this is for updating rather than creating, reading, or deleting.

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 readOnlyHint annotation already covers the read-only nature. The description adds context that the returned fields are global and usable in issues, which is useful. However, it does not describe pagination, ordering, or other behavioral details, though these are less critical for a simple 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?

The description is a single, front-loaded sentence without any fluff. Every word contributes to conveying the tool's purpose.

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

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

Given the zero-parameter, read-only nature and the presence of an output schema, the description fully covers the tool's purpose. It clearly explains what the tool returns and its scope, with no missing critical information.

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 zero parameters, the schema is fully covered. The description adds no parameter-specific semantics, but none are needed. The tool has no input requirements, so the baseline of 4 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 'Get all global fields available in Yandex Tracker that can be used in issues' with a specific verb, resource, and scope. It clearly distinguishes from sibling tools like queue_get_fields by emphasizing 'global' and 'can be used in issues'.

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 does not explicitly mention when to use this tool versus alternatives. The word 'global' implies a distinction from queue-specific fields, but no direct comparison or exclusion is provided. Usage context 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?

The annotation readOnlyHint=true already signals a safe read operation. The description adds that the tool retrieves all issue types for create/update operations, but it does not disclose return format, sorting, or edge cases. Since the schema and output schema provide structural details, the description offers modest additional transparency.

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

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

The description is a single sentence that immediately states the action and resource, with no filler or repetition. It is front-loaded and efficiently communicates the tool's purpose.

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 zero parameters, a readOnly annotation, and an output schema, the description fully covers what the tool does and when it is relevant. It explains the data's usage context, making it complete for an agent to decide when to call this tool.

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

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

The tool has zero parameters and the schema coverage is 100% for an empty properties object. Per rubric, zero-parameter tools receive a baseline of 4. The description adds context about the returned data's purpose but there are no parameter semantics to elaborate on.

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 the specific verb 'Get' and clearly identifies the resource as 'all issue types available in Yandex Tracker'. It further explains the purpose ('can be used when creating or updating issues'), which distinguishes it from sibling tools like get_statuses or get_priorities.

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 states the context for use ('when creating or updating issues'), which implies when to call this tool. However, it does not explicitly name alternative tools or specify when not to use it, so it lacks full exclusionary 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 readOnlyHint annotation already marks this as safe, and the description adds useful non-obvious behavior: the result is organization-wide and a queue may still reject a priority it does not use. It does not overstate mutation or introduce contradictions.

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 states the resource and purpose, the second adds a critical scope caveat. Every sentence earns its place and the main action is front-loaded.

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

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

With no parameters and an output schema available, the description fully covers what an agent needs: what is returned, the accepted field compatibility, and the organization-wide scope. No missing prerequisite or postcondition is apparent.

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 zero parameters and 100% schema description coverage, so there are no parameter semantics for the description to add; the baseline for zero-parameter tools is 4. The description instead clarifies useful output semantics (id/key compatibility with issue_create/issue_update).

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+resource ('Get the issue priority levels of Yandex Tracker') and enumerates example values, making it clearly distinct from sibling lookup tools like get_statuses and get_resolutions. The tie to the priority field accepted by issue_create/issue_update further pins down its 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?

It provides clear usage context by stating the returned id/key are what issue_create and issue_update accept in priority, which tells an agent when to call this tool. It does not explicitly name alternatives or exclusion cases, but the lookup is self-contained and the sibling list contains no competing priority 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?

The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the scope ('all resolutions') and the context ('when closing issues') but does not disclose additional behaviors like ordering, filtering, or response format. This is acceptable for a simple list retrieval with annotations 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 a single, focused sentence that immediately states the action and resource. It is front-loaded with the tool's purpose and contains no unnecessary words 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?

Given the tool has no parameters and the output schema exists, the description is sufficient for an agent to understand the tool's role. The context 'when closing issues' and the scope 'all resolutions' provide complete guidance for this low-complexity read operation.

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

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

The tool has zero parameters, so the schema fully covers the input space (100% coverage). Per the rubric, a no-parameter tool gets a baseline of 4. The description does not need to add parameter details, as none exist.

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 tool's purpose: retrieving all resolutions in Yandex Tracker used when closing issues. It uses a specific verb ('Get') and resource ('resolutions'), and the context 'when closing issues' distinguishes it from sibling tools like get_statuses or get_issue_types.

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 intended use case ('when closing issues'), which helps the agent select it for issue closure scenarios. However, it does not explicitly mention alternatives or exclusions, though the context is reasonably clear among the many sibling getter 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?

The readOnlyHint annotation already covers the safety profile. The description adds a contextual detail that only statuses usable in issues are returned, which is mildly informative. It does not describe pagination, return format, or other behavioral traits, but the output schema fills some gaps.

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

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

The description is a single concise sentence that front-loads the action ('Get all statuses') and provides necessary qualifying context without any fluff. 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 simple, parameterless, read-only tool with an output schema, the description adequately explains what the tool returns. The context of 'available in Yandex Tracker' and 'usable in issues' is sufficient for the agent to use it correctly, and the output schema covers return structure.

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 zero parameters, the schema is empty and schema description coverage is trivially 100%. The baseline for 0 params is 4, and the description does not need to explain any parameters. It appropriately focuses on the tool's purpose.

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

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

The description clearly states it gets all statuses available in Yandex Tracker that are usable in issues, with a specific verb and resource. It distinguishes itself from sibling reference-data tools by naming the exact entity (statuses) and scoping to issue-usable statuses.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as get_issue_types or get_resolutions. It only states what it does, leaving the agent to infer usage from the name. There is no mention of exclusions or alternative 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?

Beyond the readOnlyHint=false annotation, the description discloses important behavioral details: the checklist is created if it does not exist, items are appended in the given order, and the response contains the checklist after addition. This gives the agent a clear model of the operation's side effects and return 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?

The description is concise, front-loaded with the core action, and every sentence adds meaningful information: action, creation behavior, ordering, and return value. There is no redundant or filler 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?

For a tool with two required parameters, a full input schema, an output schema, and readOnlyHint=false, the description is complete enough. It explains the mutation behavior, the ordering guarantee, the auto-creation behavior, and what the caller should expect in the response, so an agent can invoke it correctly without missing key context.

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 schema already documents issue_id format and items as an array with an example. The description adds minor behavioral context ('items are appended in the order given'), but the schema already conveys the same ordering intent in the items description, so the description adds limited value beyond the structured 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 ('add') with a clear resource ('items to the checklist of a Yandex Tracker issue') and clarifies that multiple items can be added. It also specifies the 'one or more items' semantics and the append behavior, making it easy to distinguish from sibling tools like issue_update_checklist_item or issue_delete_checklist_item.

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 through its verb and behavior but does not explicitly state when to prefer this tool over alternatives such as issue_update_checklist_item or issue_delete_checklist_item. It does clarify that the checklist is created on demand, which helps an agent understand the tool's effect, but no explicit 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?

Beyond the annotation readOnlyHint=false, the description discloses meaningful behavioral details: comments are created via this call, '@login' in text does not produce notifications, and notification requires the `summonees` parameter. This gives the agent important side-effect knowledge about who gets notified and how template content should be transferred. It does not state every consequence, but it covers the key non-obvious behavior.

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

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

The description is compact and front-loaded with the core action, followed by two targeted caveats. Every sentence contributes either primary purpose, a template-workflow correction, or a mention-behavior warning. There is 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?

The tool has six parameters, but all are fully described in the schema and the required ones are obvious. The description adds the critical contextual guidance about templates and mention semantics, and the presence of an output schema means return-value details are not the description's responsibility. An agent has enough information to call this tool correctly and avoid the most likely errors.

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 beyond the schema by explaining that there is no `template_id` parameter and that template text should be copied into `text` while template summonees go into the summon parameters. It also clarifies the real-world meaning of `summonees` for mentions, reinforcing and extending the schema's 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 opens with an unambiguous action: 'Add a comment to a Yandex Tracker issue.' This names the exact verb and resource and clearly separates it from sibling operations like issue_update_comment, issue_get_comments, and issue_delete_comment. It also clarifies what the tool is not for by stating there is no `template_id` parameter, preventing confusion with template-related helpers.

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 concrete when-to-use guidance: add comments to issues, and if using a saved template, first call `comment_templates_get_all` with `queue` set, then copy values into `text` and the summon parameters. It also explicitly warns against the common mistake of putting '@login' in the text, directing users to the `summonees` parameter instead, which is a clear exclusion and 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?

The annotation set is minimal (only readOnlyHint=false), so the description carries most of the disclosure burden. It correctly discloses the mutating nature ('Create a link') and adds valuable directional semantics with examples, but it does not address edge cases such as duplicate links, self-links, or side effects. The description is consistent with readOnlyHint=false, so no contradiction.

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

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

Two sentences with zero filler: the action is front-loaded in the first sentence, and the relationship-semantics clarification occupies the second. The examples earn their place because the enum contains genuinely confusing direction pairs.

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 output schema exists, so return values need no explanation, and all three parameters are documented in the schema. The description covers the one subtly tricky aspect (link directionality), which is the main source of agent error here. The only real omission is explicit routing to issue_delete_link/issue_get_links, which is more of a usage-guidance concern.

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%, which sets the baseline at 3. The description adds genuine value by concretely disambiguating the trickiest direction pairs ('depends on' vs 'is dependent by') and defining 'relates' as a plain connection, reducing the risk of reversing link direction. Only three of nine enum values are exemplified, leaving some gap, but the directional principle generalizes.

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 ('Create') and a precise resource ('a link between a Yandex Tracker issue and another issue'), making the operation unambiguous. It is easily distinguished from the sibling issue_delete_link (removal) and issue_get_links (retrieval) without needing to inspect schemas.

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

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

The description implies when to use the tool (whenever two issues need to be linked) and clarifies how the relationship parameter should be read, but it never explicitly names alternatives such as issue_delete_link or issue_get_links or states when not to use this tool. Usage context 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 indicate readOnlyHint=false, so the description's mention of 'Add' aligns. However, no additional behavioral traits are disclosed (e.g., permissions needed, side effects like triggering notifications, or rate limits). The description adds minimal value 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?

A single, direct sentence with no wasted words. It is appropriately front-loaded and provides essential information 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?

Given the 100% schema coverage and existence of an output schema, the description is fairly complete. It lacks mention of error conditions or prerequisites (e.g., issue must exist), but for a straightforward add operation, it is adequate.

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?

All four parameters are described in the input schema (100% coverage). The description does not add new meaning beyond the schema; it merely restates the tool's purpose. Baseline of 3 is appropriate given high schema coverage.

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

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

The description clearly states the action ('Add a worklog entry'), the resource ('worklog entry'), and the context ('to a Yandex Tracker issue'). It effectively distinguishes from sibling tools like issue_delete_worklog, issue_update_worklog, and issue_get_worklogs.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives (e.g., issue_add_comment). It only describes the function without usage context or prerequisites, leaving the agent to infer based on the tool name.

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

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

Annotations only state readOnlyHint=false, so the description carries the behavioral burden. It discloses that the tool mutates state by executing a transition, that it targets 'done' status, that resolution must be valid for the issue type, and that it returns the transitions available in the closed status. This is meaningful behavioral context beyond the 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?

The description is compact: two sentences that lead with the core action and resolution constraint, then state the return value. Every sentence carries needed information without 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?

The definition covers the operation, resolution-selection process, and return value, which is strong for a focused tool with a full schema and output schema. It could be slightly more complete by mentioning what happens if no 'done' transition is available, but 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 coverage is 100%, so the baseline is 3. The description adds important semantic value for resolution_id by explaining it must be allowed by the issue's type and how to discover the allowed values via issue_get and queue_get_metadata. It does not add detail for fields or comment, but the schema already describes those clearly.

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 specific action: closing a Yandex Tracker issue by finding and executing a transition to a 'done' status. It names the exact resource and operation, and the 'finds a transition' detail helps distinguish it from a generic transition tool like issue_execute_transition.

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 procedural guidance: read the issue type, call queue_get_metadata, then provide a resolution allowed by that type. It does not explicitly name alternative tools like issue_execute_transition or state when not to use this tool, but the context and specialized purpose make the intended use clear.

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

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

readOnlyHint=false already marks this as a write operation, and the description adds genuinely new behavioral context: the returned version goes stale at once because queue triggers bump it, plus a concrete mitigation (re-read with issue_get). This goes beyond what the schema or annotations convey. It could additionally disclose permission requirements or side effects like notifications, which keeps it at a 4 rather than a 5.

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, zero filler: the first states purpose, the second covers the template workflow, the third warns about version staleness. The core purpose is front-loaded ahead of the caveats, 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 14-parameter create tool, the schema documents parameters, the output schema covers return values, and the description covers the workflow gotchas an agent would otherwise trip on. The template-argument absence and stale-version behavior are the critical non-obvious pieces, and both are addressed; no blocking information 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 the schema already documents all 14 parameters, putting the baseline at 3. The description adds value by warning that no template parameter exists and instructing the agent to copy fieldTemplates values into the regular arguments field by field — preventing an invocation that passes a nonexistent argument.

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 an issue ... in a Yandex Tracker queue,' with the Russian synonym 'задача' added to remove ambiguity for a term that has multiple meanings. The verb clearly separates it from read/update/close siblings like issue_get, issue_update, and issue_close without needing to open any schema.

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

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

The description gives explicit guidance for the genuinely non-obvious workflow: there is no template argument, so the agent must read a template via issue_templates_get_all and copy its fieldTemplates values into these arguments field by field. It also routes post-create follow-up to issue_get when the version needs re-reading. It does not enumerate when-not-to-use conditions against mutation siblings, but the template case is the one that would actually cause a failed 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 destructiveHint=true, and the description adds useful behavioral detail beyond that: it confirms the operation deletes a single item and states the return behavior, "Returns the issue's checklist after the deletion." This helps the agent set expectations about the side effect and response.

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 carry all the essential information: the action, the prerequisite lookup step, and the return behavior. No filler or redundant repetition 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 tool is low-complexity with two fully documented required parameters, a destructive annotation, and an output schema. The description adds the only practical missing piece—how to find the checklist item ID—and states the return value. Nothing else an agent needs is absent.

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

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

The input schema already covers both parameters thoroughly at 100% coverage. The description adds value by telling the agent exactly how to obtain checklist_item_id via issue_get_checklist, which supplements the schema's static field description with a practical source for the value.

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

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

Description uses a precise verb-resource combination: "Delete a single item from the checklist of a Yandex Tracker issue." It clearly distinguishes this from sibling tools like issue_delete_link or issue_delete_comment by naming the specific checklist-item resource.

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

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

Description provides clear context and a concrete prerequisite: "Use issue_get_checklist to get the item IDs." It does not explicitly mention when not to use this tool or contrast it with checklist update/add alternatives, but the usage context is unambiguous.

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 readOnlyHint annotation (false) already indicates a write operation, and the description's 'Delete' aligns. However, it adds no extra behavioral context such as permanence, permissions, or side effects, which is a gap for a destructive action.

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

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

The description is a single, concise sentence that immediately states the action and resource. No superfluous 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?

Given the low complexity, complete schema, and presence of annotation and output schema, the description is sufficient for the agent to understand the tool's purpose and usage. It lacks some deeper behavioral context, but the overall package is complete.

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

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

Schema coverage is 100% with clear descriptions for both issue_id and comment_id. The description adds no parameter detail, but this is acceptable because the schema fully documents the parameters.

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

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

The description 'Delete a comment from a Yandex Tracker issue' uses a specific verb and resource, clearly distinguishing this tool from siblings like issue_add_comment and issue_update_comment.

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

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

The description clearly states the tool's action and context, making it obvious when to use it. However, it does not explicitly mention alternatives or exclusions, which prevents 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 only provide readOnlyHint=false, so the description must add behavioral context. It adds the workflow hint about using issue_get_links, but does not disclose whether deletion is permanent, requires special permissions, or has side effects. No contradiction with annotations exists.

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

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

Two sentences, directly front-loaded with the purpose, followed by a useful usage hint. No wasted words or redundant 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 delete operation with two well-documented parameters and an output schema, the description covers the essential workflow. Including the prerequisite for retrieving link IDs makes it reasonably self-contained, though a note on irreversibility would add 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 coverage is 100% with clear descriptions for both parameters (link_id 'as returned by issue_get_links' and issue_id format). The description's mention of issue_get_links adds little beyond the schema, so baseline 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 explicitly states 'Delete a link between a Yandex Tracker issue and another issue', combining a specific verb (delete) with a clear resource (issue link). This distinguishes it from sibling tools like issue_add_link (which adds) and issue_get_links (which retrieves).

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

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

The description gives a direct usage prerequisite: 'Use issue_get_links to retrieve the link IDs for an issue.' This tells the agent where to obtain the required link_id and implies this tool is used after retrieval. It doesn't explicitly list exclusions, but the context is clear enough.

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

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

Annotations already indicate readOnlyHint=false, signaling a write operation. The description's 'Delete' verb aligns with this. However, it adds no further behavioral details such as permanence, required permissions, or side effects. Given that annotations cover the basic safety profile and the description is consistent, it provides minimal additional transparency.

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

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

The description is a single sentence with no unnecessary words. It is front-loaded with the verb 'Delete' and the resource, making it easy to scan and understand immediately.

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 a simple delete operation with an output schema and annotations, and the schema fully documents parameters. The description provides enough context for an agent to know what the tool does. It lacks explicit mention of irreversibility or permission dependencies, but for a basic deletion action, the information 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 both parameters (issue_id and worklog_id) are fully documented in the schema itself. The description does not add any extra parameter semantics. Per the rubric, with high schema coverage, the baseline is 3, and the description contributes nothing 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 the specific verb 'Delete' and identifies the resource as 'worklog entry (spent time record)' within a Yandex Tracker issue. This clearly distinguishes it from sibling worklog tools like issue_add_worklog and issue_update_worklog, which perform different operations.

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 usage context clear: it is for removing spent time records from an issue. However, it does not explicitly mention when to use this tool over alternatives or state exclusions, such as permission limitations or inability to delete certain worklogs. Still, the context is unambiguous for a straightforward delete operation.

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 readOnlyHint: false, so the description carries the burden of behavioral context. It adds that invalid transition IDs are rejected and that the tool returns the transitions available in the new status, giving the agent useful post-invocation expectations.

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, front-loaded sentences communicate the action, prerequisite, constraint, and return behavior without extraneous detail. 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?

The description covers the core prerequisite, the API constraint, and the result of a successful call. Since an output schema exists, detailed return-value documentation is unnecessary. A small gap is not distinguishing this tool from sibling issue_close, but the core invocation context is complete.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds meaningful value by emphasizing that transition_id must come from issue_get_transitions and by explaining the consequence of using an invalid ID, 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?

The description clearly states the tool executes a status transition for a Yandex Tracker issue, using a specific verb and resource. It also distinguishes itself from the read-only sibling issue_get_transitions by describing an action that changes state.

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

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

The description gives explicit usage guidance: call issue_get_transitions first and pass one of the returned IDs, warning that the API rejects anything else. It does not mention alternatives like issue_close or when to prefer this tool over other transition-related tools, so it stops short of a full 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 the description consistently describes a read operation. It adds useful behavioral context by stating that the tool returns the full issue record including the current version, which goes beyond the schema's parameter documentation.

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 with no filler. The core purpose is front-loaded, and the routing to alternatives is packed efficiently into the second 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 tool with a readOnlyHint annotation, an output schema, fully described parameters, and explicit sibling differentiation, nothing essential is missing. The description covers purpose, scope, and alternatives without redundancy.

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 (issue_id and include_description) are fully documented with formats and fine print about size. The tool description does not add meaning 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?

Description clearly states a specific verb ('Read') and resource ('one Yandex Tracker issue') and notes it returns the full record including version. It also distinguishes itself from issues_find and the issue_get_* subresource tools, so an agent can tell exactly what this tool 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?

Explicitly directs users to issues_find when searching instead and lists which related resources (comments, links, attachments, worklogs, etc.) have their own issue_get_* tools. This gives clear when-to-use and when-not-to-use guidance with named 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?

The readOnlyHint annotation already covers the safety profile, so the description does not need to restate read-only behavior. The description adds no behavioral context beyond 'by its id' and does not discuss pagination, size limits, or potential for large content, though the schema's fields parameter does warn about the content field.

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 sentence with no filler, front-loads the action and resource, and is easily parsable. Every word contributes meaning.

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

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

For a simple read-only attachment-listing tool, the description combined with the rich input schema, readOnlyHint, and output schema is sufficient. The required input is clear, the optional fields behavior is documented in the schema, and no critical invocation information 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 issue_id and fields are already documented in the input schema. The description reinforces that issue_id identifies the target issue but adds no new semantic value beyond the parameter 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 states a specific verb ('Get'), a clear resource ('attachments'), and the required identifier ('by its id'). This distinguishes it from sibling issue_get_* tools such as issue_get_comments, issue_get_worklogs, and issue_get, since 'attachments' is an unambiguous resource.

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

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

The description implies the tool is used when a caller needs attachments for a specific Yandex Tracker issue, and the issue ID requirement is clear. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, leaving differentiation to inference from the tool name and sibling 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?

The description is consistent with the readOnlyHint annotation and adds valuable behavioral detail beyond it: results are paginated, the response contains a next_cursor, and that cursor must be passed back as the cursor parameter until it becomes null. It also discloses the breadth of events included, such as triggered triggers.

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

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

The description is compact and front-loaded with the core action and expected contents, followed by the pagination contract. It contains no filler, though the first sentence is slightly dense with enumerated 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 the output schema exists, all parameters are documented, and the tool is read-only, the description sufficiently covers scope and pagination behavior. It does not discuss alternative tools or edge cases, but those are not required for correct invocation here.

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

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

Schema description coverage is 100%, so all five parameters are already documented with types, defaults, and examples. The description adds only the pagination loop concept ('next_cursor' passed back as 'cursor' until null), which is a modest enhancement rather than a necessary compensation.

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

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

The description opens with a specific verb and resource ('Get the change history of a Yandex Tracker issue') and enumerates exactly what the changelog contains: status transitions, field edits, comment changes, and executed triggers. This clearly distinguishes it from sibling read tools like issue_get_comments or issue_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 is clear: this is the tool for retrieving an issue's full change history, including who changed what and when. It does not explicitly name alternatives or say when not to use it, but the described scope gives agents enough context to select it appropriately.

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 no behavioral context beyond the readOnlyHint annotation. It does not mention pagination, return format, or error behavior. Since annotations already declare the operation safe, the description provides minimal additional transparency.

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

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

The description is a single sentence that front-loads the action and resource, with no extraneous words. It is concise and well-structured.

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

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

For a simple read-only tool with one parameter and an output schema, the description is adequate to convey the tool's purpose. It doesn't cover edge cases like absent checklist items, but the output schema and annotations cover most operational context, so this is acceptable.

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

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

The input schema already fully documents the single parameter with a clear format example ('SOMEPROJECT-1'). The description's 'by its id' adds no new meaning, so the description does not enhance parameter understanding 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 the specific verb 'Get' followed by the resource 'checklist items of a Yandex Tracker issue' and identifies the input by 'its id'. This clearly states the tool's function and distinguishes it from sibling issue_get_* tools such as issue_get_comments and issue_get_links.

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

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

The description implies usage when checklist items for a specific issue are needed, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. Given the sibling tools for various issue aspects, more explicit guidance would improve this dimension.

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 provide readOnlyHint=true. The description adds meaningful behavioral context: results are paginated, the response includes next_cursor, and callers must loop by passing next_cursor back as cursor until null. This goes beyond the static annotation and clarifies the expected interaction pattern.

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 redundancy. The core purpose is front-loaded, and the pagination instruction is the only additional sentence, earning 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?

Combined with a fully described input schema, an output schema, and readOnlyHint annotation, the description provides everything needed to correctly invoke and paginate through comments. No critical behavioral or usage detail 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 coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds value by connecting 'next_cursor' from the response to the 'cursor' parameter, explaining the pagination workflow that ties parameters together across calls.

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 action ('Get a page of comments') on a specific resource ('a Yandex Tracker issue by its id'). Clearly distinguishes from sibling tools like issue_get_worklogs or issue_get_attachments by naming the exact resource.

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

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

Clear context: this is the tool for fetching issue comments, identified by issue_id. It does not explicitly name alternatives or exclusions, but the resource specificity makes the intended use unambiguous. The pagination instruction ('pass it back as cursor until it is null') also guides multi-page 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 readOnlyHint annotation already signals this is a safe read operation, so the description adds no new behavioral context. It does not clarify whether 'related links' includes incoming and outgoing links or whether link types are returned. The description adds no value beyond the 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?

The description is a single sentence with no wasted words, but it is slightly awkwardly phrased ('issue related links'). It is front-loaded with the main action, so it remains concise and readable.

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

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

For a simple read-only tool with one parameter and an existing output schema, the description is adequate. However, it lacks any clarification on what types of links are returned or whether both directions are included. Given the output schema exists, the agent can infer structure, but some behavioral details are 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 input schema has 100% coverage with a clear description for the required issue_id parameter. The description only says 'by its id', which adds no new meaning beyond the schema. Baseline 3 applies because the schema carries the full 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 it retrieves related links to other issues for a specific issue by its ID. The verb 'Get' and resource 'related links to other issues' are specific, and the resource is distinct from sibling tools like issue_get or issue_get_comments, though it does not explicitly differentiate itself.

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

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

The description provides no guidance on when to use this tool versus alternatives. It gives no context about use cases, prerequisites, or exclusions. The usage is merely implied by the function name and description.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds that it returns a list of available transitions, which is mildly informative but does not disclose additional behavior such as whether the list depends on user permissions or includes all possible transitions.

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 information. It front-loads the purpose and includes the key detail about returning a list of available transitions.

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 lookup tool with one well-documented parameter and an output schema, the description fully covers the context needed to select and invoke the tool. No further behavioral or return-value details are necessary.

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 parameter 'issue_id' is fully described in the schema with format examples, so the description does not need to add parameter details. The description does not go beyond the schema but the schema is sufficient, warranting the baseline score.

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

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

The description clearly states the tool gets possible status transitions for a Yandex Tracker issue, using a specific verb and resource. It distinguishes itself from the sibling tool 'issue_execute_transition' by focusing on retrieval rather than execution.

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 useful for discovering available transitions before performing one, but it does not explicitly state when to use it versus alternatives like issue_execute_transition. No exclusions or alternative tools 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?

The readOnlyHint annotation already indicates this is a safe read operation. The description adds no further behavioral context, such as behavior when the issue ID does not exist, whether the URL is absolute, or if any special permissions are required. The description is essentially a restatement of the tool's name, providing no extra transparency 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 clear sentence, front-loaded with the verb and resource, and contains no superfluous words. It is appropriately concise for the tool's simplicity.

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

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

For a simple one-parameter tool with an output schema and a readOnlyHint annotation, the description is sufficiently complete. It clearly states what the tool does, and the schema documents the parameter. The presence of the output schema covers return value details, so no further elaboration is necessary.

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 provides 100% coverage of the single parameter, including its description with format example ('SOMEPROJECT-1'). The tool description does not add additional meaning beyond what the schema already 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 uses a specific verb (Get), names the resource (Yandex Tracker issue url), and specifies the input method (by its id). This clearly distinguishes it from siblings like issue_get (which likely returns full issue details) and other getter 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 usage when an issue URL is needed, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool names are provided, so the guidance is implicit rather than explicit.

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

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

The readOnlyHint annotation already establishes this is a safe read operation, and the description's 'Get' is consistent with it. The description adds no further behavioral context such as return shape, pagination, or multi-issue support; it even uses singular 'by its id', slightly understating the capability. 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?

The description is a single, front-loaded sentence with no filler. It states the action and resource immediately, and every word is informative. It is appropriately sized for a straightforward retrieval 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?

Given the rich input schema (which documents both parameters and the multi-issue format), the presence of an output schema, and the readOnlyHint annotation, the minimal description is mostly sufficient. The only notable omission is that the description itself does not mention that multiple issue IDs can be queried in one call, though the schema covers that detail.

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

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

Schema description coverage is 100%: issue_ids documents the '<project>-<id>' format and 'Multiple Issue IDs', and fields explains what to include and to omit to get all. The tool description itself adds no parameter detail and its singular 'by its id' is less accurate than the schema's plural description, so it provides no added value beyond the structured 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 the operation ('Get') and resource ('worklogs') for Yandex Tracker issues, distinguishing it from sibling tools that handle comments, attachments, changelogs, or that add/update/delete worklogs. The phrase 'by its id' identifies the key input, though it underrepresents that multiple issue IDs are supported.

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

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

The description provides no guidance on when to choose this tool over alternatives, nor does it mention exclusions, prerequisites, or related tools like issue_get_comments or issue_get_changelog. The only clues are the tool name and the word 'worklogs', so usage 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.