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

The description goes well beyond the annotations by disclosing that the abort interrupts in-flight delegated work, changes session state, persists as aborted for durable jobs, returns the sessionId and confirmation, and may keep history available. This is exactly the kind of behavioral context a destructiveHint alone cannot convey.

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, front-loaded with the core purpose, and each subsequent sentence earns its place by addressing the destructive consequences, persistence behavior, return value, and post-abort history. No filler or repetition of structured metadata.

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 destructive tool with rich schema coverage and clear annotations, the description covers when to act, what will happen, what is returned, and what may remain. No critical information is missing for an agent to select and 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?

The schema already covers 100% of the single parameter with a rich description, so the baseline applies. The tool description reinforces the need to confirm the intended session but does not add new parameter meaning 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 states a precise action ('Abort an owned Kimi session'), the target resource, and the condition for use ('that should no longer continue running'), which sets it apart from sibling tools like kimi_delegate_task or kimi_continue_task. The opening sentence makes the tool's purpose 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?

It gives clear when-to-use context: abort only after confirming the intended session, and only for work that should no longer continue. It does not explicitly name sibling alternatives for when not to use it, so it falls short of fully explicit when-not/alternative routing.

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 valuable operational transparency beyond those: no session creation, no AgentSwarm execution, no credential exposure, no workspace modification, and returns health/auth status plus safe backend metadata and diagnostics. This materially enriches the behavioral contract without contradicting 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?

Four sentences, each earning its place: purpose, usage timing, return contents, and explicit negative side effects. The core function is front-loaded, and there is 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 zero-parameter diagnostic tool with no output schema, the description covers why and when to call it, what it returns, and what it will not do. It names the relevant diagnostic domains (connectivity, authentication, backend, runtime) and is sufficient for correct invocation.

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 empty schema is complete and the description does not need to document any parameter behavior. With no parameters, the baseline of 4 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 immediately states the specific verb and resource: 'Check bridge and private Kimi-runtime readiness' with a clear scope limiter 'without submitting an LLM task.' It clearly differentiates from the delegation and task-management siblings by framing this as a pre-delegation diagnostic.

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 when to use the tool: 'Use before delegation or when diagnosing connectivity, authentication, backend, or runtime problems.' It also provides what-not conditions, such as not starting a session or running AgentSwarm, but it does not name a specific alternative sibling to use instead in those cases.

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 adds substantial behavioral detail beyond the annotations: it warns that the continuation may execute commands and modify files, describes return values (new promptId and running status), and notes registry updates when durable jobs are configured. This meaningfully informs an agent about side effects and state changes.

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, front-loading the purpose and usage guidance. Every sentence adds useful information, including return behavior and destructive side effects, without 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?

The description covers purpose, when to use, return values, and destructive behavior, which is strong for a tool with no output schema. It does not address failure cases or what happens when the session is not found or not owned, but the annotations and full schema coverage cover most operational needs.

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. The description adds little beyond what the schema provides, only noting that optional model, thinking, and swarm settings apply to the new prompt, which is already reflected in the parameter 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 ('Submit follow-up instructions') and names the resource ('owned existing Kimi session'), making the core action clear. It distinguishes the tool from creating a duplicate session, but it does not explicitly name or differentiate a specific sibling tool, so the distinction is slightly less sharp than it could be.

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 the tool: for corrections, additional work, or deliberate continuation of a recovered job instead of creating a duplicate session. It gives clear use-case context but does not name alternative sibling tools or state when not to use it, leaving some routing 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 description goes well beyond the annotations by explaining timeout semantics ('timeout does not abort the underlying Kimi session'), durable jobId inclusion, and idle-result content such as handoff and review data. It also clarifies that a client-side disconnect does not destroy the underlying job, which is valuable behavioral context an agent would otherwise not know.

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 dense sentences with every sentence earning its place: the first defines behavior, the second gives usage guidance and sibling differentiation, and the third covers timeout recovery and result contents. It is front-loaded with the core action and avoids repetition of schema details.

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 tool with no output schema, the description provides strong context by explaining when to use it, what happens on timeout, and how to recover a job. It does not enumerate result shapes for blocked/failed/aborted statuses, but enough is specified for an agent to invoke the tool and handle the common recovery path.

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 input schema already provides detailed explanations for cwd, plan, task, dedupe, timeoutMs, and others. The description adds no extra parameter-level semantics beyond what the schema already documents, so 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 opens with a precise verb+resource statement: 'Start a Kimi task and wait until it becomes idle, blocked, failed, aborted, or the caller wait times out.' It also distinguishes itself from kimi_delegate_task by noting the waiting behavior and immediate jobId return differences, so an agent can clearly tell which tool to select.

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?

