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

Beyond the readOnlyHint annotation, the description discloses that no model call is made, that responses are cacheable via fingerprint, and that certain detail modes restate data the client already has. It also explains the fallback behavior for resource-blind clients and clarifies that parameter-contracts is a contract document, not a JSON 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 long but front-loaded with the core purpose, cost, and caching behavior. The detail-mode explanations are dense and information-rich, with each sentence adding a distinct fact. It could be tightened slightly, but the structure makes the complexity navigable.

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 output schema exists and annotations cover read-only safety, the description provides everything an agent needs to call this tool correctly: purpose, cost model, caching, detail-level tradeoffs, include_schemas behavior, and fallback rationale. No significant gap remains.

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 documents both parameters. The description adds meaningful nuance beyond the schema: which tools get async_lifecycle, that 'full' restates existing data, and that include_schemas is an opt-in fallback sourced from kimi:// resources. This helps an agent reason about payload tradeoffs.

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 opens with a specific verb and resource: 'List this server's tools, tiers, and the result fingerprint.' It clearly distinguishes this from the sibling tools by emphasizing that it is free, caching-friendly, and returns capability metadata rather than status, models, or job operations.

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 strong usage context: it is free, makes no model call, and is designed for clients to cache by fingerprint. It also explains when to use different detail modes and when to pass include_schemas, though it does not explicitly name sibling tools as alternatives or provide when-not-to-use conditions.

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?

Discloses far beyond the annotations: the read-only agent profile (no shell/write tool), the static-review limitation ('treat findings as unvalidated claims you verify yourself'), data egress of question and extra_context to the provider, best-effort redaction that does not cover typed inputs or files Kimi reads, AGENTS.md auto-loading with skills that can point outside the workspace, and timeout termination with unrecoverable partial output. The readOnlyHint=false annotation is consistent — the tool is read-only for files but is PAID and makes external calls — so the description adds context without contradicting the annotations.

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?

Front-loaded with purpose, then cost, safety, data flow, and recovery — each paragraph carries a distinct critical topic with no filler. It is long (~380 words), but the length is largely earned given 9 params, paid quota, and external egress; minor redundancy exists where the description restates schema-level isolation/redaction notes.

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 high-complexity tool (paid external call, 9 parameters, blocking timeout, async fallback, data egress), every operational concern is covered: preconditions, cost, safety profile, data handling, redaction limits, timeout/recovery, and when to route to the async sibling. The output schema covers return values, so the 'result envelope' mention suffices.

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% with rich per-parameter descriptions, so the baseline is 3; the description adds operational value on top: workspace_root targeting decision ('omit it for pure Q&A'), clamp/default semantics for timeout_seconds (10-600s, 300s default), isolation's non-suppression of built-ins/AGENTS.md, and redaction bounds for extra_context. It also cross-references kimi://params rather than duplicating full lifecycle details, which 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?

Opens with a specific verb+resource: 'Ask Kimi (a different model) for a read-only second opinion or answer,' which pinpoints the tool's role as a cross-model consult and distinguishes it from every sibling (not status, not delegate, not review_changes). It further disambiguates from kimi_consult_async by framing this as the synchronous, paid variant.

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?

Explicit preconditions and routing: 'run kimi_status (free) first to confirm the CLI is installed and authenticated,' and it states the no-dry-run limitation. For long or high-effort consults it names kimi_consult_async as the preferred alternative with concrete deadline numbers (300s vs 1800s), and provides a recovery chain via kimi_job_list/kimi_job_status/kimi_job_result. It also tells the caller when to pass workspace_root vs omit it.

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?

Annotations only provide coarse flags (readOnlyHint=false, idempotentHint=false), but the description reveals substantial behavioral context: it is paid and spends quota on every call, has no dry-run, commits to spend once started, has a separate 1800s default deadline, sends raw and unredacted inputs, auto-loads AGENTS.md, and has best-effort secret redaction. The phrase 'read-only' refers to Kimi not editing files, so it does not contradict readOnlyHint=false; the tool still has job and quota side effects.

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 long but appropriately so given the tool's side effects, cost, and lifecycle. It is front-loaded: purpose, paid warning, and sync-vs-async tradeoff appear first, followed by job lifecycle and data egress. Each paragraph adds necessary information and none is 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?

