list_phishing_campaigns

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

No annotations are provided, so the description carries the full burden. It discloses the HTTP method (GET) and parameter routing, but doesn't mention pagination behavior, response shape, authentication needs, or any side effects. For a list operation this is a moderate gap.

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?

Two sentences, front-loaded with the core action and endpoint, then routing guidance. No wasted words, though the routing guidance could be more specific.

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 an output schema, so return values are covered elsewhere. But with 0% schema coverage, no annotations, and generic schema properties, the description should explain what route IDs are expected, what query parameters are supported, and how this relates to sibling tools. It doesn't.

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% and the schema is generic (body/query/path_params with additionalProperties). The description adds some meaning by saying route IDs go in path_params and filtering/pagination/sorting/include values go in query, but it doesn't specify which route IDs, what filter keys exist, or what include values are valid. It partially compensates but leaves most semantics undefined.

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 states a specific verb and resource ('List phishing campaigns') and names the exact HTTP endpoint. It distinguishes from siblings like get_phishing_campaign and list_phishing_campaign_attempts by the resource and list scope, though it doesn't explicitly name a sibling.

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 gives clear routing guidance: route IDs go in path_params and filtering/pagination/sorting/include values go in query. However, it doesn't state when to prefer this tool over alternatives like list_account_phishing_campaigns or get_phishing_campaign, nor any exclusions.

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