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

No annotations are provided, so the description carries the full behavioral burden. It confirms this is a write operation but omits whether watchers are notified, whether the comment can be edited or deleted afterwards, permission requirements, or what happens if the issue key is invalid.

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

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

A single short sentence with the verb and resource front-loaded and no wasted words. It is efficient, though its brevity reflects under-specification rather than tight editing of richer 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 simple two-parameter operation with fully documented schema fields and no output schema, the description is minimally adequate. It still leaves the mutation's side effects and success/failure behavior unexplained, which matters given the absence of annotations.

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 both issue_key and comment documented including an example format ('PROJ-123'), so the baseline is 3. The description adds no parameter meaning beyond what the schema already conveys.

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 (add) and resource (comment on a Jira ticket), so the agent knows exactly what it does. However, it offers no differentiation from siblings like get_jira_ticket or update_jira_ticket, which also touch the same ticket 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?

Provides no when-to-use guidance, no prerequisites such as needed permissions or issue existence, and no mention of alternatives. The agent must infer everything about context from the name alone.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the auto-detection behavior and the optional resolution comment, but says nothing about what happens if no 'Done'/'Resolved' transition exists, whether the change is reversible, or any permission requirements.

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

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

Two sentences, front-loaded with the action and its distinguishing mechanism. No filler or redundancy.

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

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

With no output schema and no annotations, the description covers the essential behavior an agent needs to invoke it correctly. The main gaps are failure modes (no matching transition) and permission expectations, which are minor for this scope.

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 three parameters including the auto-detect fallback for transition_name. The description only restates the optional comment, adding no meaning beyond the schema; 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?

States a specific verb and resource ('Mark a Jira ticket as completed/done') plus the distinctive mechanism ('Automatically identifies and executes the Done or Resolved workflow transition'). This implicitly distinguishes it from the generic sibling transition_jira_ticket, which presumably requires an explicit transition target.

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

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

Usage is implied: reach for this when you want to close a ticket and don't want to specify a transition. But the description never states when to prefer it over transition_jira_ticket or list_ticket_transitions, nor any preconditions, leaving the routing decision to inference.

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

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

No annotations are provided, so the description carries the full burden. 'Get' clearly implies a read-only operation, and it names the fields returned, which is useful. However, it says nothing about permissions/auth requirements, rate limits, handling of missing or inaccessible issues, or comment truncation/pagination.

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

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

One sentence, zero waste, front-loaded with the verb and resource and ending with the concrete return contents. Nothing could be cut without losing information.

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

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

With no output schema, the description usefully enumerates what comes back (summary, description, priority, status, assignee, comments), which compensates for the missing return contract. It is nearly complete for a simple single-parameter read, with only error/permission behavior left undescribed.

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 single parameter is already documented with the same 'PROJ-123' example, so the description adds no meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Get detailed information about a specific Jira issue by key') and enumerates the returned fields, so the agent knows exactly what it retrieves. It does not, however, distinguish itself from siblings like get_my_jira_tickets or search_jira_tickets, which the 'by key' phrasing only implicitly separates.

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

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

Usage is implied rather than stated: the key-format example signals you need a known issue key, which routes away from search-based siblings. But there is no explicit when-to-use vs. when-not guidance, no mention of alternatives, and no prerequisites.

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. It usefully discloses that the scope is the authenticated user rather than an arbitrary user, but says nothing about auth failure behavior, whether the profile is cached, or rate limits. Adequate but thin for an unannotated 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?

A single sentence with the resource and return contents front-loaded and zero filler. Nothing could be removed without losing 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 parameterless read with no output schema, the description covers the essentials by listing the returned fields and the scope. It omits error/edge behavior when no session exists, which is the only notable 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?

Zero parameters, so the baseline is 4. The description adds value by enumerating the profile fields returned (name, email, account ID, timezone), which compensates for the absence of any output schema.

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

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

States a specific verb (Fetch) and resource (currently authenticated Jira user profile details) and enumerates the returned fields. The resource is clearly distinct from the ticket-oriented siblings, though the description does not explicitly name that distinction.

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 'currently authenticated user' implies the tool needs an active session and returns the caller's own profile, but there is no explicit when-to-use guidance or exclusion (e.g., that it cannot look up other users by account ID). Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses the non-obvious association semantics (assigned, reported, or mentioned) and implies an authenticated read via 'authenticated user', but says nothing about pagination, result volume, or return shape.

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

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

Two tight sentences; the scope-defining clause is front-loaded and the filtering capabilities follow. The second sentence largely restates what the schema already conveys, so it earns slightly less than full marks.

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 zero required parameters, 100% schema coverage, and no output schema, the description covers the essentials: what is retrieved and how results are scoped. Only the absence of pagination/return-volume context keeps it from being 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?

Schema coverage is 100%, so the schema already fully documents all four parameters including enum values and defaults. The description only paraphrases three of them (status, project, username) and omits max_results, adding no meaning beyond the schema. 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?

