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

No annotations are present, so the description carries the burden of disclosing behavior. It goes beyond the schema by explaining that plain text input is automatically converted to ADF format, which is a non-obvious and important behavior. It could mention persistence or permissions, but the ADF conversion note is substantial.

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 filler or repetition. The primary action is front-loaded, and the key conversion behavior follows 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?

For a simple tool with two required scalar parameters and no nested objects, the description plus schema cover the essential invocation details. It lacks explicit output or alternative-tool guidance, but those are minor gaps for an add-comment 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?

Schema description coverage is 100%, so the baseline is 3. The description adds real semantic value for the body parameter by clarifying that the agent can pass plain text and does not need to compose ADF manually, which goes beyond the schema's simple 'comment content (text)' description.

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

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

The description states a specific action—adding a comment to an issue—and distinguishes itself from sibling tools like update_issue or transition_issue. It also mentions a unique behavior: automatic conversion to ADF format, which adds clarity beyond the tool name.

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

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

The intended use is implied clearly: add a comment to an issue. However, there is no explicit guidance about when to prefer this tool over alternatives or when not to use it, leaving some routing 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 behavioral disclosure burden. It only mentions the API version and bodyHtml format guidance, but does not disclose write/mutation effects beyond the verb 'create', nor does it cover permissions, authentication, rate limits, idempotency, or response behavior. This is a significant gap 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?

Two compact sentences with no filler: the main action is first, followed by API version and a targeted usage hint. 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 3-parameter tool, the description covers the key bodyHtml constraint and API context. However, with no output schema, it does not explain what the API returns (e.g., page ID or URL), which an agent might need to use the result. Overall adequate but not 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%, providing baseline 3. The description adds meaningful value by constraining bodyHtml to simple HTML tags (h2, p, ul, li, table), which helps the agent generate well-formed content beyond the schema's single example.

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: 'Confluence에 새 페이지를 생성합니다' (creates a new page in Confluence). This names both the verb and the resource, but does not explicitly contrast with sibling tools like create_issue, though the 'Confluence' domain distinguishes it from the Jira-centric 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 usage context is implied: this is for creating Confluence pages, and the REST API v2 note plus bodyHtml instructions give some operational guidance. However, there is no explicit 'when to use' or 'when not to use' statement, no mention of alternatives, and no 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?

With no annotations provided, the description carries the full disclosure burden, but it only states that an issue is created and lists required fields. It does not disclose that this is a state-changing operation with persistent side effects, that repeated calls create duplicate issues, or what the tool returns (e.g., created issue key). For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

The description is two short sentences with zero filler: the purpose statement comes first and the requirement note second. Every word earns its place, and the structure 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?

This is a 9-parameter creation tool with nested objects (customFields, labels), no annotations, and no output schema, yet the description is only two sentences. An agent cannot learn the return value, how parentKey/customFields behavior is scoped, or what permissions are needed — the schema alone does not cover these. The description is too sparse for the tool's complexity.

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

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

Schema description coverage is 100%, and every parameter is individually documented with examples (priority values, issueType examples, ADF auto-conversion for description, customFields sample). The description's only parameter information — which fields are required — duplicates the schema's required array and adds no new meaning. Baseline 3 applies since 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?

The description states a clear verb and resource ('새 이슈를 생성합니다' / creates a new issue) and adds the required-field constraint (project key, issue type, summary), which is useful. It does not explicitly differentiate from siblings like update_issue or transition_issue, and the main clause largely restates the tool name, so it stops short of a 5.

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

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

The description gives no guidance on when to use this tool versus get_issue, update_issue, transition_issue, or other siblings. Usage context is only implied by the word 'create' — there is no mention of when creating is preferred over updating or transitioning an existing issue. An agent choosing between these sibling tools gets no routing help beyond 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?

