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

Annotations already flag destructiveHint, but the description goes further: it says the action changes session state, can interrupt in-flight commands or delegated work, and that persisted session history may remain. It also discloses the return value, adding real context beyond 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?

Three sentences with no filler. The purpose is front-loaded, followed by necessary caveats and return behavior. 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 one-parameter destructive action, this is complete. It covers when to use the tool, prerequisites, side effects, persistence nuance, and return value, even without an output schema.

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 sole parameter sessionId is fully documented in the schema, including the instruction to use the ID returned by delegation or discovery tools. The description reinforces the need to confirm the session ID, but does not add meaningful semantic detail 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?

Description states the specific action: 'Abort an existing Kimi session that should no longer continue running.' It uses a clear verb and resource, and is easily distinguished from sibling delegation and status 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?

The description gives explicit guidance: 'Use only after confirming the target session ID' and explains the consequence of interrupting in-flight commands or delegated work. It does not name alternative tools or explicit when-not-to-use conditions, but the context is clear.

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, idempotentHint, and destructiveHint=false. The description adds significant behavioral context beyond these: it is a diagnostics-only tool, does not expose credentials, does not start a swarm, and does not modify the workspace. It also mentions 'safe diagnostics' and 'suggested next actions', reassuring the agent about side-effect-free execution. This goes well 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?

Three sentences pack a precise purpose, explicit usage guidance, and behavioral exclusions, with no filler. The main action and target are front-loaded in the first sentence, and the negative guarantees are placed last. 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 0-parameter read-only status tool, the description fully covers what the agent needs: what is checked (health/auth, metadata, diagnostics), when to use it, and what it does not do. Although no output schema exists, the description enumerates the return content in enough detail for an agent to predict the result shape.

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 no parameter-level work for the description to do. Schema coverage is 100% by default with an empty properties object. Baseline score of 4 for 0-param tools is appropriate; the description adds nothing parameter-specific because nothing 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 verb 'Check' plus resource 'live bridge and private Kimi-runtime readiness' clearly states the tool's specific function. It enumerates the checks (health/auth, backend/version, diagnostics, suggestions) and explicitly contrasts with delegation tools by saying it does not submit an LLM task or start a swarm. This differentiates it from all named 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 description gives explicit timing: 'Use before delegation or when troubleshooting connectivity and authentication.' This directly tells the agent when to invoke this tool. It does not name sibling alternatives explicitly or state when not to use, but the context of siblings and the negative 'does not' statements provide enough differentiation for a conditional diagnostic tool.

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 mark the tool as destructive, and the description goes beyond this by disclosing the concrete effects: 'may run commands and modify files.' It also clarifies that model, thinking, and swarm settings are applied before prompt submission, adding timing context not present in 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 dense sentences with no filler, front-loading the purpose and use cases before the behavioral note. Every sentence adds value, and the optional-settings detail is packed efficiently at the end.

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 essential calling conditions are covered: required parameters, use cases, destructive behavior, and settings timing. It stops short of stating whether the call blocks until completion or what it returns, but the sibling wait tools and full schema make this gap minor.

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 every parameter, including sessionId and task. The description adds little per-parameter semantics beyond confirming the optional model/thinking/swarm settings and their timing, which keeps it at the baseline.

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 ('Submit follow-up instructions to an existing Kimi session') and adds the key distinguishing feature of preserving prior context. It further differentiates from new-session work by saying to use it 'instead of creating an unnecessary duplicate session,' which separates it from sibling delegation 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?

The description explicitly gives concrete use cases: corrections, additional work, and recovery after a failed/aborted task. It also warns against duplicate sessions, but it does not name sibling tools or state when to choose kimi_delegate_task over this tool, so the routing guidance is clear but not exhaustive.

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 idempotentHint=false. The description adds context: it waits for terminal states, may run commands and modify files, returns handoff/review data, and explicitly notes timeout behavior ('A timeout returns control without aborting the Kimi session'). It also discloses swarmEvidence behavior. No contradiction with annotations; adds valuable behavioral detail beyond the structured hints.

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: three sentences cover purpose, usage differentiation, and key behavioral warnings. It is front-loaded with the core function and routes to the alternative, with no fluff. Every sentence contributes value.

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 10 parameters, a nested object, and no output schema, the description gives a solid overview but omits the exact return structure beyond 'handoff and review data' and 'structured swarmEvidence'. The timeout and dedupe behaviors are mentioned indirectly via schema. Slightly more detail on the return shape would help, but the core operation is adequately scoped for an agent to invoke it 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%, with each parameter thoroughly described (e.g., dedupe object, model alias, timeoutMs). The description does not add parameter-level explanation beyond what the schema provides, but it does set expectations for the overall call (waiting, returning handoff data). Baseline 3 is appropriate since the schema carries the parameter documentation load.

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 ('Start'), resource ('Kimi task'), and outcome ('wait for completion... return handoff and review data'). It explicitly distinguishes from kimi_delegate_task by naming the alternative and the condition ('when the caller needs immediate asynchronous control'), so an agent can select correctly 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 provides clear guidance on when to prefer this tool over kimi_delegate_task, and warns that 'The task may run commands and modify files.' This covers primary usage context and a key exclusion (immediate async control), leaving little 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 indicate destructiveHint=true, so the agent knows mutations can occur. The description adds value by specifying that the task may modify files in cwd and that the tool returns immediately (non-blocking behavior). It also discloses the limitation of swarmMode verification. Only minor gaps remain, such as specifics about response format, but the description goes beyond 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 three sentences, with the core action and return behavior front-loaded, then alternatives and key caveats. Every sentence adds distinct value: purpose, usage guideline, and behavioral note about destructive effects and swarmMode. There is no fluff, and it is appropriately compact.

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 complexity (8 parameters, destructive nature, asynchronous workflow), the description covers the essentials: what it does, when to use it, what happens after (siblings), and important caveats (swarmMode, file modifications). However, it does not detail the return format or how to interpret 'current status,' and is silent on error handling or failure cases. For a high-complexity tool with no output schema, slight gaps remain, but the description is largely 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?

