get_report_queries_ad_group_computers

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

There are no annotations, so the description must carry the behavioral transparency burden. It does reveal that the operation calls a GET endpoint, implying read-only behavior, and that there may be required request headers, hinting at authentication. But it does not disclose side effects, rate limits, or any non-obvious runtime behavior, leaving the behavior profile only partially explained.

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 exactly two sentences, with the core purpose front-loaded and the parameter routing sentence adding immediate functional guidance. No filler or redundant wording; every phrase earns its place.

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?

Despite the presence of an output schema, the means to correctly invoke the tool are under-specified. The description says to pass 'route IDs' but does not state which IDs or even whether they are mandatory, enumerates no example query filters or pagination names, and says nothing about the expected body. An agent cannot confidently assemble a valid request from the provided text.

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 input schema is entirely generic (open-ended body/query/headers/path_params objects with 0% coverage), so the description's mapping—route IDs in path_params, filters and pagination in query, headers in headers—provides the only semantic meaning. It compensates somewhat, but it still lacks specifics like which route IDs, which filter names, and whether body should be used, so it does not fully bridge the schema gap.

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 'Retrieve ad group computers', a clear verb-plus-resource statement that matches the tool name and endpoint. It identifies the resource (ad group computers) and the action (retrieve). It does not explicitly contrast itself with sibling tools like get_report_queries_ad_computers_view or get_report_queries_ad_group_users, so it misses the top score for differentiation.

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 provides no guidance on when to use this tool versus alternatives. It only says where to put parameters (path_params, query, headers), with no mention of that is not the right choice, no exclusions, and no implied conditions beyond the resource name. This is effectively no selection guidance.

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