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

Beyond the annotations (destructiveHint=true), it discloses that with 'yolo' approval mode kimi edits files and runs shell commands as the user, that print mode executes without confirmation, that it blocks until settling, and that interrupted runs preserve a resumable session id. This significantly extends the structured annotations without 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?

Structured into purpose, usage, and caution paragraphs with no filler—each sentence conveys an important fact or constraint. It is somewhat long, but that length is reasonable given the tool can mutate the local machine and has 8 configurable parameters.

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

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

With no output schema, it sensibly tells the agent what to expect ('only its final result plus stats, prefixed session id') and covers resumability, blocking, cwd scope, and destructive behavior. It does not spell out the exact structure of the result/stats, but the remaining gap is minor for evaluating outcomes.

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 schema already covers all 8 parameters with detailed, 100% coverage. The description reinforces certain parameters (e.g., cwd's workspace scope, approval_mode's yolo hazard, timeouts not losing sessions) but adds little meaning beyond the schema's existing text, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource ('Start a NEW task in the local Kimi Code agent') and clearly identifies it as separate from the current conversation, naming kimi_reply for continuation. This makes it easy to distinguish from the six sibling tools.

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 lists when to use it ('Good for: a second opinion, work kept out of this context, parallel investigation') and points to kimi_reply as the continuation path, effectively stating when not to use this tool. It also gives practical guidance on optional parameters ('Usually omit').

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 readOnly, and the description goes well beyond them: no data is sent, no session lock is taken, it never blocks on kimi, thought/reasoning content is omitted, and it refuses to invent prompts from metadata. It also discloses the 100000-char page cap and cursor durability at EOF. This is model behavior 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?

Long but dense; the first sentence names the action and source, and every additional clause adds operational detail (omissions, caps, cursor semantics). Slightly run-on in the return-shape sentence, but nothing is wasted.

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

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

For a read-only tool with no output schema, the description fully specifies the return shape (session, state, items, cursor, has_more, truncated_tail), data source, omissions, caps, and cursor behavior. There is no output schema, so this description carries the entire burden and meets it.

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 already documents all five parameters with defaults and maxes, so the baseline is 3. The description adds meaning beyond the schema: the cursor is always returned even on empty pages, and a trailing partial line is not lost at EOF; the overall 100000-char cap applies per page. These nuances are not 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 opens with a specific verb and object: 'Read a bounded snapshot of a kimi session's visible conversation from kimi's native agents/wire.jsonl'. It clearly states what the tool does, where data comes from, and what it does not do (no sending, no waiting). The purpose is immediately distinguishable from sibling tools even without naming them.

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 makes the read-only, non-interfering nature explicit ('does not send anything into the run, does not take the session lock, does not wait'), which tells an agent when to pick this over mutations like kimi_resume. It doesn't explicitly name sibling tools, but the behavioral contrast is clear enough. Not a 5 because it never states direct conditions like 'use this when you need history without resuming'.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context: it reads live from `kimi provider list --json`, 'Starts no task' (quick operation), and clarifies it is a cheap lookup rather than a full endpoint probe. This goes beyond the annotations without contradicting them.

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?

Four short sentences, each carrying distinct value: purpose, data source, use case, and economic warning. Front-loaded with the verb and resource, no filler or redundancy.

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

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

For a simple list tool with one optional parameter and no output schema, the description covers the main needs: what it returns (list of models), when to call it, that it is read-only and cheap. It could mention result formatting or that the search filters by model id, but the schema handles that parameter, 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?

The schema description for the single `search` parameter is fully self-explanatory (100% coverage), specifying it as an optional substring filter with examples. The description adds no parameter-specific information, which is acceptable given the schema already covers it fully — baseline 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 starts with a specific verb ('List') and resource ('models this kimi installation has configured'), making the operation unambiguous. It explicitly states it is for picking a `model` value for `kimi`/`kimi_reply`, which distinguishes it from sibling tools that perform replies.

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 directs the agent to use this tool to select a model for kimi/kimi_reply, which is a clear use case. It also implies when not to use it by noting it is the 'configured catalog, not a paid probe,' though it doesn't explicitly list exclusions or alternative conditions beyond naming the reply tools.

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 mark destructiveHint=true and readOnlyHint=false, and the description adds substantial context beyond that: session survival in kimi's store, persistence across server restarts, that kimi retains prior turns but never this conversation, and that a timeout-killed run is resumable. It also explains the difference in reachability between transport modes. 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?

