cpu_get_craft_status

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the stall condition (output box room less than one whole batch), the all-or-nothing settlement behavior, the meaning of isFinished (holds the process slot only), the reset of waiting, and the timestamp clock basis. It also notes the tool is public and works for any tokenId, which is important security/scope context. This goes well beyond a simple getter description.

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 structured with a front-loaded summary of what is returned, followed by necessary behavioral details. Each sentence earns its place: stall mechanics, isFinished semantics, timestamp clock, public access, and the pointer to cpu_claim_craft. There is no redundant or filler text.

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 there is no output schema and no annotations, the description does an excellent job of covering the complex craft-state concepts: schedule progress, claimable output, stalling, blocked outputs, finished runs, and timestamp consistency. An agent has enough information to interpret the response and decide next actions.

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 schema describes tokenId as 'the tokenId of the cell whose craft processes to act on,' so the baseline is 3. The description adds the extra semantic that the tool is public and works for any tokenId, clarifying authorization and ownership expectations 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 ('Get') and names the exact resource ('the craft job on a cell') plus enumerates the returned data: recipe, status, batch progress, claimable amount, next maturation, and run end. This clearly differentiates it from sibling tools like cpu_craft and cpu_claim_craft, which initiate or bank craft jobs rather than report on 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 states this is 'the source of craft progress' and directs the agent to bank matured batches with cpu_claim_craft, giving a clear follow-up action. It implies when to use this tool versus the claim tool, though it does not explicitly mention when not to use it or compare with other status getters like cpu_get_mining_status.

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