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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that a page is created and that ADF format is used; it does not mention permissions, side effects, duplicate-title behavior, response format, or what happens if the space does not exist. For a mutating tool this is a notable gap.

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

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

The description is a single front-loaded sentence with no filler words. It states the action, target, and format in the most compact way possible.

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 schema covers all parameters, and the description names the operation and format, so the tool is minimally usable. However, there is no output schema and no behavioral guidance about the creation result or prerequisites, leaving some uncertainty for an agent.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description adds only the ADF format detail, which maps to the body parameter, giving a baseline-3 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 states a specific verb ('Создать' = create), a clear resource ('новую страницу в Confluence' = new page in Confluence), and the key format ('формат ADF'). This clearly distinguishes it from sibling tools like confluence_get_page or confluence_update_page.

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 implied by 'создать новую страницу', but the description gives no explicit guidance about when to prefer this over confluence_update_page or when not to use it. No alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It usefully reveals the two-step approach: remote links first, then CQL title search, which is important because title matches may not be linked pages. But it does not mention read-only safety, result ordering, pagination, or other behavioral details.

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. Every word contributes to defining the tool's purpose and method.

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 no annotations and no output schema, this description is thin. It does not explain what the result contains, how spaceKey influences the CQL search, or how limit applies. It gives a usable high-level intent but not enough standalone guidance for a complex call.

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

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

Schema description coverage is only 33%, with only issueKey documented. The description does not explain limit or spaceKey, and its mention of 'Jira issue' mostly reinforces issueKey rather than adding meaning. It therefore fails to compensate for the low parameter documentation coverage.

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

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

The description states a specific verb and resource: 'Find Confluence pages for a Jira issue.' It also names the mechanism ('using remote links, then CQL title search'), which distinguishes it from general Confluence page search tools such as confluence_search_pages.

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 scopes this tool to page discovery tied to a specific Jira issue, giving the agent a clear context for use. However, it does not explicitly name alternatives or state when not to use it, so it lacks the exclusionary guidance 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'get content' and does not mention return format, whether the result is the raw HTML body, whether metadata/version info is included, authentication requirements, or side effects. For a simple read operation this is a noticeable gap.

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

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

The description is a single short sentence with no filler or redundancy. It front-loads the action and resource, and is appropriately sized for a one-parameter 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?

The tool has no output schema and no annotations, so the description should explain what 'content' means and what the agent can expect as a result. It does not mention the returned representation, pagination, or how to locate a page ID. This is incomplete for a tool with no structured output metadata.

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%: pageId is described as a numeric Confluence page ID in the schema. The description merely repeats the ID-based usage without adding extra semantic detail, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Получить' / get), a specific resource (page content), and the access path (by page ID). It clearly identifies the tool's core function and is distinguishable from siblings like confluence_search_pages, 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 offers no guidance on when to use this tool versus alternatives such as confluence_search_pages or confluence_find_pages_for_issue. It does not mention prerequisites beyond stating 'by its ID', nor does it explain what to do when the page ID is unknown.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool gets a list of all spaces, without mentioning pagination, response size, ordering, authentication, or side effects. The read-only nature is only implicit from 'get'.

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 with no filler. It front-loads the action and resource, which is appropriate for a zero-parameter list tool.

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

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

For a simple zero-parameter tool, the description adequately states what the agent will receive: a list of all Confluence spaces. However, since there is no output schema, a bit more detail about response contents or pagination would make it fully 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?

The tool has zero parameters and 100% schema description coverage, so there are no parameter semantics to document. This is the baseline case where no additional description is needed.

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 clear verb and resource: 'Получить список всех пространств Confluence' (get a list of all Confluence spaces). It is distinct from sibling tools, which focus on pages and Jira issues, so an agent can identify this as the space-listing tool.

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

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

There is no guidance about when to use this tool versus alternatives, no exclusions, and no mention of related tools like confluence_search_pages. The usage context is only implied by the verb 'get list' and the resource 'spaces'.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does state the output shape (page IDs and URLs) and 'Search' implies a read-only operation, but it does not describe pagination behavior, result ordering, access scope, or error/empty-result handling. This is adequate but leaves clear 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 front-loaded sentence with no filler. Every word contributes to identifying the action, resource, method, and output, making it an efficient and well-structured definition.

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 basics are covered: required cql, optional limit/start, and output of IDs/URLs are all present. However, with no output schema and no annotations, the description would benefit from more detail about response shape, pagination, and when to prefer sibling search tools. It is usable but not fully 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?