The description is four tightly packed sentences. The core purpose is front-loaded, then it adds session persistence, follow-up brevity, and sibling routing. No filler; every clause 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 9-parameter tool with no output schema, the description covers the essential behavioral dimensions: when to use, what happens on timeout, session longevity, transport trade-offs, and routing. It even hints at the return (session id) and missing conversation context. Nothing an agent needs to decide correctly is omitted.

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%, yet the description enriches several parameters: it explains session ID sources, why transport should usually be omitted and the reachability difference, timeout override guidance including resumability, and approval_mode headless implications. This goes well 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?

The description uses a specific verb ('Send a new turn') and names the exact resource ('existing kimi session that is not executing right now'). It explicitly distinguishes itself from kimi_send and kimi, and even includes edge cases like timed-out or cancelled sessions. This fully separates it from all six 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?

It states precisely when to use this tool versus alternatives: 'For a turn still running under acp, use kimi_send instead' and 'resume it here instead of restarting with kimi'. This is explicit routing with a clear condition, leaving nothing 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the behavioral constraint that only acp-transport runs are reachable and that 'print' runs cannot be accessed mid-run, which is useful context. However, it doesn't describe the return format or potential pagination, though with annotations covering safety, a 3 is appropriate.

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 concise, with four sentences that each add value. The first sentence states the core purpose and key information fields, the second clarifies scope and exclusions, and the third routes to the appropriate sibling. No wasted words.

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?

Though the tool has no output schema, the description lists what information the results contain (session id, working directory, elapsed time, messages). Combined with annotations clarifying read-only and idempotent behavior, and the clear use case and exclusions, the description is complete for an agent to invoke 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 tool has zero parameterschen and schema description coverage is 100% (the schema is empty). With no parameters to document, the description naturally carries no parameter burden. The tool's output is well described, so this dimension is not applicable and a high score is given.

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 lists currently running kimi turns, with specific details (session id, working directory, elapsed time, messages). It distinguishes from siblings by noting only acp-transport runs appear and that 'print' runs are unreachable mid-run, and points to kimi_sessions for past sessions. This is a specific verb+resource with clear 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?

It explicitly states when to use this tool (for current, reachable runs) and when not to ('print' runs are unreachable; for past sessions use kimi_sessions). The alternative (kimi_sessions) is named, providing clear routing 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?

Annotations already mark it readOnly=false, idempotent=false, and destructiveHint=truehare, and the description adds crucial behavioral details: it returns immediately, the reaction surfaces in a separate pending reply call, and a follow_up is queued without awaiting its result. The note about the first result envelope further clarifies the async interaction model.

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 information-dense: each sentence adds distinct value—reachability, command semantics, delivery timing, and caveats about result envelopes. There is no wasted wording.

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 100% schema coverage and annotations, the description still supplies essential contextual details: immediate return behavior, relationship to the waiting kimi_reply call, and the caveat about follow_up results not being awaited. This is sufficient for an agent to decide when and how to use the 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 description coverage is 100%, with each parameter already described in detail, including the command enum and the message requirement rules. The description reinforces the relationship between commands and turn behavior but doesn't substantially extend the parameter-level semantics already provided.

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 ('Deliver') and resource ('a kimi turn that is executing right now'), clearly distinguishing this from kimi_reply, which is for finished sessions. It also clarifies transport constraints ('acp' vs 'print') that prevent misuse.

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

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

Provides explicit when-to-use and when-not-to-use guidance: only for currently executing turns, not for 'print' transport or finished sessions. It names kimi_reply as the correct alternative for completed turns and points to kimi_running for finding reachable sessions.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating the ordering (newest first), the inclusion of timed-out runs, and the fact that it returns working directories. It doesn't describe pagination or output format, but for a read-only list tool with no output schema, the added context is meaningful.

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 sentences, front-loads the core behavior (list all sessions, newest first, with working directory), and then immediately provides the use case and the sibling alternative. Every sentence earns its place with no wasted words.

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 list tool with strong annotations, the description is nearly complete. It covers scope, ordering, inclusion of timed-out runs, and how to use the result. The only minor gap is the lack of an explicit output format, but since there is no output schema and the tool is simple, this is a small omission.

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 schema is trivially complete. The description adds no parameter-specific semantics because there are none to add. A baseline of 4 is appropriate for a zero-parameter tool.

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 lists all kimi sessions with their working directory, newest first, and explicitly includes running, finished, and timed-out runs. It also distinguishes itself from kimi_running by noting that kimi_running is for turns still executing, which helps an agent understand the exact 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 explicitly says to use this tool to recover an id for kimi_reply, and it names kimi_running as the alternative for turns still executing. This gives clear when-to-use and when-not-to-use guidance, which is strong for a list tool.

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