zdx_get_application_user

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

Annotations already declare readOnlyHint=true, and the description reiterates 'Read-only', which is consistent. It adds value by describing the return structure (user's score plus nested per-device metrics) and explains the 'since' parameter (hours window, default 2h). No behavioral 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?

The description is three sentences long. The first sentence states the core purpose, the second adds read-only and return details, and the third provides parameter dependencies. Every sentence adds value with no 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?

With no output schema, the description adequately describes the return structure (user score and nested per-device metrics) and the 'since' window. It does not cover error cases or pagination, but for a targeted read-only detail tool, this is sufficient given the sibling context and annotations.

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. It explains where to get app_id and user_id from other tools, and clarifies the 'since' parameter as a window in hours with a default of 2h (though schema default is null, which could cause minor confusion). The explanation adds meaning beyond the bare schema, but more detail on parameter format could improve.

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 a single user's ZDX detail for an application with a per-device breakdown. It specifies the returned data (user score and per-device metrics), distinguishing it from sibling tools like zdx_list_application_users (lists users) and zdx_get_application (overall app data).

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 explains the tool is read-only and guides the user to obtain app_id from zdx_list_applications and user_id from zdx_list_application_users. This provides clear context for when to use the tool, though it does not explicitly exclude alternatives or specify when not to use it.

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