The description covers purpose, cost, deadline behavior, lifecycle tools, data egress, workspace resolution, redaction limits, and parameter caveats. Since an output schema exists, return-value details are not needed in prose. An agent has everything needed to decide whether to call this tool and how to handle the resulting job.

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 parameters and the baseline is 3. The description adds valuable operational semantics beyond the schema, especially for question and extra_context (sent raw and unredacted) and workspace_root (fallback to server cwd when MCP roots are unavailable). This extra context justifies a 4.

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 opens with a specific verb and resource: 'Ask Kimi for a read-only second opinion in the background; get a job_id back immediately instead of blocking.' It also explicitly differentiates from kimi_consult by noting the same read-only behavior but detached execution. This makes the tool's purpose and distinction from siblings immediately clear.

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 explicit when-to-use guidance: prefer this async variant for high-reasoning_effort or broad repo-grounded consults that may exceed the 300s synchronous deadline. It also prescribes the surrounding workflow: run kimi_status first, poll kimi_job_status, consume via kimi_job_result, and cancel with kimi_job_cancel. This is strong routing and lifecycle 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?

The description goes far beyond annotations. It discloses the paid/quota cost, the non-blocked network and lack of sandbox, execution with the user's own privileges, that AGENTS.md and skills are loaded even with isolation settings, raw input exposure, best-effort redaction limits, timeout/deadline behavior, and non-recoverable partial output. Annotations already mark readOnlyHint=false and openWorldHint=true, and the description expands on that meaningfully.

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 dense and information-rich, with critical facts front-loaded: the headline diff-not-applied behavior, the paid cost, and the free alternatives. It is longer than average, but every section covers high-stakes facts an agent needs before invoking a paid, un-sandboxed, potentially network-accessible tool. Slight structural improvement could consolidate the warnings, but overall it is well organized with clear topic shifts.

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 tool's genuine complexity, a high-stakes paid model delegation with 8 parameters, no sandbox, and many sibling alternatives, the description covers prerequisites, cost, security boundaries, failure modes, timeouts, recovery paths, and routing to async variants. An output schema exists, so the description need not enumerate return values. This is as complete as an agent could reasonably need.

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 each parameter. However, the description adds context beyond the schema, especially for workspace_root (MCP roots unavailable, fallback to server cwd, workspace_warning), isolation (built-ins load either way), idempotency_key (scoped to tool+workspace, replay semantics, conflict refusal), and timeout_seconds (clamping behavior). It also explains how parameters relate to runtime behavior (e.g., timeout_seconds bounds the run, not necessarily the inline wait).

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 (delegate), resource (a coding task to Kimi), and the key behavioral outcome (a reviewable diff that is not applied to the tree). It is clearly distinguished from siblings by naming alternatives like kimi_delegate_dry_run, kimi_status, and kimi_delegate_async.

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 when to use the tool (when you want Kimi to implement a coding task and inspect the diff before applying), when to avoid it (for mere scope/readiness checks, use kimi_delegate_dry_run/kimi_status), and when to use an alternative (kimi_delegate_async for substantial tasks likely to exceed the deadline). It also notes the workspace_root requirement and the prerequisite of a git repo with at least one commit.

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?

The description discloses far more than annotations could: it is paid, spends quota on every new call, runs without a sandbox, can push/fetch/install with user privileges, sends the raw task to the provider, reads tracked files, auto-loads AGENTS.md, and only best-effort redacts secrets. It also explains that the job runs to completion or its deadline even if never polled. No contradiction with annotations exists.

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?