States a specific verb (Retrieve) and resource (Jira tickets) with the key scoping qualifier that they belong to the authenticated user, further clarified as assigned, reported, or mentioned. This user-scoping distinguishes it reasonably well from the generic search_jira_tickets sibling, though no sibling is named explicitly.

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

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

The user-centric scope implies when to use it (when you want the caller's own tickets rather than arbitrary search results), but there is no explicit 'use X instead of Y' guidance and no stated conditions or exclusions. Usage is left to inference.

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

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

With no annotations, the description carries the full burden, and 'list all available' does convey a non-mutating read operation. It does not disclose permission requirements, rate limits, or anything about the shape/ordering of returned transitions, so behavioral disclosure is only partial.

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

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

One tight sentence with the resource and scope front-loaded and zero filler. Slight redundancy between 'available' and 'allowable state changes' keeps it from being maximally economical.

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 read tool with no output schema, the description covers the essential purpose and scope; nothing critical to invoking it correctly is missing. Additional detail on the returned transition structure would be a bonus rather than a requirement 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% and the single issue_key parameter is documented with a format example, so the schema does the heavy lifting. The description adds only that the key refers to a 'Jira ticket', which is baseline-level 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?

States a specific verb (list) and resource (workflow transitions) scoped to a Jira ticket, and clarifies the intent ('to check allowable state changes'). It implies a read-only inspection role distinct from the mutating transition_jira_ticket sibling, but never names that sibling explicitly, so an agent must infer the split.

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 'to check allowable state changes' implies the tool is a pre-flight lookup before performing a transition, which is useful context. However, it gives no explicit when-to-use condition or pointer to transition_jira_ticket as the follow-up action.

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

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

No annotations are provided, so the description carries the full burden. It implies a read ("Search") but says nothing about pagination beyond the default, result ordering, error behavior on malformed JQL, or any rate/permission constraints.

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

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

A single front-loaded sentence with zero waste. Efficient, though it spends its brevity budget on restating the schema rather than on 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?

A simple two-parameter read tool with full schema coverage and no output schema, so the description is minimally adequate. The absence of annotations leaves a gap around read-safety and result behavior that a sentence or two could have closed.

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 jql and max_results are already documented with examples and a default. The description only restates that jql is a JQL string, adding no syntax or format value 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?

States a specific verb (Search) and resource (Jira issues) plus the mechanism (custom JQL string). This distinguishes it from get_jira_ticket (single issue) and get_my_jira_tickets (pre-scoped to the current user), though it never explicitly names those 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?

No when-to-use guidance, no prerequisites, and no routing to alternatives such as get_my_jira_tickets for a personal-ticket query. The agent must infer that a custom JQL string is the differentiator.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose that the transition must be valid for the ticket's current workflow state, what happens on an invalid transition, whether permissions are required, or what side effects (comments, notifications, status history) occur. Only the parameter syntax is conveyed.

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 with no waste; the examples are compact and immediately useful for picking the right argument.

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

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

For a state-mutating tool with no annotations and no output schema, the description should explain failure conditions and the discovery path via list_ticket_transitions. Neither is present, leaving the agent under-informed about how to invoke this reliably.

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 three parameters are already documented with examples and the required/optional split. The description's examples of transition names duplicate the schema's own example, adding no new semantics such as whether name or ID is preferred.

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 ('Move') and resource ('Jira ticket') with the scope 'any workflow state', plus concrete transition-name examples. It is clearly distinguishable from read siblings like get_jira_ticket, but it never contrasts itself with the overlapping complete_jira_ticket, which also lands tickets in 'Done'.

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 on when to choose this over complete_jira_ticket or update_jira_ticket, and no mention of the sibling list_ticket_transitions, which is presumably the prerequisite for discovering valid transitions. The agent is left to infer the workflow.

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 behavioral burden. It states that fields are edited and a comment can be optionally posted, but says nothing about partial-update semantics (are omitted fields left alone?), permission requirements, or what errors occur on an invalid issue key. 'Optionally post a comment' is the one helpful behavioral note.

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 with no filler; the action and affected fields come first. It is arguably slightly under-specified rather than wasteful, but structure is clean.

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 7-parameter mutation tool with no annotations and no output schema, the description covers what fields exist but omits partial-update behavior and failure modes. With schema coverage at 100% the parameter side is covered, leaving a moderate behavioral gap.

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

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

Schema description coverage is 100%, so each of the 7 parameters is already documented in the schema, including the assignee empty-string unassign rule and the issue key format. The description only echoes the field list and adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description names a specific verb (Edit) and resource (existing Jira issue) and enumerates the editable fields, so an agent can distinguish it from siblings like get_jira_ticket or complete_jira_ticket. It doesn't explicitly contrast itself with transition_jira_ticket or add_jira_comment, which is why 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 statement of when to use this tool versus alternatives, despite the sibling set containing add_jira_comment (overlapping with the `comment` field) and transition_jira_ticket (a different kind of mutation). The agent must infer that this is for field edits on an existing issue.

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