qbo_payroll_status

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

The description discloses a key invariant: 'Door 1 is always dry-run / not submitted,' which adds behavioral context beyond a simple status fetch. However, with no annotations provided, the description carries the full burden of explaining side effects, output structure, or other behavioral nuances. It does not clarify whether this is a read-only operation or describe the response format, though 'fetch' implies read-only.

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 two short sentences with no redundant filler. The primary action is stated upfront, and the Door 1 caveat is a concise but essential addition that earns its place. Every word contributes value.

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 no output schema, the description would need to clarify what the tool returns to make it fully complete. It mentions 'status' and the Door 1 rule, but does not describe the overall return shape, possible statuses, or whether multiple doors are included. Without that, an agent may struggle to correctly interpret the response, though the simplicity of the tool mitigates the gap. The description is adequate for initiating a call but leaves some ambiguity for downstream use.

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 tool has zero parameters and the input schema is empty, so there is no parameter complexity to document. Per the baseline for 0-parameter tools, a score of 4 is appropriate; the description adds no parameter information because none is needed.

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 uses the specific verb 'fetch' with resource 'payroll run status', clearly identifying the tool's function. The additional note about Door 1 provides scoping detail, but it does not explicitly differentiate from the sibling qbo_payroll_preview, leaving some ambiguity about the exact boundary between them.

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?

There is no guidance on when to use this tool versus alternatives like qbo_payroll_preview. The Door 1 note is a behavioral caveat, not a usage directive. Without explicit 'use when' or 'instead of' information, an agent must infer the appropriate context.

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