linkedin list ad accounts

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower; the description still adds real value by disclosing the hard scoping rule (only accounts in the LINKEDIN_ADS_ACCOUNT_IDS config are ever returned) and the default exclusion of test accounts. It does not discuss pagination or result caps for accounts outside the allowlist, leaving only a minor gap.

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 compact sentences, front-loaded with the verb, resource and the configuration-bound scope. Every clause carries information: reachability, the exclusion of out-of-config accounts, and the test-account default. No filler or repetition.

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 values need not be spelled out, and the description covers scope, defaults and exclusions for a zero-required-parameter read tool. The only thing an agent might still want is whether the allowlist is enforced as an error or a silent filter when adAccountIds includes unconfigured IDs.

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%, so each of the three parameters is already documented, establishing a baseline of 3. The description reinforces the adAccountIds default ("every configured account") and the includeTestAccounts default, but adds no filtering semantics for the status array beyond what the schema states.

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?

Specific verb+resource ("List the LinkedIn sponsored ad accounts") with explicit scope (accounts configured in LINKEDIN_ADS_ACCOUNT_IDS reachable by the authenticated member) and the fields returned (currency, status, serving status). It distinguishes list-of-configured-accounts from a detail fetch by implication, but never names or contrasts a sibling such as linkedin_get_account_details, so it stops short of full sibling differentiation.

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?

Usage context is implied rather than stated: "Accounts outside the configured list are never returned" and "Test accounts are excluded unless asked for" tell the agent what will not be returned and hint at when to set includeTestAccounts. There is no explicit guidance on when to choose this tool over linkedin_get_account_details or other listing siblings, and no stated prerequisites.

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