Usage conditions are explicit: this tool is for cases where the caller can remain connected for the expected duration, while kimi_delegate_task is preferred for long-running work. It also gives a recovery instruction after timeout or disconnect, directing the caller to kimi_recent_jobs instead of resubmitting.

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 warns that the task may execute commands and modify files in cwd, going beyond the destructiveHint=true annotation with a concrete side-effect statement. It also discloses that swarmMode only verifies the mode before submission, that final evidence comes later via handoff, and that the call returns before completion.

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 contract is front-loaded in the first sentence, followed by return values, recovery, side effects, swarm mode, and proactive-offer guidance. It is longer than strictly necessary, but each paragraph carries distinct information and avoids repeating schema content.

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 complex asynchronous tool with nine parameters and no output schema, the description covers what is returned, how to recover after interruptions, side-effect risk, swarm mode semantics, and when to offer Kimi proactively. An agent has enough context to call it correctly and select the right follow-up tools.

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 nine parameters in detail. The description adds only mild extra context, such as swarmMode verification semantics, rather than materially enriching the parameters beyond the schemas.

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?

Names a clear operation—start or continue a Kimi task and return immediately—so an agent understands the fire-and-forget contract. It identifies the resource, the immediate-return behavior, and the fact that the caller receives identifiers before completion, distinguishing it from the wait/recovery 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?

Explicitly scopes when to use it (long-running or asynchronous work) and gives a concrete recovery path after disconnect or timeout using kimi_recent_jobs, kimi_wait_until_idle, and kimi_get_handoff instead of submitting a duplicate prompt. It also covers the proactive case where Kimi was not mentioned, including ask-first and auto-off behavior.

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 establish read-only/idempotent/non-destructive safety, and the description reinforces this with 'does not create or modify a session.' It also adds a non-obvious behavioral caveat: discovery does not grant ownership and session-oriented tools still enforce durable ownership.

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 lean sentences arranged by function, usage, ownership caveat, and non-mutation. Every sentence adds a distinct piece of guidance without padding.

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 a rich schema, read-only annotations, and sibling context, the description covers purpose, precise invocation conditions, ownership behavior, and side-effect-free behavior. Nothing critical is missing for correct selection and use.

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 fully describes all 8 parameters and the description need not repeat them. The description adds only general context that results can be filtered by status and cwd, which is already evident 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?

Names a specific action ('Find') and resource ('raw Kimi sessions') with an explicit matching criterion (title substring) and optional filters. Distinguishes itself by saying it is for when the exact session is unknown and contrasts with kimi_recent_jobs and sessionId-based 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?

Gives explicit when-to-use: only when exact session is unknown and durable recovery via kimi_recent_jobs is unavailable or insufficient. Also states what to do after identification (prefer sessionId-based tools), so an agent knows both when and when not to invoke 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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds value by explicitly stating what is not modified—file, session, or durable job state—and by clarifying the return behavior (requested path and diff content), which goes beyond the generic annotation 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 three sentences with no filler. It front-loads the action, then provides the trigger context, the expected return, and the safety guarantee. 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 two-parameter read-only tool with no output schema, the description covers the purpose, when to call it, what it returns, and its side-effect behavior. There is no meaningful gap that would prevent an agent from invoking 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?