Only the cql parameter has a schema description ('CQL query'), and the tool description adds no parameter-level detail beyond repeating 'with CQL.' With schema description coverage at 33%, the description should compensate for limit and start semantics but does not, leaving the agent to infer from names and numeric constraints.

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 ('Search'), a clear resource ('Confluence pages'), and a distinctive query method ('with CQL'), then states the output ('page IDs and URLs'). This distinguishes it from Jira sibling tools and from Confluence tools like get_page or list_spaces. The CQL qualifier also helps separate it from confluence_find_pages_for_issue.

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

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

There is no explicit guidance about when to use this tool versus alternatives such as confluence_find_pages_for_issue or confluence_get_page. The description implies CQL-based searching but does not state when not to use it or which sibling tool to prefer for different needs.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the page is updated, without revealing whether content is replaced, whether title and body can be updated independently, or what permissions or side effects apply. This is minimal and does not go beyond the basic verb.

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 words. It is concise and communicates the core operation efficiently, though it is sparse on supporting context. The conciseness is good, but the lack of any additional structure barely justifies a perfect score.

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 simplicity of the operation and full schema coverage, the description is minimally viable for invoking the tool: pageId is required, body and title are optional updates. However, there is no output schema and no annotations, and the description does not mention return behavior, prerequisites, or side effects, leaving noticeable gaps for a mutation tool.

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

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

Schema description coverage is 100%, so the input schema already documents all three parameters (pageId, body, title) including that body is in ADF JSON. The description adds no additional parameter semantics, which is acceptable because the baseline of 3 applies when the schema carries the load.

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

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

The description 'Обновить существующую страницу Confluence' clearly states the action (update) and the resource (existing Confluence page), which is specific enough. It does not explicitly differentiate from siblings like confluence_create_page or confluence_get_page, but the word 'existing' gives some implicit distinction, so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives such as confluence_create_page or confluence_search_pages. No conditions, exclusions, or relational context with sibling tools are mentioned. The word 'existing' implies update rather than creation, but this is not made 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the operation without mentioning side effects, permission requirements, idempotency, or what the response contains. It adds nothing beyond the obvious 'add comment' 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 a single short declarative sentence with no filler and the core operation is front-loaded. It is efficiently sized, though it does not enrich the description with any contextual guidance.

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 two-parameter mutation with fully documented schema fields, so an agent can construct a valid call. However, with no annotations, no output schema, and no guidance about behavior or alternatives, the description is only minimally complete for safe and correct invocation.

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

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

Schema description coverage is 100%: both issueKey and body have clear descriptions, so the baseline is 3. The tool description adds no additional meaning beyond mapping 'comment' to body and 'Jira task' to issueKey, so it does not merit a higher 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 uses a specific action verb 'Добавить' (add) and a clear resource 'комментарий к задаче Jira' (comment to a Jira issue). This distinguishes it from read-only siblings like jira_get_comments and other issue mutations like jira_create_issue or jira_update_issue.

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 state when to use this tool versus alternatives, nor does it name any sibling tool. However, the action of adding a comment is clearly implied by the name and description, so usage is inferable rather than completely absent.

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

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

No annotations are available, so the description carries the full burden. It does not disclose side effects, required permissions, or that it is a write operation.

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 with no redundancy. It is front-loaded with the main 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?

The operation is straightforward, but the description lacks information about return values or any special behavior. Given the simple nature and schema coverage, it is minimally sufficient but not fully 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?

The schema provides descriptions for all parameters (100% coverage), so the baseline is 3. The tool description itself adds no further meaning to parameters, so score 3.

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

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

The description clearly states the tool's function: creating a new issue in Jira. The verb 'Создать' (create) and object 'новую задачу' (new issue) distinguish it from update, search, and get operations among siblings.

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. It does not mention scenarios, prerequisites, or conditions; it is merely a statement of function.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only restates the action 'get list of comments' without mentioning read-only guarantees, required permissions, pagination, ordering, or any side effects. The verb 'get' implies a read operation, but no behavioral traits beyond that are revealed.

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

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

The description is a single short sentence with no filler, front-loading the verb and resource. Every word earns its place and nothing extraneous is included.

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

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

The tool is simple with one required parameter and no output schema, so the description need not be lengthy. However, because there is no output schema and no annotations, the description does not clarify what fields the returned comments contain, ordering, or pagination. It is adequate for basic orientation but leaves some ambiguity.

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

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

Schema description coverage is 100%, as issueKey is documented with a clear example ('PROJ-123'). The description text adds no additional parameter semantics 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 states a clear action ('Получить список комментариев' – get list of comments) and a clear resource (comments on a Jira issue), which distinguishes it from sibling tools like jira_get_issue and jira_add_comment. However, it lacks additional scoping details such as whether all comments are returned or if any filtering applies, which prevents a perfect score.

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

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

