elite_prepare

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

The annotations are all false/neutral, so the description carries the burden. It discloses that the tool returns a stateful run_id and a continuation that must be followed in later calls — key behavioral context beyond any structured signal — and it warns the agent that this call is not the final answer.

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-loads the core verb, and uses short directive phrases that an agent can parse quickly. Slight deduction because the juxtaposition of 'Run it is' not clearly the same sentence as 'Not the answer', but overall it earns its space.

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 described model ('start a task → retain id → follow continuation') is complete enough to attempt a intercepted call, and the workflow-specific directives are present. However, it fails to explain what a 'continuation' looks like, how it relates to siblings, or whether the 'persist' parameter affects that assumed the behavioral guarantee.

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 has two parameters (user_prompt, persist) with zero description coverage, and the tool description adds no parameter details. 'user_prompt' does not even self-evidently map to 'start a non-trivial task' — it takes its purpose entirely from the ambiguous title. The description fails entirely to compensate for the schema's lack of explanation.

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 clear action ('Start a non-trivial task') and signals its role in the workflow ('Not the answer'). However, it does not name the underlying resource or define what qualifies as 'non-trivial', and only loosely differs from siblings like elite_verify and elite_memory.

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 instruction to 'Retain run_id and obey the returned continuation after each later Elite call' implies this is the entry point for a multi-step workflow, and 'Not the answer' is a weak exclusion. It gives useful context for when to call it, but stops short of explicitly contrasting it with elite_verify or elite_memory.

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