Check job status (free)

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

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

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

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

Long but dense and front-loaded: purpose, then usage, then state semantics, then polling protocol. Every sentence carries behavioral or routing information; the parentheticals ('a delegate often runs ~20s') are relevant, not filler.

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

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

For a polling/status tool with complex lifecycle semantics, the description covers the full call path (when to poll, what fields mean, when to escalate to kimi_job_result, edge cases like incompatible payloads). Output schema exists, so return-value detail is not required here.

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

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

Input schema coverage is 100% and both parameter descriptions are already complete; the tool description restates job_id's origin but adds no new meaning for the input parameters. The poll_after_ms discussion is output behavior, not an input parameter, so baseline 3 applies.

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

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

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

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

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

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

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