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

Annotations already indicate read-only, idempotent, non-destructive. Description adds 'fast, non-blocking' and 'queries once' – complements annotations well. No contradictions.

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 terse sentences, front-loaded with purpose and behavioral traits. No extraneous text.

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 single param, rich annotations, output schema present, description covers purpose, behavior, param source. Fully sufficient.

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?

Only parameter export_id with description linking it to start_rapid7_export. Schema coverage 100%, description adds source info beyond schema.

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?

Clearly states it checks status of a Rapid7 export job. Verb+resource specific. No explicit differentiation from siblings but clear enough.

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?

Explicitly notes it's fast, non-blocking, and does NOT poll/wait. Implies use for quick status checks. Could mention when to use alternatives like polling.

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

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

Annotations already indicate the tool is not read-only (readOnlyHint=false), not destructive (destructiveHint=false), idempotent (idempotentHint=true), and open-world. The description adds behavioral context beyond annotations: it downloads Parquet files and loads them into the DuckDB database for querying. No contradictions with 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?

The description is three sentences, each serving a distinct purpose: stating the main action, providing a usage condition, and detailing the execution. No redundant or unnecessary words.

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 description explains the tool's purpose, when to use it, and what it does (downloads and loads into database). An output schema exists (not shown) so return values are covered. There is no mention of error handling or behavior for invalid export IDs, but the precondition partially addresses that. Overall, it is complete enough for a tool with rich annotations and schema.

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 coverage is 100% with both parameters having descriptions. The description does not add any additional information about the parameters beyond what the schema already provides. It reinforces that export_id must be from a completed export, but that is already in the parameter description. Baseline 3 is appropriate.

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 downloads a completed Rapid7 export and loads it into the database. It specifies the verb ('download' and 'load'), the resource ('completed Rapid7 export'), and the destination ('local DuckDB database'). It also distinguishes from siblings by referencing the workflow step (after check_rapid7_export_status).

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 explicitly instructs to call this tool after check_rapid7_export_status confirms the export is COMPLETE, providing a clear precondition. It does not directly list alternative tools, but the sibling list includes related tools like start_rapid7_export and check_rapid7_export_status, and the workflow context is clear.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds valuable behavioral details: returns column names and data types, omits unloaded tables, and returns formatted JSON keyed by table name. No contradiction.

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?

Concise at 4 sentences with front-loaded main purpose. No wasted words; every sentence adds value. Clear structure: main action, output details, usage hint, return format.

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 parameters and an existing output schema, the description is fully complete. It explains what the tool returns (schema of all tables, specific tables, omitted tables) and when to use it. No gaps remain.

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?

No parameters exist (schema coverage 100%), so baseline is 4. The description does not need to add parameter info but effectively describes the output, which is the only relevant semantic.

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 retrieves the schema of all database tables, listing specific table names (assets, vulnerabilities, etc.) and noting omitted tables. This distinctly differentiates from sibling tools like query_rapid7 or export-related tools.

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?

Explicitly advises using this tool to understand available data before writing queries, which is the primary use case. Does not specify when NOT to use it, but the context is sufficient for an agent to decide.

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

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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns metadata fields like export ID, date, status, type, and row counts, which is useful context beyond annotations. However, it does not disclose pagination, ordering, or time window for 'recent'.

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?

Only two sentences, front-loaded with the main action. Every sentence adds value without redundancy or unnecessary detail. Highly efficient.

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's simplicity (single optional parameter, output schema exists), the description covers purpose, scope, and returned fields. However, it could clarify 'recent' (e.g., default time window) and note whether results are sorted. Overall adequate with minor gaps.

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% (limit parameter is well-defined). The description does not add any additional meaning or context beyond what the schema provides, resulting in a baseline score of 3.

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 specific verb 'list' and resource 'Rapid7 exports', with scope 'recent' and 'tracked in the system'. It differentiates from sibling tools like check_rapid7_export_status or download_rapid7_export by focusing on listing metadata for available 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?

Implicitly indicates use case ('useful for understanding what exports are available for reuse'), but does not explicitly mention when not to use or provide alternatives among siblings. No usage exclusions or context for when to choose this over other tools.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, which aligns with loading data. The description adds that it skips the export process and is faster. It does not mention error handling or file existence, but overall provides useful behavioral 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 description is three sentences, each adding value. No fluff. Purpose is front-loaded. It is concise and structured effectively.

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?