Despite being long, every sentence earns its place: purpose is front-loaded, then cost, sync-vs-async tradeoff, lifecycle, requirements, network risk, data handling, and redaction limits. The paragraph structure uses bold semantic labels and makes the critical operational and safety facts scannable without fluff.

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 that this is a paid, asynchronous, side-effectful operation, the description is operationally complete. It covers what is returned (job_id), how the result is delivered (reviewable diff not applied), how to poll/consume/cancel, prerequisites (git repo with at least one commit), deadlines, sandbox absence, and data exposure. An output schema exists, so return-value details are not the description's burden.

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 each parameter is already well-documented in the schema. The description reinforces key usage points such as passing an absolute workspace_root and using idempotency_key to replay without new spend, but it does not add substantial new parameter-level meaning beyond the schema's own descriptions.

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?

Opens with a specific verb-plus-resource statement: 'Delegate a coding task to Kimi in the background and get a job_id back immediately.' It clearly separates this from kimi_delegate (sync) and explicitly names related sibling tools for follow-up, so an agent can distinguish it without opening schemas.

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?

Gives explicit when-to-use guidance: prefer this for substantial/multi-file tasks that may exceed the 300s sync deadline, and use free tools (kimi_delegate_dry_run, kimi_status) first for scope/readiness checks. It also names the companion tools for polling, consuming, and canceling, leaving no ambiguity about the operational 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?

The description goes well beyond the readOnlyHint annotation by detailing exactly what happens and what does not: no model call, no spend, no worktree created. It also transparently explains subtle return semantics — tier/sandbox describe the previewed run, overrides are unvalidated, and deadline_advisory is only a hint — which prevents misinterpreting the tool's output.

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 long, but it is information-dense and front-loaded with the most critical facts (free, no model call, no spend, no worktree). The caveats about tier/sandbox, overrides, and deadline_advisory are valuable and earn their place, though a slightly tighter structure would improve scannability.

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 preview tool with an output schema, the description completely covers the behavioral contract: what is previewed, what is not, validation parity with the paid call, and the meaning of special return fields. It even resolves potential confusion about deadline_advisory naming the async counterpart. Nothing critical is missing.

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?

Input schema description coverage is 100%, so the schema already fully documents every parameter. The description adds useful context about the previewed call's resolutions, but it does not need to compensate for schema gaps. Baseline 3 is appropriate 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 identifies a specific action ('Preview what a kimi_delegate/kimi_delegate_async call would do'), names the exact resources involved (HEAD commit, file counts, prompt size, workspace/isolation), and distinguishes this tool from related siblings like kimi_dry_run. The 'exactly as kimi_dry_run previews kimi_review_changes' analogy makes the purpose immediately recognizable.

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 says explicitly when to use it: 'Use it before delegating to confirm scope and repo before committing to cost.' It also states that a failure here mirrors a failure the paid call would hit, giving the agent a concrete preflight decision rule. It names the paid counterparts (kimi_delegate/kimi_delegate_async) and the analogous dry-run sibling.

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?

Annotations already declare readOnlyHint: true, so the 'Free — no model call, no spend' claim is consistent. The description goes beyond the annotation by detailing effective behavior: would_call_model is False on empty diff, prompt_bytes is 0, coverage discloses omitted untracked files, model/reasoning_effort are echoed unvalidated, and deadline_advisory is non-null only when size/effort risks the synchronous deadline. This meaningfully explains what the call will do and what side effects (none) it has, though some behaviors are described at a high level. No contradiction with the read-only/hint annotations exists.

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 long but informational; it front-loads the core purpose in the first sentence and the free/no-spend trait. Each sentence adds a distinct behavioral fact (would_call_model, coverage, unvalidated overrides, deadline_advisory). It is not tautological or bloated, but it is verbose and could be tightened around the deadline_advisory/async sentence. The structure earns a 4 not a 5 because some sentences are dense enough to require rereading, though all of them earn their 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?