With 100% schema coverage, the baseline is 3. The description adds critical semantics by referencing the sibling tools (for follow-up), explaining the asynchronous returns, and providing context between parameters (e.g., relationship between swarmMode and kimi_delegate_and_wait). While the description doesn't re-explain each parameter in detail, it enriches the schema's meaning through usage context, justifying 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 clearly states the tool's verb ('Start or submit'), resource ('Kimi task'), and primary behavior (returns immediately with identifiers and status). It effectively differentiates from siblings by naming kimi_delegate_and_wait, and the context signals confirm it's for asynchronous workflows. This is specific and unambiguous.

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 when to use this tool (asynchronous workflows) and when not to (when result is needed in one call, use kimi_delegate_and_wait). It also names the follow-up tools (kimi_wait_until_idle, kimi_get_handoff) and clarifies the caveat about swarmMode. This is exemplary usage 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description reinforces this and adds extra context: it returns 'matching candidates plus status-aware next-step guidance' and warns about latency for includeSummary. It discloses behavior beyond 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?

The description is three sentences, front-loaded with purpose, and each sentence adds value: function, usage context with alternative, and read-only output behavior. 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 search/find tool with fully documented parameters and safety annotations, the description covers purpose, usage, and output nature. It mentions status-aware next-step guidance and latency trade-offs, though it doesn't detail the exact return structure. Given no output schema exists, this is nearly 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% with detailed descriptions for all 8 parameters. The description does not add parameter-specific semantics beyond what the schema already provides; it only generalizes about status and working directory filters. Baseline 3 is appropriate given full schema coverage.

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 explicitly states the tool finds recent Kimi sessions by title substring, with optional filters on status and working directory. It also names the exact use case (interruption recovery/dedupe when session ID is unknown) and contrasts with session-ID-based tools, clearly distinguishing it from siblings like kimi_recent_sessions.

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: 'Use for interruption recovery or dedupe when the exact session ID is unknown; prefer session-ID-based tools once a match is known.' This clearly routes the agent to alternatives once a match is found, leaving no ambiguity.

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. The description repeats this with 'This is read-only; it does not modify the file or session' but adds little beyond the annotations. It also adds the path scoping note, though that is more usage guidance than behavioral disclosure. 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 three sentences with no filler. Purpose is front-loaded, usage context follows, and the safety/path caveat is last. 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?

The tool has no output schema, so the description should explain what the agent will receive, but it never describes the return shape or content of the diff. It covers purpose, prerequisite tools, and read-only behavior, but omits return-value semantics. The tool is simple, so this is a moderate gap rather than a severe one.

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 both params have meaningful schema descriptions. The tool description adds only minor context by reminding that the path should be in the target session workspace and that diff content is expected. Since the schema already carries most parameter meaning, the baseline 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 states a specific verb and resource: 'Read the diff for one file in a Kimi session workspace.' It also clarifies the unit of work ('one file') and the need for 'exact patch content,' which helps distinguish it from sibling tools like kimi_get_handoff or kimi_review_package.

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 context: 'Use after kimi_get_handoff or kimi_review_package identifies a changed path and exact patch content is needed.' This clearly states when the tool is appropriate and names related tools. It does not explicitly discuss when not to use it or list alternative diff-retrieval paths, so it falls 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false; the description's read-only sentence mostly restates that. It adds useful context about the delivered handoff contents, but no new behavioral traits such as failure modes, authorization requirements, or side-effect details beyond 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?

