Get Ad Accounts

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations by stating that results are grouped by organization and include account IDs, names, and creation times. There is no contradiction with the annotations.

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 compact, with an opening sentence that states the core purpose and short sections for Args and Returns. There is minor redundancy: the return shape is described in prose and again in the Returns block, and the Args block repeats schema information. Still, the structure is scannable and every sentence is relevant.

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 simple read-only tool with one required parameter, comprehensive annotations, and no output schema, the description adequately covers the input, return grouping, and included fields. It does not mention pagination, errors, or authentication, but these are not critical given the tool's simplicity and annotation coverage.

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 already documents orgIds with a clear description and 100% schema description coverage. The description's Args section only restates the schema ('Array of organization IDs') without adding formatting, constraints, defaults, or relationships, so it provides no added meaning beyond 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 'Get' with resource 'ad accounts' and a scope 'for specified organizations,' and also mentions the return format (grouped by organization with account IDs, names, and creation times). This clearly differentiates it from sibling tools that operate on campaigns, ad sets, and ads, none of which list ad accounts.

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 usage when an agent needs ad accounts for a set of organization IDs, but it never explicitly states when to prefer this tool over alternatives or when not to use it. Because no sibling tool targets ad accounts, the context is reasonably clear but implied rather than stated.

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