Get Task Status

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, covering safety. The description adds behavioral context by exposing the status values (pending, in_progress, completed, failed), which imply asynchronous task processing. This is useful beyond the annotations, though the return field list is likely duplicated in the output 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 well-structured and front-loaded with the primary purpose. However, the Args and Returns sections largely duplicate the input and output schemas, which reduces the efficiency. It is still concise enough for a simple tool, but some content could be trimmed without loss.

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 status-polling tool with a single parameter and an existing output schema, the description provides sufficient detail on the returned fields, including status and progress. It is slightly incomplete in that it does not mention the asynchronous nature explicitly, but the status values imply it. Overall, it is complete enough for an agent to invoke the tool correctly.

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

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

The input schema fully documents the single parameter (task_id) with the same description as in the Args section. Since schema coverage is 100%, the description adds no additional semantic value beyond what the schema already provides, aligning with the baseline score 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?

The description clearly states the tool's function: to query task status ("작업 상태를 조회합니다"). This is a specific verb and resource, and it distinctly differentiates from sibling tools like blog_start_draft, blog_apply_feedback, and blog_finalize_draft, which all perform actions rather than status queries.

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 or provide alternatives. The context of sibling tools implies it is meant for checking the status of asynchronous operations (e.g., after starting a draft), but this is only implied, not directly communicated. There is no guidance on when not to use it or how it fits into the workflow.

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