The input schema already provides 100% description coverage for both sessionId and path, including guidance to prefer paths from kimi_get_handoff or kimi_review_package. The tool description adds no additional parameter-level meaning beyond the schema, so the baseline score 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 names a specific verb ('Read the diff') and a specific resource ('for one file in an owned Kimi session workspace'). It clearly distinguishes the tool as the diff-reading step after kimi_get_handoff or kimi_review_package, so an agent can identify what it does without needing to open the schema.

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 gives explicit when-to-use guidance: after kimi_get_handoff or kimi_review_package identifies a changed path, when exact patch content is needed. This tells the agent the preceding steps and the condition that should trigger this tool, which is strong contextual 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 signal read-only/idempotent/non-destructive, and the description reinforces this by stating it does not submit or modify. It adds genuinely new behavior: durable-job reconciliation and caching of the returned handoff, which are side effects an agent might not expect from a read-only tool.

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 sentences, each with a distinct job: scope, use timing, return payload, durable side-effect, and non-modification guarantee. Information is front-loaded and there is no filler, though the durable-job sentence adds nuance that could have been separate.

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 a single obvious parameter and no output schema, the description conveys the key return fields and the exact lifecycle timing, which is enough to call it correctly. The only minor gap is that 'current or final' and 'owned' are not formally defined, but siblings fill the surrounding workflow.

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 only parameter, sessionId, has a complete schema description. The tool description adds the 'owned' constraint and ties the ID to current/final result retrieval, giving a bit more selection meaning than the schema alone.

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 names a concrete read action ('Read') on a specific resource ('current or final handoff for an owned Kimi session'), which clearly distinguishes it from delegation, waiting, diff, abort, and status siblings. It also immediately scopes to 'current or final' and 'owned,' so an agent can classify the tool as a retrieval operation.

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 kimi_wait_until_idle reports idle or during recovery when authoritative status/result must be refreshed. It does not name a sibling alternative for when not to use it, and the negative constraint ('does not submit another prompt') is more of a safety note than an exclusion, so this is clear context without full alternative routing.

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 declare idempotent and non-destructive hints, so the description carries the burden of explaining mutability. It does so thoroughly: changes are per-user, persistent, and only apply to tasks started afterwards. It also explains the cost implications of worker vs coordinator model choice, adding real behavioral 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?

The description is front-loaded with the core purpose and then builds logically: role explanation, cost rationale, read behavior, write behavior, and persistence semantics. Every sentence earns its place, and the length is justified by the need to explain a stateful setting with special values.

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 two optional parameters and no output schema, the description covers all essential aspects: how to list, how to switch, what special values mean, when changes take effect, and scope. An agent has everything needed to invoke it correctly without additional inference.

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%, but the description goes further by explaining that parameter values come from the listed model ids and by defining the two special values 'default' and 'same.' It also ties each parameter to the coordinator/worker role, giving agents the conceptual model needed to pick the right parameter.

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 pairing: 'Show or change which ai& models Kimi uses.' It clearly distinguishes between the coordinator and worker roles and states that calling with no arguments lists models, while calling with parameters changes settings. This is unambiguous and easily separable from 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?

The description gives explicit call patterns: no arguments for listing, coordinatorModel/workerModel for switching, and special values 'default' and 'same' with their meanings. It does not name sibling tools or state when not to use this tool, but the context is clear enough for an agent to decide correctly.

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 Publishing. The description adds meaningful context beyond the annotations: it operates on a persistent registry and does not contact Kimi, making behavior transparent during runtime outages. No contradiction with 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?

Four sentences, each earning its place: definition, usage timing, return payload, and a critical behavioral note. The primary statement is front-loaded)Skip and the guidance follows naturally without padding.

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 simple two-parameter read-only tool and no output schema, the description fully covers what an agent needs: when to call it, what it returns (status, identifiers, workspace, swarm mode, cached results/errors, timestamps), and that it works even if Kimi is unavailable. The pagination default/cap is already present in the schema, 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%, with both 'status' and 'pageSize' fully documented including defaults, enum values, and caps. The description itself does not add parameter-level detail, but that is acceptable because the schema already does the heavy lifting.

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 a specific verb ('List'), a precise object ('recent connector-owned durable jobs'), and the source ('persistent bridge registry'). The description also frames the tool as the recovery path for a lost jobId/sessionId, which clearly separates it from siblings like kimi_recent_sessions and kimi_get_handoff.

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 directs the agent to 'use this first' after timeouts, disconnects, bridge restarts, or lost responses, and notes it remains usable when the Kimi runtime is down. It does not name alternative tools or state when not to use it, so it falls just short of the full 'when/when-not/alternatives' criterion.

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, so the safety profile is known. The description adds context beyond those: it clarifies that this is a raw metadata query only, and it reveals a subtle behavioral rule that the listing itself does not grant authorization. This is useful, non-duplicative behavioral disclosure 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?

