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

Annotations already mark it destructive, non-idempotent and open-world, but the description adds genuinely non-obvious behavior: every call creates a proposal the user approves before anything changes, and creates land PAUSED. The approval workflow and paused-by-default semantics are exactly the context an agent cannot get from the annotation flags.

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?

It is dense but well front-loaded: routing decision first, then the naming trap, then invocation, then the tool list by category. The October 2025 naming paragraph is long but earns its place because it prevents a real mis-parameterization (campaign vs ad set).

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 router over 17 sub-tools with no output schema, the description supplies everything needed: invocation shape, the read/write boundary, the naming disambiguation, approval and pause behavior, and the full category inventory. No material gap remains for correct use.

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 100%, so the three parameters are already documented. The description still adds value by pinning action to the single valid value 'execute' and clarifying that tool_name is the exact name of the mutating tool, plus that list_tools/get_tool_schema live on the read router. Slightly beyond the schema-only baseline.

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 role (the 17 LinkedIn Ads write tools that create, update, pause or remove) and immediately names the sibling it is not: linkedin_ads, the read router. An agent can distinguish this router from linkedin_ads without opening either 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?

It gives explicit when-not guidance ('Reading, listing or checking anything is not here... calling this router to look something up is always wrong'), points to linkedin_ads and linkedin_get_campaign_structure for lookups, and states the operative constraints ('One account per call, no fan-out'). Nothing is left to inference.

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