Get Rapid7 Statistics

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and side-effect behavior. The description adds that tables not loaded are omitted and returns JSON, which is useful context. No contradictions. The description does not mention performance or rate limits, but for a read-only, idempotent tool, the transparency is adequate.

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 clear and well-structured with bullet points for the return value and behavior. However, it is slightly verbose for a tool with no parameters; a more concise version could combine the first two sentences. Overall, it is front-loaded but not as tight as possible.

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 zero parameters, comprehensive annotations (read-only, idempotent, non-destructive), and the presence of an output schema (mentioned but not shown), the description covers all necessary context. It explains what tables are included, the omission of unloaded ones, and the return format. For this simple tool, the description is complete.

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?

There are no parameters, so the input schema is fully covered (100%). The description adds meaning beyond the schema by specifying the tables included and the omission behavior. Since there are no params, the description perfectly compensates for any lack of parameter documentation.

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: getting summary statistics for all database tables. It lists specific tables (assets, vulnerabilities, policies, vulnerability_remediation) and notes that unloaded tables are omitted. This distinguishes it from siblings like query_rapid7 (which likely runs arbitrary queries) and list_rapid7_exports (which lists 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 mentions the tool is 'useful for getting an overview of the data across all loaded datasets,' which provides some context. However, it does not explicitly specify when not to use it or compare to alternatives like query_rapid7 or get_rapid7_schema. A stronger statement about when to choose this over siblings would improve clarity.

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