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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: results are filtered to connect-time selections by default, and the response carries default_account_id. It does not describe ordering or pagination, keeping it short of 5.

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?

Three short sentences, each earning its place: identity, default scoping, then the parameter behavior. The scoping rule and the parameter effect are front-loaded in that order and there is no filler.

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?

An output schema exists, so return-value documentation is not required, yet the description still flags default_account_id as a useful response field. Combined with the annotation-covered safety profile and the explained parameter, an agent has enough to call it correctly; only ordering/pagination behavior is absent.

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% for the single all_accessible boolean, so the description must carry the meaning, and it does: true returns every account the credential can reach versus the default connect-time subset. It is not explicit about the default value being false, but the contrast makes the semantics unambiguous.

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?

States a specific verb (Lists) and resource (the user's connected Microsoft Advertising ad accounts), and the scope ('connected' vs 'accessible') separates it from generic list_accounts and from entity lists like list_microsoft_campaigns. An agent can identify the tool without opening the schema.

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 explains both operating modes: default returns only accounts selected at connect time, while all_accessible=true returns every account the credential can reach, giving the agent a clear basis for choosing a parameter value. It does not explicitly name a sibling or say when to prefer this over list_accounts, so it stops short of a 5.

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