get_execution_status

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

With no annotations, the description carries the full behavioral burden, and it handles it well. It discloses that progress is computed from the results file so far, that logTail is filtered JMeter console output, and that JMeter only prints a summary line about every 30 seconds so the logTail can appear unchanged between quick polls.

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 front-loaded with the core purpose and returned data, then compactly covers polling behavior, logTail semantics, and end-of-run routing. Every sentence earns its place; there is no filler or repetition.

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 one-parameter polling tool with no output schema, the description is complete. It explains statuses, runtime info, the progress fields, throughput windows, per-label breakdown, logTail caveats, and the correct sibling to call after completion.

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 provides no description for executionId (0% coverage), but the description compensates by tying it to a 'test run started with execute_test_plan', making it clear that the parameter identifies the run initiated by that tool. It adds meaning beyond the bare parameter name and required field.

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: 'Check the status of a test run started with execute_test_plan'. It clearly defines the possible states (running/completed/failed), what data is returned, and distinguishes itself from get_execution_report by saying the report is for after the run ends.

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 explicit guidance: 'Poll this tool rather than tailing stdout.log' and 'Once the run ends, call get_execution_report for the full aggregate'. This tells the agent exactly when to use this tool and when to switch to a sibling, which is strong usage guidance.

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