zdx_get_web_probes

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

Annotations already declare readOnlyHint=true, and the description reinforces this with a 'Read-only.' statement, providing consistent context. It adds sequencing context about needing web_probe_id, but doesn't detail pagination or return format beyond 'full records'. Given annotations cover safety, a 4 is appropriate for the added operational context.

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 two sentences plus a detailed parameter note. It's front-loaded with the core purpose and usage, and the parameter explanation is dense but necessary. No fluff; every sentence adds value.

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 no output schema, the description provides adequate context: it mentions full records, gives a workflow pointer, and the query parameter warning about JMESPath is extremely valuable. For a list tool with 4 params and partial schema description, the description is nearly complete for practical use.

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 doesn't elaborate on device_id or app_id, but schema coverage is only 25%: the 'query' parameter is thoroughly explained with examples and a critical warning about field naming conventions. The 'since' parameter lacks description, but the overall explanation of query semantics compensates significantly. Given low schema coverage, the description adds substantial value for the query param, warranting a 4.

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 lists web probes for an app on a ZDX device, with 'full records' and specific resource/scope. It distinguishes itself by mentioning the specific use case for obtaining web_probe_id, which is unique among the large sibling list.

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?

Explicitly instructs to call this tool BEFORE zdx_start_deeptrace and explains why, providing a clear sequential workflow. This is strong usage guidance that differentiates it from alternatives.

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