The description is three sentences with no fluff. The first sentence states the action and scope, the second provides usage guidance with an explicit alternative, and the third adds a brief behavioral caveat. Every sentence earns its place, and the most important information is front-loaded.

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 and four optional parameters, the description covers the essentials: what the tool returns, when to use it, why it differs from the durable-job alternative, and its authorization caveat. It also names the core return fields, which is sufficient for a read-only discovery 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%, so the schema already fully explains all four parameters (status, pageSize, excludeEmpty, includeArchive). The description mentions return fields such as statuses and titles but does not add parameter-specific details beyond the schema, so the 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 opens with a precise action and resource: 'List recent raw Kimi sessions' and enumerates the returned metadata (identifiers, statuses, titles, web links, workspace metadata). It also draws an explicit contrast with kimi_recent_jobs, calling this tool a 'discovery fallback' and positioning it as the non-durable alternative, so an agent can distinguish it from siblings 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 gives explicit routing guidance: 'Use this as a discovery fallback when durable job recovery is unavailable; when durable jobs are configured, prefer kimi_recent_jobs because it is connector-owned and persistent.' It also warns that raw session discovery is not authorization and that session-oriented tools still enforce durable ownership when configured, clarifying when and why this tool should be chosen.

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/idempotent/non-destructive, and the description adds useful behavioral context: the package is cached when durable jobs are configured and the tool 'does not modify the session or workspace.' It could disclose failure behavior or freshness implications, but it goes 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?

Four sentences, all information-bearing and front-loaded with the main action in the first sentence. The final sentence restates what annotations already cover, but it is brief and does not bloat the description.

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 tool with read-only annotations and no output schema, the description communicates inputs, output components, when to reuse, caching behavior, and safety. Nothing an agent needs to select and invoke this tool correctly 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?

There is only one parameter and schema coverage is 100%, so the schema already explains sessionId and its idle-session recommendation. The description adds no new parameter-level detail, 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 opens with a specific verb and resource: 'Build a reviewer-oriented snapshot for an owned Kimi session' and enumerates its inputs (handoff, changed files, Git statistics, review checklist). This makes its purpose distinct from siblings like kimi_get_handoff and kimi_get_diff, which cover only pieces of the snapshot.

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 gives explicit trigger conditions ('after delegated implementation work' or 'after recovery') and an explicit reuse rule: if kimi_delegate_and_wait already returned reviewPackage, reuse it unless newer evidence is needed. This is direct when-to-use guidance with an alternative named.

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 provide idempotentHint and destructiveHint, but the description goes far beyond by explaining that maxAgents is a ceiling (not a hard number), that values above deployment cap are reduced, concurrency behavior, queueing, rate-limit backoff, and offerKimi semantics. No contradiction with annotations; description adds rich behavioral context.

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 dense; every sentence adds necessary detail. It front-loads the main purpose and then elaborates. It could be slightly tighter, but the complexity justifies the length. Not overly verbose.

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 two optional parameters and no output schema, the description explains what the response reports (concurrency, queueing, backoff) and how to use it. All needed information for correct invocation is present.

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 baseline is 3, but description adds substantial meaning: explains maxAgents is a ceiling, how it gets reduced, offerKimi values (ask/auto/off) with default and behavior. This goes well beyond the schema's 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?

States a clear verb ('Show or change') with a specific resource (AgentSwarm workers per task). It distinguishes itself from sibling tools like kimi_model_settings by specifying the exact resource. An agent can immediately understand what this tool does.

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 describes when to call with maxAgents (when user asks to raise/lower limit) and when to call with no arguments (to report current settings). Also gives guidance on offerKimi usage ('read it before your first offer', 'save it when the user says...'). 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.

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses meaningful behavior: a timeout only ends the wait attempt without aborting the session or marking the durable job timed out, and pending approval/question data is returned when applicable. These details align with the annotations, so there is 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 front-loaded with the core polling purpose and terminal states, and most sentences add unique value such as timeout semantics and return content. The final sentence about not modifying workspace content partially duplicates the readOnlyHint annotation, so it is not perfectly lean.

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 two-parameter poll tool with no output schema, the description adequately covers sessionId provenance, terminal states, timeout behavior, and return content. The exact shape or error signaling of 'normalized status' is underspecified, but an agent has enough information to invoke the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents both sessionId and timeoutMs, including the non-mutating timeout behavior. The description adds only marginal provenance guidance by naming kimi_recent_jobs as a recovery path, which the schema already implies via 'session-discovery tools'.

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 ('Poll') and a specific resource (an owned Kimi session), and enumerates the exact terminal states. It distinguishes itself from sibling discovery/delegation/abort tools by describing the wait/poll role and by referencing session IDs from delegation or kimi_recent_jobs.

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 gives clear usage context: the sessionId must come from delegation or be recovered through kimi_recent_jobs, and it clarifies that a timeout is not an abort or a durable-job failure. It does not explicitly name alternatives like kimi_delegate_and_wait or state when not to use the tool, so it stops 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.