The description is complete for an agent to invoke correctly: it names the sibling alternatives, explains the free/read-only behavior, explains the return value semantics (would_call_model, prompt_bytes, coverage, deadline_advisory) even though an output schema exists, and it adheres to the annotation profile. For a 10-parameter tool with 100% schema coverage, the description fills the gaps the schema can't — when to use it, what the preview can't guarantee (redaction), and how parameters should be passed to match the paid call. No missing information for selecting or invoking this tool is apparent.

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 every parameter. However, the description adds important cross-parameter guidance: 'Pass the same extra_context and untracked policy you would give the review so the preview matches it', and it explains that model/reasoning_effort mirror the paid call's defaults. It also explains the relationship between deadline_advisory and would_call_model, which the schema alone does not convey. Slightly above the baseline 3 because the description explains how parameters interact, though it does not restate individual parameter meanings from 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 states a specific verb ('Preview what a kimi_review_changes call would send') plus a concrete resource (the review call's scope, diff size, redactions, truncation). It names the sibling it is not ('async counterpart of the previewed call, not of this dry-run tool') and distinguishes it from kimi_review_changes. This allows an agent to tell it apart from both the paid review and the dry-run sibling without opening schemas.

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 'Use it before a review to inspect the scope and the reported redactions', provides a concrete precondition, and warns about the redaction limitation. It also says to 'Pass the same extra_context and untracked policy you would give the review so the preview matches it', which is a direct how-to for correct invocation. The 'not a refusal' closing phrase clarifies the advisory hint semantics, further guiding use.

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?

The description discloses far beyond the annotations: the graceful-shutdown-then-force-kill lifecycle, teardown of a throwaway worktree, non-resumability of cancelled jobs, cleanup_warnings for leftover paths, idempotent retry safety, and the 'free — no model call' cost profile. This aligns with and enriches readOnlyHint=false and idempotentHint=true with no 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 purpose is front-loaded in the first sentence, and each subsequent sentence earns its place by covering a distinct behavioral facet: shutdown process, force-kill fallback, non-resumably, cleanup warnings, idempotency, and cost. It is dense but not bloated; only a small trim would tighten it further.

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 a 100%-covered schema, an output schema present, and annotations covering idempotency and destructiveness, the description still adds substantial context: lifecycle, edge cases (terminal jobs, cleanup failure), and retry safety. The only untold edge case is behavior for a genuinely unknown job id, which is a minor gap given how much is already covered.

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 schema itself is unusually rich: job_id explains where to find it and how to recover lost ids via kimi_job_list, and workspace_root explains the MCP-roots fallback and workspace_warning behavior. The description adds no parameter-level meaning beyond the schema, so the 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?

The opening sentence states a specific verb (Cancel) and resource (a running background Kimi job), making the tool's function immediately unambiguous. It is plainly distinct from sibling tools like kimi_job_status, kimi_job_result, and kimi_job_list, none of which perform cancellation.

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 clear usage context: it applies to running jobs, and the statement that already-terminal jobs are returned unchanged effectively defines when the tool adds no value. It explicitly names kimi_job_list as the recovery path for lost job ids. It stops short of an explicit when-not statement against sibling status/result tools, but cancellation is unique among the siblings, so little exclusion guidance is needed.

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?

The prose is extremely transparent: deletion conditions, ordering relative to the response, TTL retention on failed removal, and non-done behavior are all described. However, the annotations declare destructiveHint=false while the description says the tool 'deletes the stored record' and 'removes completed job state.' This is a direct contradiction, so the dimension must be scored 1 per the rubric.

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 long but information-dense; every sentence contributes a distinct operational fact. It front-loads the core purpose and then uses a tight paragraph for deletion semantics, making the structure appropriate for the behavioral 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?

Given the output schema exists and the input schema is fully documented, the description covers all the remaining behavioral context an agent needs: when deletion happens, what is retained on incompatible/corrupt results, what happens if removal fails, and that non-done jobs are untouched. Nothing material is missing.

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 already documents all three parameters, including the detail enum's summary/full semantics and job_id provenance, so schema coverage is 100%. The description adds minimal parameter-specific meaning beyond a cross-reference to kimi_job_result for detail; it does not need to compensate, so 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?

