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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses that the campaign is created on LinkedIn immediately, that an externalId is returned, that spend ceilings and the linkedin_ads feature flag are enforced server-side and cannot be bypassed, and that the new campaign starts with no creatives. This is substantive side-effect context that annotations alone do not provide, with no contradiction.

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?

Four sentences front-load the core action, then layer behavioral caveats, money-object semantics, and sibling routing in a logical order. Each sentence earns its place, though the server-side enforcement sentence is slightly wordier than the rest.

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 complex 13-parameter tool with nested money objects, four enums, and no output schema, the description covers the essential invocation facts: side effect, return value, budget shape, server-side constraints, and post-creation state. It does not clarify whether a budget or schedule is required for a valid campaign, and it omits any cost implications of the live write-through, but an agent can confidently invoke the tool using the two required params listed in the schema.

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?

With 62% schema coverage, most parameters are already documented in the schema; the description adds value by consolidating that dailyBudget, totalBudget, and unitCost all share the same money-object shape, which is most helpful for unitCost, whose schema entry only calls it a bid amount. It also reinforces the adAccountId lookup path. Semantics for name, format, objective, and bidStrategy are left to their enums, and the description does not compensate for those gaps.

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 opening sentence 'Create an ad campaign' states a specific verb and resource, and the description immediately disambiguates it from the closely related campaignstack_create_ad_creative by noting the new campaign has no creatives yet and directing the agent to add them separately. The write-through nature and the returned externalId further pin down exactly what this tool does.

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 gives explicit prerequisite and follow-up routing: it names campaignstack_list_ad_accounts for finding adAccountId and campaignstack_create_ad_creative for adding creatives, which is actionable guidance. It does not, however, state when not to use this tool or contrast it with siblings like campaignstack_generate_ad_campaign or campaignstack_update_ad_campaign.

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