With no annotations, the description carries the behavioral disclosure burden. '조회합니다' communicates a read-only retrieval operation, and 'REST API v3' adds an implementation detail. But it does not disclose authentication needs, error behavior, rate limits, or how expand/fields affect the response; this is minimally transparent but not misleading.

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 the primary purpose front-loaded and no filler. The 'REST API v3' clause is mildly useful but not strictly actionable; it does not bloat the 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?

For a five-parameter read tool with no output schema and no annotations, the description gives the core retrieval behavior but omits response-shape guidance, clearer expand/fields semantics, failure behavior, and usage routing. It is workable for a basic call by ID or key, but it has clear gaps for robust 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?

All five parameters already have descriptions in the schema, and the schema coverage is 100%, so the description does not need to restate them. The tool description only repeats the 'ID or key' lookup concept and adds no semantic meaning 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 a clear verb — '조회합니다' (retrieves) — and a specific resource ('issue detail information') by ID or key. This distinguishes it from siblings like jql_search, which searches for issues rather than fetching a known one, though it never explicitly names 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 lookup condition 'ID 또는 키로' implies that the tool should be used when the agent already knows the issue identifier. However, there is no explicit guidance about when not to use it or when to prefer siblings such as jql_search or get_transitions, so routing 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 provided, the description carries the behavioral disclosure burden. The verb '조회합니다' (retrieves) signals a read-only operation, and '현재 인증된 사용자' indicates the authentication context. It could describe return shape or error behavior, but for a simple self-info endpoint these are minor 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 consists of two short, purposeful sentences. The main function is front-loaded, and the second sentence adds practical guidance without padding 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?

For a zero-parameter tool with no output schema, the description tells the agent what the tool returns (current authenticated user info) and why it might be used (account ID verification). It does not enumerate exact response fields, but that is a minor omission given the tool's low complexity.

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

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

The tool has zero parameters, so the rubric baseline is 4. Schema description coverage is trivially 100%. The description adds no parameter details, and none are needed because there is nothing to configure.

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: it retrieves the current authenticated user's information. It clearly distinguishes this tool from siblings like get_issue, create_issue, and list_projects by focusing on the user identity rather than Jira/Confluence content. The account-ID use case further clarifies 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?

The description explicitly says the tool is useful for checking the account ID, giving a clear usage context. It does not mention alternatives or exclusions, but no sibling tool serves this same purpose, so explicit exclusions are unnecessary.

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 behavioral burden. It indicates a read-only lookup via '조회합니다' and clarifies that the result contains transition IDs for later use with transition_issue. It does not mention auth requirements or empty-list edge cases, but these are minor for a simple read-only list 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?

Two short sentences, each with a clear job: first states purpose, second states when to use it. There is no filler or redundancy, and the key operational detail 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?

For a one-parameter tool with no output schema, the description says enough: it returns a list of possible transitions and tells the agent to extract transition IDs before transitioning. It could add required-permission or empty-list notes, but those are not essential for selecting and calling this 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 coverage is 100%: the only parameter, issueIdOrKey, is already described as the issue ID or key. The description adds no further parameter-level detail, so it stays at the baseline for 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 states a specific action (retrieve a list of possible status transitions) and a specific resource (an issue), and explicitly connects the output to transition IDs used with transition_issue. This makes it clearly distinguishable from siblings like get_issue or transition_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 explicitly tells the agent to use this tool before calling transition_issue to confirm transition IDs, which is a direct usage rule. It also implicitly defines transition_issue as the tool that performs the actual transition, so the agent knows this tool is for lookup only.

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 mentions the API endpoint, not read-only status, pagination behavior, result size limits, or potential rate limiting. For a search tool, agents would benefit from knowing whether this is a safe read operation and how paging works.

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 zero waste, front-loading the primary function (JQL search) and adding the relevant API version. It is appropriately sized for a tool with schema coverage of 100%.

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 parameter details, but the overall description lacks information about return shape, read-only nature, or how pagination interacts with maxResults. For a search tool with no output schema and no annotations, this is a noticeable gap, though not critical for basic 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%, so the baseline is 3. The description adds no parameter-level detail beyond the schema, but the schema itself already documents all five parameters, including defaults and pagination token semantics. No compensation 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 specific verb ('searches'), a resource ('issues'), and the query mechanism ('JQL'), clearly differentiating it from siblings like get_issue (single issue retrieval) and list_projects. The REST API v3 endpoint reference further anchors its scope.

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

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

