get_report_queries_get_user_details

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention whether the operation is read-only, what permissions are required, what side effects occur (if any), or what happens on failure. The only behavioral hint is that it is a GET call, but that is not explicitly stated. The description is nearly silent on anything beyond parameter placement.

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 reasonably concise at two sentences, but the opening phrase 'Retrieve get user details' is awkward and redundant, wasting a few words. The parameter guidance is front-loaded but could be more compact. It is not excessively long, but the redundancy prevents a higher score.

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 tool has 4 optional parameters, no required fields, and an output schema (though not shown). The description does not explain the purpose of the route IDs, the specific filters or pagination mechanism, or any response expectations. It lacks context about the typical use case, what constitutes a valid call, and how it fits into the broader report query functionality. Despite the output schema presumably covering return values, the description is far too thin for an agent to call this correctly without external knowledge.

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 description does add some meaning to the parameters that are otherwise empty objects in the schema. It indicates path_params holds route IDs, query holds filters and pagination, and headers holds request headers. However, it is vague—'route IDs' is ambiguous, and 'filters' and 'pagination' are not defined in detail. Given the schema has 0% description coverage and 4 parameters, the description partially compensates but does not fully clarify the parameters' actual content or 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 description says 'Retrieve get user details' which is a redundant restatement of the tool name. It does not specify what 'user details' means, what data is returned, or how it differs from sibling tools like get_r_user_get_users or other report query tools. The specific verb and resource are unclear, and there is no differentiation from the many similar report query 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?

There is no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or excluded scenarios. The description only describes the HTTP call and parameter placement, leaving the agent to infer when it would choose this over a sibling like get_r_user_get_users or get_report_queries_get_groups_details.

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