fusion_operation_status

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

There are no annotations provided, so the description carries the full burden of behavioral disclosure. The phrase 'without retrying it' is a useful behavioral trait, but the description does not disclose whether the status is persisted for long, if it can be stale, whether it requires a valid operation_id, or any error conditions (e.g., operation not found). It also doesn't specify if the operation may still be running and what happens in that case. The description gives a hint but leaves many behavioral aspects undisclosed.

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 a single, concise sentence that is front-loaded with the action ('Retrieve persisted operation status') and immediately clarifies the key nuance ('without retrying it'). There is no filler or redundant content, making it appropriately sized and easy to parse.

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?

Given the tool has one parameter with zero schema coverage ratio, no output schema, and no annotations, the description is too sparse to be fully contextual. It does not explain the return value (status details like success/failure/progress), how the operation_id relates to other fusion tools, or what 'persisted' means for the agent. A more complete description would specify typical usage (e.g., polling after an async operation) and the expected response structure.

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%, so the description must compensate for the undocumented parameter. However, the description only mentions 'operation status' and does not explain what 'operation_id' is or how to obtain it, nor its format or constraints. The sole parameter is not elaborated beyond its schema title 'Operation Id', leaving the agent with minimal semantic understanding.

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: 'Retrieve persisted operation status' and notes the key behavior 'without retrying it.' It clearly indicates the tool is for fetching status, not initiating operations routes the agent away from retrying. However, it does not explicitly distinguish from siblings like fusion_acknowledge_operation or fusion_active_command, which might also involve operations, so it is adequate but not fully differentiating.

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 gives minimal usage direction: it implies that the tool is for when you need to check status without triggering a retry)Skip the potential retry behavior. However, it does not state when to use this tool versus alternatives like fusion_acknowledge_operation, fusion_active_command, or fusion_recompute. No explicit context about typical usage scenarios or prerequisites (e.g., operation_id from a prior command) is provided, so guidance is incomplete.

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