cyberqp_get_customer_accounts

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds meaningful context by explicitly guaranteeing that passwords and OTP codes are never returned, and by stating that only metadata fields (id, username, type, status) are included. It does not explain pagination behavior, response shape, or ordering, but the security boundary is a strong and useful behavioral disclosure.

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, then adds the security-relevant caveat and the optional filter. Every clause earns its place; there is no filler or repetition of obvious information.

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?

For a list tool with 5 parameters, one required, and no output schema, the description explains what is returned (metadata fields) and what is never returned (passwords/OTP). It is missing explicit mention of pagination response behavior and how cursor/page/limit interact, but the input schema covers the parameters. Overall it is reasonably complete for a simple metadata list operation.

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 has 100% description coverage, so the baseline is 3. The description adds no new parameter meaning beyond the schema: accountType is already described as a filter with the same enum values, and page/limit/cursor are already documented. The description's mention of the filter is helpful but redundant with the schema.

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 uses a specific verb ('List') with a clear resource ('account METADATA for a customer') and enumerates the returned fields (id, username, type, status). It also draws a clear line against sensitive data ('never returns passwords or OTP codes') and distinguishes itself from the sibling count tool by emphasizing listing metadata rather than counting.

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 implies the usage context: call this when you need account metadata for a customer, optionally filtered by account type. However, it does not explicitly state when to prefer this over cyberqp_get_customer_accounts_count or other account-related siblings, nor does it mention any conditions where this tool should not be used.

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