The description opens with a specific verb-resource pair: 'Fetch a finished background Kimi job's result and delete the stored record.' It also distinguishes itself from the sibling kimi_job_result by emphasizing deletion and one-shot consumption, so an agent can tell them apart immediately.

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 explicitly states when to use it ('Use only when you no longer need to poll or re-read the job') and what it does not do ('Non-done jobs are not deleted'). It names the analogous envelope of kimi_job_result and clarifies the free/no-model-call behavior, giving clear selection context among siblings.

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?

Goes far beyond the readOnlyHint annotation by disclosing TTL/eviction behavior, the soft cap of 50, eviction order, running-job exemption, truncation behavior, filter independence, and inclusion of sync-originated records. This is rich behavioral context that annotations alone do not provide.

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?

Long but dense and front-loaded with purpose and cost. Each paragraph covers a distinct behavioral concern, and there is no filler or repetition beyond what is needed to prevent common misuse. The structure earns its length.

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?

Provides everything an agent needs to call and interpret this tool correctly: return field overview, defaults, filter interactions, truncation semantics, expiry/eviction caveats, and a pointer to kimi_job_status for result_ok interpretation. With an output schema present, detailed return values are handled elsewhere, so no critical gap remains.

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?

Although schema descriptions already cover all three parameters, the description adds crucial semantics not visible in the schema: limit and status narrow independently, omitted limit returns every matching job, a single explicit limit truncates and drops rows rather than paging, and there is no cursor to follow. This materially improves correct invocation.

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 exactly what the tool does: lists background jobs for a workspace, newest first, and explicitly notes it is free with no model call. It also names the key returned fields and implies the distinction from sibling job tools by saying stored failures are triageable without fetching each result.

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?

Gives a concrete use case: recover job_ids lost across context compaction or interruption. It also references kimi_job_status for result_ok semantics and advises reading results promptly, which implies when deeper inspection is needed. It does not explicitly tell the agent to use kimi_job_result for full results, so a small exclusionary detail is missing.

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?

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: the call does not delete the record, failure modes include job_result_incompatible for unreadable stored results, the envelope matches the job kind so callers should branch on 'tool', and the operation is free with no model call. These details go well beyond the annotation alone.

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 front-loaded with the core behavior and non-destructive guarantee, then efficiently covers usage conditions, failure modes, and the alternative deletion tool. Every sentence adds distinct value, and the detail parameter behavior is explained compactly.

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 presence of an output schema, the description need not restate return values. It covers when to call, what kinds of jobs are supported, how to branch on the result, failure scenarios, the deletion alternative, and the detail option, making it fully contextual 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%, and the schema already documents job_id, detail, and workspace_root with equivalent semantics. The description reinforces the 'summary'/'full' detail distinction but does not materially add parameter meaning beyond what the input schema provides, so a baseline score 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 uses a specific verb and resource: 'Fetch a finished background Kimi job's result WITHOUT deleting the record.' It clearly distinguishes itself from kimi_job_consume_result and enumerates which async/sync job kinds it applies to, making sibling differentiation straightforward.

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 when to use this tool ('Use when kimi_job_status reports result_available=true'), when not to use it (running/cancelled/timed-out/failed jobs), and which alternative to prefer when deletion is desired (kimi_job_consume_result). This leaves no ambiguity about tool selection.

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?

Despite readOnlyHint=true, the description adds substantial non-obvious behavior: result_ok's three-state semantics, the possibility of job_result_incompatible on cross-release records, poll_after_ms backing off, expires_at lifecycle, and ttl retention. It also notes it is free/no model call. No contradiction with annotations.

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?

Long but dense and front-loaded: purpose, then usage, then state semantics, then polling protocol. Every sentence carries behavioral or routing information; the parentheticals ('a delegate often runs ~20s') are relevant, not 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 polling/status tool with complex lifecycle semantics, the description covers the full call path (when to poll, what fields mean, when to escalate to kimi_job_result, edge cases like incompatible payloads). Output schema exists, so return-value detail is not required 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?

