list_accounts

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the return format ('structured dict with account metadata'), explains MCC traversal depth, and clarifies that only 'accessible' accounts are listed. This adds meaningful insight beyond the tool's name.

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 concise overall, with the main purpose stated first and a clear recommendation. The inclusion of the source and implementation note ('Source: ...') adds minor noise but does not detract significantly from readability.

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 covers the tool's core functionality, return format, traversal depth, and a clear use case. With an output schema present, this is largely sufficient. However, it does not differentiate the tool from the similar sibling list_accessible_customers, which is a small gap.

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 tool has zero parameters, so the baseline of 4 applies per the rubric. The input schema is empty, and the description correctly focuses on behavior rather than parameter details, which are unnecessary here.

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 action ('List all accessible Google Ads accounts'), the resource ('Google Ads accounts including MCC sub-accounts'), and adds specific scope ('up to two levels deep'). This distinguishes it from reporting tools and provides a concrete verb+resource structure.

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 explicit usage context: 'Recommended first step: run this to discover available customer IDs before calling any reporting tools.' However, it does not mention when to avoid this tool or compare it to the sibling list_accessible_customers, which might serve a similar purpose.

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