run_implementation

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

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly reveals the key non-blocking behavior by saying 'asynchronously' and directs the agent to the correct follow-up mechanism. It does not mention failure modes or repeated launches, but the async contract is clearly and usefully disclosed.

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 extremely concise: two clauses that each earn their place by conveying what to launch, how to launch it, and how to monitor it. There is no filler or repetition of the tool name.

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 provides the essential control flow—launch asynchronously, then poll—but it is not complete enough for actual invocation because both parameters are undocumented and no annotations or parameter descriptions compensate. An agent can understand the workflow at a high level but cannot determine how to set run_name or timeout_s correctly.

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 description coverage is 0%, and the tool description does not mention run_name or timeout_s at all. The agent cannot learn their meaning, optionality, or expected values from the description, so it cannot confidently set parameters for this tool.

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 specific verb and resource: 'Launch implementation', and adds the distinguishing mode 'asynchronously'. Naming get_run_progress as the polling target separates this tool from progress-reporting tools, and 'implementation' distinguishes it from synthesis or bitstream-generation siblings.

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 clearly tells the agent what to do after calling the tool: poll with get_run_progress. However, it does not give conditions for choosing this tool over sibling flow steps like run_synthesis or generate_bitstream, so the selection context is mostly implied by the domain.

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