linkedin get creatives

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuine domain context by explaining that a creative carries its own intended status, review verdict, and rejection reasons, which helps interpret results. It says nothing about pagination behavior, account allowlisting (LINKEDIN_ADS_ACCOUNT_IDS), or the cost/shape of includeContent.

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?

Two sentences, zero waste: the action and scope come first, then a compact domain definition that earns its place by clarifying what the returned entities represent.

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 explanation is not required, and annotations plus full schema coverage handle the rest. The remaining gap is sibling disambiguation against linkedin_list_ad_creatives and linkedin_get_entity, which the description does nothing to resolve — a real risk for tool selection in a 17-tool cluster.

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 all six parameters are already documented in the schema, including the distinction between intendedStatuses and effective delivery status. The description reinforces only the campaignIds scenario; it adds no syntax, defaults, or edge-case detail beyond the schema. Baseline 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?

States a specific verb and resource ("List the creatives of a LinkedIn ad account") with scope (optionally narrowed to campaigns), and defines what a creative is. However, it never differentiates itself from the near-identical sibling linkedin_list_ad_creatives, leaving an agent unable to tell the two apart from the text alone.

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 is only implied: "optionally for given campaigns" hints at the filtering scenario, and the framing around review verdict / hold-back reasons suggests it is the tool to reach for when diagnosing non-delivery. But there is no explicit when-to-use, when-not, or pointer to linkedin_list_ad_creatives or linkedin_get_entity as alternatives.

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