Check Rapid7 Export Status

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds substantial behavioral detail beyond those hints: local download/load progress, per-file progress, skipping the API call when the local phase is active, returning stored summary/error on completion/failure, durable tracker behavior across restarts, and explicit non-polling semantics. This is rich, accurate, and useful context.

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 summary sentence is front-loaded, followed by a well-structured bullet list that clarifies each possible state. The additional paragraph about the durable tracker and restart reconciliation earns its place by explaining observable behavior. No sentence is redundant or wasted.

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 presence of an output schema and comprehensive annotations, the description covers everything an agent needs: when to use it, what phases it reports, how it behaves in each phase, restart behavior, and the fact that it is non-blocking and non-waiting. There are no meaningful gaps for selecting or invoking this tool correctly.

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 single parameter export_id is fully documented in the input schema, including its origin from start_rapid7_export or a multi-window remediation load. With 100% schema description coverage, the description itself does not need to add parameter detail. The baseline of 3 is appropriate because the schema carries the parameter semantics.

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 Rapid7 export, including local download/load progress.' This clearly differentiates it from sibling tools like start_rapid7_export, download_rapid7_export, and load_rapid7_parquet, which perform different actions on exports.

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 clearly conveys when to call the tool: after an export has been started, to inspect platform-side or local progress. It also states behavioral boundaries like 'Does NOT poll or wait' and explains when the Rapid7 API call is skipped. It does not explicitly name alternative tools or exclusion conditions, but the context is strong enough for an agent to select it appropriately.

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