get_report_queries_adaudit

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. The description only restates the HTTP method and parameter placement; it doesn't disclose whether this is a read-only operation, whether it requires authentication, what the response shape is, or any side effects. For a GET endpoint, the read-only nature is implied but not explicitly stated, and the lack of any behavioral context beyond the endpoint path is a significant gap.

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 core action and endpoint, then provides parameter placement guidance. It's appropriately sized for the information it conveys, with no wasted words. It could be slightly more structured by separating the endpoint from the parameter instructions, but it's 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 has an output schema, the return value may be documented there, but the description still lacks critical context: what 'adaudit' data is, what filters are available, what route IDs are needed, and what headers are required. With no annotations and a generic schema, the description leaves too much for the agent to infer. The sibling list shows many similar report query tools, and this description doesn't help an agent understand what makes this one distinct in terms of data or use case.

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 0%, so the description must compensate for the schema's lack of parameter documentation. The description does explain the general role of each parameter container (path_params, query, headers), which is helpful. However, it doesn't specify which route IDs are valid, what filters or pagination parameters are supported, or what headers might be required. The schema itself is just generic objects with additionalProperties, so the description adds only minimal meaning.

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') and resource ('adaudit Calls GET /report_queries/adaudit'), which clearly identifies the endpoint. It distinguishes this tool from the many sibling report query tools by naming the specific 'adaudit' resource. However, it doesn't explain what 'adaudit' means or what the returned data represents, so it's clear but not fully self-contained.

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 gives basic guidance on where to put parameters (path_params, query, headers), which is useful for calling the tool. However, it doesn't state when to use this tool versus alternatives, nor does it mention any prerequisites or context for when this specific report query is appropriate. The guidance is about mechanics, not selection.

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