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

Annotations already establish readOnlyHint, idempotentHint, destructiveHint and openWorldHint. The description adds context beyond them by stating 'does not consume billing' and confirming read-only behavior, which is genuinely useful for an agent deciding whether to call it freely.

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?

Dense but front-loaded: what it searches, empty-query behavior, safety profile, return shape, and next step. Every clause earns its place, though the parenthetical about the OpenAI connector contract is slightly redundant.

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 one-parameter read-only search with an existing output schema, the description covers platforms, filter semantics, safety, return format, and the follow-up tool. Nothing an agent needs to call it correctly is missing.

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 coverage is 0%, so the description carries the burden for the single `query` parameter, and it does explain the critical semantic: an empty query returns all accounts rather than nothing. It does not specify matching behavior (substring vs fuzzy), leaving a minor gap.

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 gives a specific verb (searches) plus the resource (connected ad accounts), explicitly enumerates the platform sources (Google, Meta, LinkedIn), and names the follow-up sibling `fetch`. This distinguishes it from the many list_* tools that enumerate accounts per-platform.

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?

It states the empty-query condition clearly ('If query is empty, all connected accounts are listed') and routes the agent to `fetch` after obtaining an id. It lacks an explicit when-not-to-use note versus `list_accounts`, which is the nearest apparent alternative.

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