get_zpa_enrollment_certificate

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

The annotation already declares readOnlyHint=true, so the description's '(read-only)' adds no new information. However, it does describe the behavioral distinction between listing all records versus looking one up by name or ID, which is not explicit in the annotations. This helps an agent understand the tool's operational modes but doesn't dive into details like pagination behavior or error cases.

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, well-structured sentence that front-loads the core action and resource. It efficiently conveys the two primary modes of operation without any unnecessary fluff. Every word 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?

The description is adequate for a tool with six optional parameters but leaves gaps. It explains the primary use cases but doesn't clarify the semantics of 'search' or default pagination behavior (e.g., default page size). The interaction between 'query' and other parameters is also unspecified, though that is partially addressed in the 'query' parameter's own description.

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 only 17% (only 'query' has a schema-level description). The main description partially compensates by mapping 'name' and 'ID' to lookup semantics, which would otherwise be ambiguous. However, it fails to clarify the meaning of 'search' (fuzzy vs. exact) and the role of 'page' and 'page_size' beyond inference from their names.

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 a strong verb ('Read'), identifies a specific resource ('ZPA enrollment certificates'), and concisely conveys two modes: listing all or looking up by name/ID. This clearly distinguishes it from sibling tools like 'zpa_get_pra_credential' or 'zpa_list_lss_configs' by resource type.

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 offers no explicit 'when to use' guidance, no mention of alternatives, and no exclusions (e.g., 'for PRA credentials use get_zpa_pra_credential'). It's implied the tool is for enrollment certificates, but this is redundant with the name and does not help an agent decide between this and other ZPA-specific read tools in the large sibling set.

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