Three sentences, each with a distinct role: what it reads, when to use it versus the alternative, and safety confirmation. The key scoping information is front-loaded and 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 one-parameter, read-only tool with no output schema, the description fully covers the invocation timing and the categories of returned content. An agent has enough information to select and call this tool without significant ambiguity.

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% and the single sessionId parameter already has a clear description ('whose current/final result and Git-change evidence should be retrieved'). The tool description does not add parameter-specific 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 description uses a specific verb ('Read') with a precise resource ('current/final handoff for one Kimi session') and enumerates the included content: assistant result, changed files, committed changes, working-tree changes, and Git baseline evidence. It also names kimi_review_package as the condensed alternative, making the purpose distinct from at least the closest sibling.

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 says to use this tool after a session finishes when the caller needs the actual result or change details, and directs reviewer-oriented needs to kimi_review_package. This gives a clear when-to-use, when-not-to-use, and named alternative.

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 idempotentHint=true, and the description reinforces this with 'This is read-only and only queries Kimi session metadata.' It adds useful context by specifying that the tool only queries metadata rather than session content, which goes beyond the annotations. There is 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 three sentences with no filler: the core purpose is front-loaded, then the intended usage context and the alternative tool, then a concise read-only note. 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 filtered-list tool with four optional parameters and no output schema, the description provides enough context: it lists the kind of data returned, explains when to use it versus the sibling, and the annotations cover safety and idempotency. The schema covers parameters fully, so nothing essential 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 the schema fully documents status, pageSize, excludeEmpty, and includeArchive. The description does not repeat parameter details, which is appropriate; the baseline of 3 applies because the description relies on the schema for parameter meaning and does not add extra semantic value 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 specific verb ('List') and resource ('recent Kimi sessions'), and further clarifies the returned data: identifiers, statuses, titles, web links, and workspace metadata. It also distinguishes itself from kimi_find_recent_session by noting that the sibling is for when a title fragment is known, so there is no ambiguity about which tool does what.

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 states exactly when to use this tool: before waiting, reviewing, continuing, aborting, or creating a possible duplicate to discover an existing job. It explicitly names kimi_find_recent_session as the alternative when a title fragment is known, which gives clear selection 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it 'does not modify files or session state,' which reinforces the safety profile but is redundant. However, it also mentions 'read-only' and 'fresh snapshot,' adding context about the nature of the output, and clarifies it's for review purposes.

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 efficient, but it could be more front-loaded: the core purpose is in the first clause, but the alternative guidance is in the middle. Still, every sentence is substantive, and it avoids redundancy. A slight improvement would be to separate the usage guideline into its own sentence, but it's well within acceptable.

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 a single well-documented parameter and no output schema, the description covers the essentials: what it does, when to use it, and safety. It doesn't detail the output structure, but that's not required given the low complexity and absence of an output schema. The only minor gap is a possible mention of error conditions, but that's minor.

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 the scription of sessionId. The description adds a recommendation to use an idle session, which adds semantic guidance beyond the schema. That merits a slight bump, but since the schema already covers the parameter well, baseline is 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 purpose: to build a read-only review package combining handoff, changed files, Git statistics, and checklist. It mentions the specific resource (one Kimi session) and the action (combining evidence). It also distinguishes itself from siblings by naming kimi_delegate_and_wait and explaining when to use it instead.

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 it after delegated implementation work and provides a clear alternative: if kimi_delegate_and_wait already returned an embedded reviewPackage, prefer that unless a fresh snapshot is needed. This provides both when-to-use and when-not-to-use 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 declare readOnlyHint=true and idempotentHint=true, but the description adds meaningful behavioral context beyond that: it clarifies that the tool 'does not abort the job on timeout' and mentions the return of 'normalized wait status and pending approval/question data when applicable.' This provides information about side effects and outcomes that the annotations do not cover. 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 three sentences long, each with a distinct purpose: statement of function, guidance on when to use, and a note on safety/returns. It is front-loaded with the primary purpose and contains no redundant or filler content. 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 tool with only two parameters and no output schema, the description adequately covers the essential information: what the tool does, when to use it, its read-only nature, what it returns, and the timeout behavior. It does not explain polling intervals or default timeout values, but the timeoutMs parameter makes that optional. The description is complete enough for an agent to invoke it 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 description coverage is 100% for both parameters. The schema already explains sessionId as the 'Kimi session ID returned by delegation or session-discovery tools' and timeoutMs with its behavior. The description adds no new parameter-specific meaning beyond what the schema provides, 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 clearly states the tool's function: 'Poll an existing Kimi session until it is idle, times out, requires approval or a question response, is aborted, or fails.' This includes a specific verb (poll), a resource (Kimi session), and enumerates the possible terminal states. It also distinguishes itself by noting it does not abort the job on timeout, which differentiates it from sibling tools like kimi_abort or kimi_delegate_and_wait.

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 usage context: 'Use after kimi_delegate_task or after an earlier wait timed out.' This tells the agent when to call this tool. However, it does not explicitly name alternatives or state when NOT to use it (e.g., comparing with kimi_delegate_and_wait which combines delegation and wait). The guidance is clear but lacks explicit exclusions.

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