The description implies usage: use this when you need to search issues with JQL. However, it does not explicitly state when not to use it or name alternatives (e.g., get_issue for single issue lookup), relying on the agent to infer the boundary from sibling names.

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 behavioral disclosure burden. It usefully scopes the result to 'accessible' projects and implies a read-only lookup via '조회'. However, it does not mention pagination behavior, authentication requirements, rate limits, 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?

A single focused sentence states the resource, action, and access scope with no wasted words. The meaning is immediate and easy to parse.

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 and its parameters are fully documented in the schema, but there is no output schema and the description does not describe the return format or pagination details. It is adequate for basic invocation but leaves some ambiguity about what the response contains.

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 in the input schema. The description adds no extra parameter-level context, which is acceptable under the baseline because the schema carries the burden.

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: it retrieves the list of accessible Jira projects. This clearly distinguishes it from siblings like get_issue, jql_search, and create_issue, which operate on different resources or use different mechanisms.

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 the agent needs a list of Jira projects the current user can access. However, it gives no explicit exclusions or alternative tool references, leaving some routing decisions to inference from sibling names.

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 must carry the full disclosure burden. It only states the high-level action and the prerequisite; it does not reveal that the operation is a state mutation, whether it requires permissions, what happens with an invalid transition ID, or what the response contains. The get_transitions reference is a usage hint, not a behavioral 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?

The description is a single sentence with the action front-loaded and the necessary prerequisite immediately after. Every word earns its place; there is no redundancy 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?

For a simple two-parameter mutation with full schema coverage, the description covers the action and the key prerequisite. However, with no annotations and no output schema, it omits side effects, error behavior, and return value expectations. It is adequate but leaves room for richer operational 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 coverage is 100%, so the baseline is 3. The description adds value by clarifying that transitionId must be a valid ID retrieved from get_transitions, giving meaning beyond the schema's terse '전환 ID' label. issueIdOrKey gains no extra meaning, but the transitionId clarification is useful.

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

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

The description states the verb '전환합니다' (transition) and the resource '이슈 상태' (issue status), making the tool's core purpose clear. It does not explicitly contrast with siblings like update_issue, but the notion of transitioning status is distinct enough in context.

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 a clear precondition: '먼저 get_transitions로 유효한 전환 ID를 확인하세요' (first check the valid transition ID with get_transitions). It does not mention alternatives or when not to use, but since this is the only transition tool, the prerequisite is sufficient 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?

There are no annotations, so the description bears the full burden of disclosing mutation behavior. It says 'modifies' and warns about ADF format, but does not clarify whether unspecified fields are preserved, whether customFields replaces the whole object, what permissions are needed, or what the response contains. Much of the ADF note duplicates 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 two concise sentences with the purpose stated first and the critical ADF caution second. Every phrase earns its place; there is 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 mutating tool with 7 parameters, no annotations, and no output schema, the description plus schema is usable but incomplete. It does not clarify partial-vs-full update semantics or how customFields should be structured, both of which are relevant for correct invocation. The get_issue guidance helps but only covers one part of the surface.

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 the get_issue workflow, but does not add new meaning for labels, summary, assignee, priority, or customFields beyond what the schema already states.

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 (modify) and the resource (issue fields). It is distinguishable from create_issue and add_comment, though it does not explicitly contrast with the sibling transition_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?

It provides a concrete workflow: use get_issue to check the current ADF before modifying the description, naming the relevant sibling tool. It lacks explicit when-not-to-use guidance versus transition_issue, but the field-editing context is clear.

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