list_ad_accounts

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful context beyond that: it enumerates the returned fields (names, IDs, status, currency, serving statuses) and the authenticated-user access scope. It omits pagination/result-limit behavior, which keeps it off a 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, front-loaded with what is listed before what is returned and when to use it. There is minor overlap between 'all accounts accessible to the authenticated user' and 'get an overview of all accounts', but no wasted sentences.

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?

With no output schema, describing the returned fields is necessary and it is done. All three parameters are covered by the schema and safety is covered by annotations, so the only remaining gap is pagination/ordering behavior and any result cap on an openWorld list call.

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 100%: each of the three filters (type, status, includeTest) is documented in the schema with enums and a default. The description adds no filter syntax, combination rules, or defaulting behavior, so the schema carries the full burden and the baseline of 3 applies.

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 states a specific verb and resource ('Lists all LinkedIn Ad Accounts') and scopes it to accounts 'accessible to the authenticated user', so the agent knows exactly what set is returned. It does not explicitly distinguish itself from the sibling get_account_details, which is the one overlap an agent might hesitate on.

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 gives clear positive usage context: 'Use this to get an overview of all accounts or find a specific account ID.' That covers the two realistic intents (browse vs. resolve an ID). It stops short of naming when NOT to use it (e.g., use get_account_details when you already have the ID and want detail), so it is clear but not fully routing.

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