etabs_job_status

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the extra credit goes to non-obvious behavior: non-blocking execution ('Never blocks'), the state machine (running/done/failed), elapsed time, and the log tail only while running. The return details are somewhat redundant with the output schema, keeping this from a 5.

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?

A single dense sentence that front-loads the core purpose (job status) and then lists the supporting details. Every clause earns its place with no 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?

With an output schema present, return values needn't be restated, yet the description nonetheless sketches the result shape and the non-blocking contract, making it self-sufficient for calling the tool. The only gap is the lack of explicit routing against etabs_job_wait and etabs_analysis_status.

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 100% and the single job_id parameter is documented there, including 'omit for the most recent job.' The description adds nothing about job_id, so the baseline 3 for schema-carried semantics is appropriate.

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?

States a specific verb and resource ('Status of a background job') and enumerates the job types and states it reports. The closing 'Never blocks' implicitly distinguishes it from the blocking sibling etabs_job_wait, so an agent can tell the two apart.

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?

Usage is only implied: the agent can infer this is a non-blocking poll of a job it started, and 'Never blocks' hints at a contrast with etabs_job_wait. However, it never names the alternative or states explicitly when to poll versus wait, so the routing guidance is left to inference.

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