get_r_report_queries_application_vulnerabilities_net

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool calls a GET endpoint, which implies a read-only operation, but it does not disclose any potential side effects, authentication requirements, rate limits, or response characteristics beyond the existence of an output schema. The description adds minimal behavioral context beyond what the HTTP method implies.

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 sentence that front-loads the endpoint and then briefly explains the parameter placement. It is concise and avoids unnecessary verbosity. The phrasing 'Retrieve records Calls `GET /r/...`' is slightly awkward and could be cleaner, but overall it is efficient and structured well.

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 large number of sibling tools with similar names (e.g., application_vulnerabilities, application_vulnerabilities_tag, application_vulnerabilities_suppressed, etc.), the description is incomplete because it does not clarify what makes this 'net' variant unique. It also does not mention any prerequisites, authentication context, or what the output represents. The existence of an output schema mitigates some return-value ambiguity, but the description still lacks sufficient context for an agent to confidently choose this tool over its many siblings.

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 schema has zero property descriptions and the parameters are generic catch-all objects (body, query, headers, path_params). The description adds value by specifying that path_params are for 'route IDs', query is for 'filters and pagination', and headers are for 'required request headers'. This gives some semantic meaning to the otherwise opaque parameters, but it does not detail what specific filters or pagination parameters are expected, leaving the agent to guess the exact keys.

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 ('Retrieve records') and names the exact endpoint via the GET call, so it is clear what resource is being accessed. However, it does not distinguish this tool from the many sibling tools that serve similar report queries, such as get_r_report_queries_application_vulnerabilities or the various tag/suppressed variants. It relies on the name to convey the 'net' distinction, which is not explicitly clarified in the description.

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?

No guidance is provided on when to use this tool versus the many similar report query tools. The description only explains how to structure the call (path_params, query, headers) but does not mention any context, such as what 'net' means or when a user would need this over the non-net variant. There is no explicit when-to-use or when-not-to-use guidance.

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