For a simple tool with one parameter and an output schema, the description covers the main purpose, usage scenario, and speed benefit. It does not need to explain return values due to output schema. Complete for the given complexity.

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 'parquet_path' has 100% schema coverage, baseline is 3. The description adds value by stating it can be a file or directory, which goes beyond the schema description. It clarifies the format.

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 tool's name and description clearly state it loads vulnerability data from Parquet files. The verb 'Load' is specific, and the resource is well-defined. It distinguishes itself from sibling tools like 'download_rapid7_export' and 'query_rapid7' by focusing on existing files.

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 explicitly says when to use: when you already have Parquet files and want to skip the export process. It mentions speed advantage. It could be more explicit about not using it if files are missing, but the context implies alternatives.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. Description adds specific details on what is deleted (databases, WAL files) and permanence, enriching 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 paragraphs with bullet points, front-loaded with main action. Every sentence adds value without redundancy.

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?

For a simple destructive tool with no parameters, the description covers purpose, usage, consequences, and return value. Output schema exists but return is adequately described.

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?

No parameters, so schema coverage is 100%. Description adds value by explaining the tool's action and consequences, which is sufficient for a parameterless tool.

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?

Description states verb 'purge' (delete) and specific resources: 'local Rapid7 data and tracking databases', listing exact databases removed. Distinguishes from sibling tools which handle exports, queries, etc.

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?

Explicitly states when to use: 'when you are done with your analysis session, before handing off a machine, or to free disk space'. Also notes consequence: need to re-run export.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered without description support. The description adds meaningful behavioral context beyond annotations: the SQL dialect is DuckDB, the data originates from Rapid7 InsightVM Bulk Export Parquet files, and arbitrary SQL filtering/aggregation/joining is allowed. It does not mention query limits or performance caveats, but the annotation coverage lowers the burden.

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 long, but every section earns its place: the first sentence states the core capability, the table and field listings are directly needed for constructing valid SQL, and the examples illustrate expected usage. It is well-structured with clear headings and front-loaded purpose.

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?

For a SQL-query tool, the description is complete: it names the database, enumerates every table and key field, explains that DuckDB SQL is supported, and provides concrete examples. The presence of an output schema means return-value documentation is unnecessary, and the annotations cover the tool's read-only, idempotent nature.

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?

Although the schema already describes the single 'sql' parameter, the description dramatically expands its meaning by listing all valid tables, their key columns, and four concrete example queries. This tells the agent exactly what kinds of SQL statements are acceptable and what data surfaces exist, going far beyond the schema's one-line description.

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 action and resource: 'Execute a SQL query against the Rapid7 database.' It then enumerates the exact queryable tables and their key fields, which clearly distinguishes this tool from siblings that load, export, or manage Rapid7 data. The purpose is unmistakable and fully scoped.

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 states when to use the tool: 'Use this tool to query any of the above tables,' and shows realistic analytic examples. However, it does not explicitly name sibling tools or state when not to use it, leaving some alternative-selection reasoning to the agent. The context is strong but not fully explicit.

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

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

Annotations indicate idempotentHint=true, and description explains that existing exports are reused. It also discloses non-blocking nature, background processing time (3-5 minutes), and automatic date range splitting. No contradictions; adds context 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?

Well-structured with clear paragraphs and bullet points. Each sentence adds value, no fluff. Information is front-loaded and logically organized.

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 output schema exists and schema coverage is 100%, the description provides complete behavioral guidance: initiation, monitoring, download, deduplication, and date handling. No gaps for an agent to invoke 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?

Schema covers all 3 parameters with descriptions. Description adds crucial context: export_type specifies the type, start_date/end_date are only for remediation, with default behavior (30 days ago to today) and automatic 31-day chunking. Schema coverage is 100%, but description provides additional semantic value.

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?

Description explicitly states the tool starts a Rapid7 export job (non-blocking), specifies export types, and automatically splits long date ranges for remediation exports. It clearly distinguishes from sibling tools like check_rapid7_export_status and download_rapid7_export.

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?

Provides clear when-to-use (to initiate an export) and what to do after (monitor with check_rapid7_export_status, download with download_rapid7_export). Explains duplicate detection (returns existing ID if today's export exists) and the 31-day chunking behavior for remediation exports.

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