cpu_craft

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it excels: it explains upfront debit of inputs, free vs. paid recipes, the one-time unbounded CPU approval for forge_wcpu, delayed timer start after indexer settlement, switch-cost burning, and free cases for first pick/restart. It also discloses that the result reports recipe cost and switch cost separately.

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 dense but well-structured: core action first, then prerequisites, then payment/cost behavior, then switch-cost nuance, then pre-commit guidance and post-invocation tracking. Every sentence adds essential operational detail for a complex on-chain crafting tool, and no redundant filler is present.

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 no annotations and no output schema, the description is remarkably complete. It covers prerequisites, cost behavior, edge cases, what the result reports, and how to follow up. An agent has enough context to invoke cpu_craft correctly and interpret what happened afterward.

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?

Although the schema already covers 100% of parameter descriptions, the tool description adds meaningful semantics beyond the schema. It clarifies batches are debited upfront with no cancel behavior, explains forge_wcpu's special CPU cost and approval flow, and details when a Switch cost is or is not burned for recipeId changes.

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: "Run a craft recipe on a cell you own (refine raw resources, or forge $WCPU)." This clearly distinguishes the action from sibling tools like cpu_list_recipes, cpu_get_craft_status, and cpu_claim_craft, which handle discovery, status, and claiming respectively.

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 and lifecycle routing: call cpu_authenticate first, discover recipes with cpu_list_recipes, check prices via cpu_get_cell, track progress with cpu_get_craft_status, and bank results with cpu_claim_craft. It leaves no ambiguity about when this tool should be invoked versus related tools.

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