Input schema coverage is 100% and both parameter descriptions are already complete; the tool description restates job_id's origin but adds no new meaning for the input parameters. The poll_after_ms discussion is output behavior, not an input parameter, so 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?

The first sentence uses a specific verb and resource ('Check a background job's lifecycle state') and immediately differentiates from kimi_job_result with 'without fetching the full result.' It also names the async/sync origins of job_id, making it unmistakable which call is being described.

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?

Explicitly says to use after any *_async call or sync consult/review/delegate whose meta.job_id names the record, tells the agent to call kimi_job_result when result_available is true, and instructs honoring poll_after_ms. This is clear when-to-use guidance with named alternatives.

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?

Beyond the readOnlyHint annotation, it discloses the data source (on-disk cache vs bundled fallback), that the fallback lacks effort data, that the real CLI/backend validate values, and that the payload is identical to kimi://models while not being fingerprint-stable. This is far more behavioral context than the annotation provides.

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 core statement is front-loaded and every sentence adds information, but the middle sentences are dense with caveats and parentheticals (cache source, fallback data, validation behavior). It is efficient but slightly more complex than necessary.

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 parameters, an output schema present, and a readOnly annotation, the description covers all decision-relevant behavior: free/no call, sources, validation caveats, payload equivalence, and cacheability. Nothing needed for correct invocation is missing.

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 there is nothing to document; baseline is 4. The description still adds relevant semantic value by explaining how the returned slugs/effort values are meant to be used as `model` and `reasoning_effort` in other calls.

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 starts with a concrete verb and object: 'List Kimi model slugs you can pass as `model`' and specifies the output includes each model's advertised reasoning-effort set for `reasoning_effort`. This makes the tool's function unambiguous and clearly distinct from siblings like kimi_status or kimi_capabilities.

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 clear context: 'Free — no model call', 'Advisory discovery only', and warns not to cache by fingerprint. It does not explicitly name alternative tools or state when not to use it, so it stops just 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.

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

Despite annotations only giving readOnlyHint=false/openWorldHint=true/idempotentHint=false/destructiveHint=false (no safety assertions), the description discloses extensively: it spends Kimi quota, sends the diff to the provider, secret-redaction is best-effort and does NOT cover extra_context or user inputs, AGENTS.md and skills are auto-loaded regardless of isolation, results can be lost on timeout (not recoverable/resumable), and review_status/coverage disclose partial/not_run states. It even explains that skill names/descriptions are exposed to the model before the prompt. This significantly enriches beyond annotations and surfaces the risk profile clearly. No 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 long but every paragraph earns its place: pricing/quota, scope, egress/privacy, progress/recovery, and limitations are all substantive and non-redundant. It is structured with bold labels (scope, Data egress, Progress & recovery) and front-loaded with the most decision-critical facts (PAID, free alternatives). It loses one point because the volume of detail, while valuable, is dense enough that a quick-skimming agent might miss the egress warnings embedded in the middle; a brief upfront risk summary would improve scanability.

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 13 parameters, 0 required, an output schema, and a rich sibling set, the description is exceptionally complete: it covers cost, egress/privacy, timeout behavior, async alternatives, dedup semantics, result disclosure semantics (review_status/coverage, not_run), and the read-only/static limitation. The only minor gap is not describing the output schema's structure, but the presence of an output schema plus the description's statements about top-level review_status/coverage makes that unnecessary. Nothing an agent needs to correctly select or invoke this tool is missing.

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 baseline 3. The description adds substantial compensating value on top: it explains scope semantics (working_tree vs branch vs commit), untracked policy behavior, timeout clamping (10-600s), idempotency_key replay/refusal rules, and that workspace_root avoids fallback to server cwd. It also flags that extra_context is sent raw/unredacted and that isolation does not suppress built-in skills/AGENTS.md. This goes well beyond what the schema's individual parameter descriptions provide.

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 ('Review git changes') and resource ('git changes'), and immediately contrasts it with siblings: 'PAID — this spends Kimi quota on every new call; use kimi_dry_run or kimi_status...'. It distinguishes from kimi_review_changes_async (prefer for long runs), kimi_consult/kimi_delegate (different Kimi interactions), and explains what it actually does (gathers diff, secret-redacts, bounded, read-only review). This makes the tool's purpose and scope unmistakable.

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 provides when-to-use guidance: 'use kimi_dry_run or kimi_status (both free) first if you only need to check scope or readiness', 'prefer kimi_review_changes_async ... for a multi-file or whole-branch review that may exceed it', and describes the recovery path via kimi_job_list→kimi_job_status→kimi_job_result. It also explains scope selection semantics, workspace_root necessity, and extra_context usage. This is comprehensive routing guidance with exclusions (e.g., 'STATIC review, not a verify mode: ... cannot run the project's checks').

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?

Beyond the annotations, the description discloses spend, zero-spend error cases, the 1800s job deadline, best-effort secret redaction, egress of raw extra_context, AGENTS.md auto-loading, and skill discovery. The 'read-only behavior' clause is consistent with readOnlyHint=false because the tool creates a job and spends quota; the description clarifies that the review itself does not modify the code.

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 dense and front-loaded with the core async behavior, cost, and free alternatives. It is somewhat long and contains a broken sentence ('Kimi may also' followed by 'Kimi auto-loads'), plus minor redundancy around spend, but nearly every sentence carries material 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?

For an 11-parameter paid async tool, the description covers the full job lifecycle, cost model, failure modes, data-egress boundaries, timeouts, and relationships to all relevant sibling tools. Output shape is delegated to the existing output schema, so nothing critical is missing.

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 documents all 11 parameters. The description adds useful runtime semantics: bad base/commit yields a structured error with zero spend, bad scope is rejected before the job starts, workspace_root should be passed, and inputs are sent raw/unredacted.

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 first sentence states a specific action ('Review your git changes in the background') and immediate result ('get a job_id back'), and the title/description mark it as the paid async variant. It explicitly distinguishes itself from kimi_review_changes by the detached execution model and from kimi_dry_run/kimi_status by cost and 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 gives clear selection criteria: use kimi_dry_run or kimi_status first for free scope/readiness checks, prefer this tool for multi-file or whole-branch reviews likely to exceed the 300s sync deadline, and use the listed kimi_job_* siblings to poll, read, consume, or cancel. It also warns that starting a job commits spend.

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?

Annotations already indicate readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral detail: the tool always reports `rate_limit` as `unavailable`, that this is not a failure, and that the only quota signal is the `kimi_rate_limited` error with `retry_after_ms`. This goes beyond what annotations provide.

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 compact and front-loaded: first sentence states the purpose and the free/no-model-call nature, second sentence gives when to use it, and the final paragraph gives crucial behavioral caveats. Slightly longer than strictly minimal, but every sentence carries meaningful guidance. A 4 rather than 5 because the last paragraph could be tightened slightly, but it's 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?

For a zero-parameter, read-only status check with an output schema, the description is complete. It tells the agent when to call, what to expect, what not to plan around, and how to interpret the only quota signal. There is nothing an agent needs to know to invoke it correctly that is missing.

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 schema coverage is trivially 100% and there is no parameter documentation burden. The description appropriately explains the output semantics (rate_limit reports unavailable) even though there is an output schema. A 4 is appropriate because the description compensates for the fact that the output schema likely just lists fields and may not explain the always-`unavailable` behavior.

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 verb 'Check' and the specific scope: installed, authenticated, supported version, and resolved defaults. It also labels it as 'Free — no model call,' which distinguishes it from paid tools. It doesn't explicitly name a sibling that performs an overlapping check, but the title and description together make the purpose clear.

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?

Explicitly says when to run it: 'before your first paid call in a session to confirm setup, and again whenever a run fails with a setup error.' It also provides a strong 'do not' guidance about spend planning and `rate_limit`, which prevents incorrect use. This is excellent usage guidance.

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