Fetch and delete job result (free)

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

The description provides rich behavioral detail (deletion after validation, not deleting incompatible or corrupted results, deletion preceding response, failure retains record until TTL). However, the annotations declare destructiveHint: false while the description explicitly says it deletes a stored record, which is a direct contradiction. Per the rubric, this scores 1 and is flagged as an annotation contradiction.

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

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

The description is somewhat lengthy but well-structured: it leads with the main purpose, then details caveats in a logical order. Every sentence carries distinct behavioral or usage information, and the paragraph breaks improve readability. Slightly longer than the minimal two-sentence example but acceptable for the complexity.

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

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

The description covers the full lifecycle: when to use, validation conditions, failure scenarios, TTL behavior, and cost. It also references the response envelope and the detail parameter's cross-tool semantics. Given the presence of an output schema, there is no need to detail return values; the description is comprehensive for this mutating, edge-case-heavy 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 coverage is 100% for all three parameters, so the baseline is 3. The description adds a cross-reference for 'detail' behavior and the response envelope, but these are mostly redundant with the schema descriptions. It does not add significant new meaning for job_id or workspace_root beyond what's already in the schema.

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

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

The description clearly states it fetches a finished background Kimi job's result and deletes the stored record, using specific verbs and resource. It distinguishes itself from kimi_job_result (which presumably only fetches) and other siblings, and defines the exact scope ('finished' jobs) and cost ('Free — no model call').

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 states 'Use only when you no longer need to poll or re-read the job', providing clear when-to-use guidance. It also contrasts with kimi_job_result by noting that incompatible results stay inspectable via that tool, and mentions that non-done jobs are not deleted, offering an exclusion condition.

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