check_job

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context on the dual modes (list vs. detail) and what happens without job_id. It doesn't describe error handling, but given the annotation coverage, it adds sufficient value beyond annotations.

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?

Two sentences, front-loaded with the core action. No fluff; every clause earns its place. The structure clearly separates the two modes and ties in the filter option efficiently.

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 tool has an output schema, so return values are already specified there. Description covers all main usage scenarios (list vs. detail, status filtering) and references run_simulation for the job_id source. With 3 optional parameters and clear annotations, this is complete for reliable agent usage.

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%, so the baseline is 3. The description adds integration logic: how job_id and status interact (without job_id lists jobs, with it returns details), which goes beyond individual schema descriptions. It clarifies the conditional behavior, adding meaningful context.

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 clearly states the tool's purpose with a specific verb and resource: 'Check status of a simulation job by ID, or list all jobs.' It distinguishes two modes (without job_id: list; with job_id: detailed status/completion), which makes it unique among siblings like cancel_job or batch_results.

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 provides clear context on when to use the tool: without job_id for listing jobs, with job_id for specific details, and when to filter by status. However, it doesn't explicitly mention alternatives or when not to use it (e.g., for batch results use batch_results), though the purpose is self-evident.

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