No guidance is provided about when to use this tool versus alternatives like jira_get_issue or jira_search_issues. The intended use is implied by the name and description, but there are no explicit conditions, prerequisites, or exclusions.

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

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

There are no annotations, so the description carries the burden. It communicates that the operation is a read-only retrieval and outlines the response scope, but it does not mention authentication requirements, potential error cases, or how much data may be returned.

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

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

A single, front-loaded sentence that names the operation and its key return categories without any filler. Every word contributes to understanding what the tool does.

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 single-parameter retrieval tool, the description is largely sufficient: it states the operation and the included detail types. It misses only a brief note on when to use it instead of searching or filtering tools, and with no output schema it could describe the return shape more explicitly.

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 issueKey documented and exemplified as 'PROJ-123'. The description adds no additional parameter meaning, but none is needed because the schema fully 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 uses a specific verb and resource: 'Get Jira issue details' and further specifies included content (parent, subtasks, issue links, remote links). This clearly distinguishes it from sibling tools like jira_search_issues (searching/finding) and jira_get_comments (comments only).

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

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

No explicit guidance is given about when to use this tool versus alternatives such as jira_search_issues. The intended context is only implied by the word 'Get' and the issueKey parameter, not stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly conveys a non-mutating read operation by saying 'get list,' but it does not mention scoping details such as whether only visible/accessible projects are returned, or whether archived projects are included. This is adequate for a simple zero-parameter list tool but not rich.

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

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

The description is a single short Russian sentence that front-loads the action ('Получить список'). It contains no filler, repetition, or unnecessary detail, and is appropriately sized for such a simple tool.

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

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

For a zero-parameter read-only list operation, the description is essentially complete: an agent knows exactly what to call and what to expect conceptually. The lack of an output schema and annotations means return-shape details are not provided, but the operation is simple enough that this is a minor gap.

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

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

The tool has zero parameters and the schema is an empty object, so there are no parameter semantics to document. The baseline for a zero-parameter tool is 4; the description does not need to add anything here.

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

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

The description translates to 'Get the list of all Jira projects,' which clearly identifies the action (list) and the resource (Jira projects), and specifies scope (all). It is distinguishable from the sibling tools, which focus on issues and Confluence spaces, though it does not explicitly name an alternative.

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

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

The description implies the tool should be used when an agent needs the full list of Jira projects, but it gives no explicit when-to-use or alternative guidance. There is no close sibling that lists projects, so ambiguity is low, but the usage guidance remains implicit rather than stated.

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

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

No annotations are provided, so the description carries the responsibility for behavioral context. 'Поиск' clearly implies a read-only operation and no side effects, which is useful. However, the description does not disclose output shape, pagination behavior, or any permissions or limitations beyond what the schema already shows.

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

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

The description is a single, front-loaded sentence with no filler or redundant text. It conveys the essential purpose immediately and wastes no words.

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 JQL search tool, the description plus the fully documented schema covers the core invocation needs. However, with no output schema and no annotations, the description does not mention what the response contains or that results are paginated, leaving some contextual gaps.

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

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

Schema description coverage is 100%, with all three parameters (jql, startAt, maxResults) already documented with descriptions and defaults. The description adds no additional parameter semantics beyond the schema, which matches the baseline of 3.

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

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

Description states a specific action ('Поиск задач Jira') and the exact mechanism ('по JQL-запросу'). This clearly distinguishes it from sibling tools like jira_get_issue, jira_create_issue, and jira_update_issue, which operate on individual issues rather than search.

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 JQL search mechanism implies the tool is for finding issues by query, but the description does not explicitly say when to use it over alternatives or when not to use it. The intended use is inferable from the phrase 'по JQL-запросу', so there is some guidance, but no explicit exclusion or sibling comparison.

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?

Annotation coverage is empty, so the description must carry the full burden. It only says 'update existing issue' and does not clarify whether updates are partial or full replacement, whether permissions are needed, or what side effects occur. This is too thin for a mutating 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 one concise, front-loaded sentence that earns its place. It sacrifices useful behavioral detail, but as a concise statement of purpose it is 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?

Despite full parameter schema coverage, this is a mutation tool with no annotations and no output schema. The description does not clarify update semantics (partial vs full) or prerequisites, leaving an agent uncertain about important call behavior.

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 documented, so the baseline is 3. The tool description adds no extra parameter semantics, but none are needed beyond the schema.

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

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

The description clearly states the action (update) and resource (existing Jira issue), and the word 'existing' distinguishes it from creation tools like jira_create_issue and from read tools like jira_get_issue.

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

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

The phrase 'existing issue' provides clear context that this tool is for modifying an already-created issue, distinguishing it from create/get siblings. However, it does not explicitly name alternatives or when-not conditions, so it stops short of a 5.

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