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

The description adds substantial behavior beyond the annotations: Rust decides from current state, retains adverse days, reports costs/refusals/meals, and is bounded to ten days and 100 added commands. It also explicitly prohibits persistent save, LLM calls, and background search, consistent with openWorldHint=false, though terms like 'shared workshop quotas' and 'full autonomy' remain under-specified.

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 every sentence carries relevant information, and the purpose is front-loaded. Some later warnings like 'Local meals do not imply full autonomy' are cryptic, but they are 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?

The description covers the parameter format, run bounds, side-effect boundaries, and the output ('complete export'), so an agent can attempt a call. It relies on domain jargon such as J95-J105, adverse days, and workshop quotas without fully explaining them, but the output schema and domain context mitigate those gaps.

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 0% schema coverage, the description carries the full burden and succeeds. It defines choices_json as a CLOSED object with fixed mission_id and enumerates all valid values for harvest, egg_reserve, and rotate, which is exactly the semantic content the schema lacks.

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 action, 'Try the fixed J95 to J105 farm chapter,' and names the resource and its closed choices object. However, 'Try' is a weaker verb than 'run' and the description never explicitly contrasts this tool with farm_autopilot_run or farm_campaign_get, so it is clear but not fully differentiated.

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 a clear precondition ('after agreeing a finite call budget') and indicates the downstream flow ('human chooses adoption'), plus a list of excluded capabilities. But it never names sibling tools or states when farm_campaign_run should be chosen over farm_autopilot_run or farm_campaign_get.

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