reach_listAutomationsV1

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 discloses that the tool is paginated, and clarifies the semantic meaning of the returned counts (contact journey metrics, not engagement metrics). However, it does not specify side effects (none expected, but no readOnlyHint is present), authentication requirements, rate limits, or default ordering/pagination behavior. The description adds value but leaves gaps that the schema partially fills (e.g., sort_direction). A score of 3 reflects adequate disclosure without contradiction.

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. The first sentence states the primary purpose and scope. The second sentence provides a crucial clarification about the meaning of counts and directs users to an alternative endpoint for engagement metrics. Every sentence earns its place, and it is front-loaded with the most important information. No fluff or repetition.

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 no output schema, so the description should compensate by explaining what the response looks like. It mentions that pagination is used and that each automation includes certain counts, but it does not describe the overall response structure (e.g., does it return an array, a pagination envelope with next page info?), nor does it mention what other fields (like name, status) are included. It also does not elaborate on the profileUuid context beyond the schema. Given the tool's relative simplicity, these gaps prevent a higher score.

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, meaning every parameter is described. The description does not add parameter-level meaning beyond the schema; it only explains the returned counts. According to the baseline rule, when schema coverage is high (>80%), a score of 3 is appropriate even if the description adds no parameter info. The description adds no extra semantic clarifications for parameters, so 3 is correct.

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's purpose: 'Get a paginated list of the automations in a profile.' It uses a specific verb ('Get') and names the resource ('automations'), and distinguishes itself from related tools by explicitly noting that the counts are contact journey metrics, not email engagement, and redirecting to the campaign statistics endpoint. This is a crisp, unambiguous purpose that differentiates this tool from siblings like reach_getAutomationDetailsV1 and reach_listCampaignsV1.

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 provides clear guidance on when NOT to use this tool: 'for opens, clicks and unsubscribes use the campaign statistics endpoint instead.' This is an explicit exclusion with an alternative. It also implies use for listing automations, but does not explicitly compare to other listing tools (e.g., list steps or list campaigns) or mention prerequisites beyond the required profileUuid. This is strong usage guidance but not exhaustive.

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