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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context ('Calculates percentage changes and highlights significant differences'), but says nothing about return format, significance thresholds, or how the two periods map to output.

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 the core action and scope. No filler, though the third sentence is somewhat promotional rather than informational.

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?

There is no output schema, and the description only vaguely gestures at results ('percentage changes', 'significant differences') without explaining the structure of the comparison output. For a nested-object, 4-required-param comparison tool, the safety annotations carry the rest, making this adequate but not complete.

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 accountId, comparisonType, and both period objects are already fully documented in the schema. The description adds no syntax or format detail beyond what the schema provides, so 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 gives a specific verb ('Compares') and concrete resources ('two time periods, campaigns, or campaign groups'), which distinguishes it from the single-scope siblings like get_campaign_performance. It stops short of explicitly naming a sibling to route against, so it is clear but not maximally differentiating.

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?

'Essential for reporting on performance trends' implies when the tool is useful, but gives no explicit when-to-use/when-not guidance and names no alternative (e.g., get_campaign_performance for single-period views). Usage context is only implied.

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

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

Annotations already declare openWorld, non-idempotent, destructive, and non-read-only behavior, so the safety profile is covered. The description adds nothing beyond that: no mention of required account permissions, whether campaigns are created in DRAFT by default, or what happens on repeat calls. Minimal added value.

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 short sentences with the action and scope front-loaded and no padding. The second sentence partially restates required-field information already visible in the schema, so it is efficient rather than maximally informative.

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 22-parameter destructive mutation with no output schema, the description is thin, though the high schema coverage compensates. It says nothing about the creation result (e.g., campaign ID) or default DRAFT status, leaving gaps an agent would need filled elsewhere.

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% with enums and defaults fully documented, so the schema carries the parameter burden. The description only names three required inputs generically ('targeting criteria, budget, and objective type') and adds no format or constraint details. 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?

Clear verb+resource ('Creates a new LinkedIn ad campaign') with placement scope ('within a campaign group') and a summary of the required inputs. It does not explicitly distinguish itself from siblings like create_campaign_group or create_creative, but the resource is unambiguous.

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 second sentence names the prerequisite inputs (targeting criteria, budget, objective type), which is useful context, but there is no explicit when-to-use vs. when-to-use-an-alternative guidance (e.g., update_campaign, create_campaign_group). Usage is only implied.

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

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

Annotations declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, which already flag this as a non-idempotent, destructive mutation. The description adds no behavioral context: it doesn't mention required permissions, what happens on failure, or that creation is irreversible. With annotations covering the safety profile at a high level, the description adds little beyond the basic action.

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 concise sentences that front-load the core action and then explain the resource's role. No redundant or filler content.

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 creation tool with 10 parameters, high schema coverage, and annotations covering safety, the description is adequate but minimal. It lacks details on return values (no output schema) and behavioral nuances like permissions or side effects, leaving some gaps.

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 the schema already documents all 10 parameters, including enums, formats, and immutability. The description provides no parameter-specific details, so baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Creates a new LinkedIn campaign group for organizing campaigns.' This clearly identifies the operation. It does not explicitly differentiate from siblings like create_campaign or update_campaign_group, but the 'campaign group' resource is distinct enough.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., create_campaign for individual campaigns). The description only states the purpose; it does not cover prerequisites, when-not-to-use, or the relationship with sibling tools such as create_campaign.

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

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

Annotations already declare a non-read-only, non-idempotent, destructive, open-world write, so safety context is covered. The description adds the behavioral nuance that without a content reference the creative is created as a reference to existing content, but says nothing about side effects, external API requirements, or resulting state beyond the default DRAFT in the schema.

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 short sentences, front-loaded with the action and scope, then the one non-obvious requirement. 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?

For a 7-parameter write tool with no output schema, the description omits what the call returns (e.g., the new creative URN) — information an agent likely needs for follow-up calls like update_creative_status. The critical inputs are covered by the schema, so this is adequate but with a real gap.

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 seven parameters (including the enum constraints and the leadgenFormId conditional) are already documented inline. The description reiterates the contentReference requirement, which is slightly useful framing, but adds no format or inter-parameter semantics beyond the schema.

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 ("Creates a new LinkedIn creative/ad") plus its placement scope ("under a campaign"), which separates it from generic create tools. It does not explicitly distinguish itself from the close sibling create_inline_ad, leaving that inference to the agent.

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 supplies one clear precondition (a content reference is required), but gives no guidance on when to choose this over create_inline_ad or how it relates to update_creative_status/create_campaign. Usage is implied from the create semantics rather than stated.

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

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

Annotations already declare the write/destructive, non-idempotent, open-world profile, so the description needn't restate safety. It does add useful behavior — that ad content and creative are created atomically in a single call — but says nothing about what is returned (no output schema) or required permissions/ordering beyond media upload.

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 the definition and mechanism, then the usage cue. Minor redundancy between "in a single call" and "from scratch," but nothing wasted.

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 12-parameter mutation with no output schema, the description covers what it does but omits the return value (e.g. created ad/creative ID) and any prerequisite ordering or account-scoping constraints. Adequate given the fully documented schema, but not complete for the tool's complexity.

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 every parameter (including the objective-conditional landingPageUrl and leadgenFormId requirements) is already documented in the schema. The description adds no format, default, or dependency detail beyond that, so 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?

States a specific verb and resource ("Creates a new LinkedIn ad with inline content") and clarifies the key mechanism: content and creative are built in one call without a pre-existing post. That implicitly differentiates it from the sibling create_creative, though it never names the alternative directly.

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?

"Use this to create sponsored content ads from scratch" gives an intended scenario but no explicit when-not-to-use rule or named alternative (e.g. "use create_creative instead if you already have a post"). Usage is implied rather than routed.

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

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

Annotations already declare destructiveHint=true, but the description adds critical subtype behavior: draft campaigns are deleted immediately while non-draft campaigns become PENDING_DELETION. This is exactly the 'what gets destroyed' context the bar rewards.

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, and the subtype-specific behavior is front-loaded after the core action. Efficiently structured.

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?

Complete for a destructive delete tool: annotations carry the safety profile, schema fully documents params, and the description fills the one remaining gap—how deletion behaves for drafts vs non-drafts. No output schema is needed since the operation returns no meaningful object.

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 schema already documents accountId and campaignId. The description adds no syntax or format details beyond what's in the schema. Baseline 3 is appropriate.

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 (deletes) + resource (LinkedIn campaign). Clearly distinguishable from sibling delete_campaign_group and update_campaign by naming the exact resource.

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?

No explicit when-to-use or when-not-to-use guidance, and no alternatives mentioned. The draft vs non-draft behavior is implied context, but doesn't route the agent to another tool.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description nonetheless adds genuinely new context: draft groups vanish immediately while non-draft groups only move to PENDING_DELETION status, which is the key operational distinction for a caller. It stops short of explaining what PENDING_DELETION ultimately means or whether child campaigns are affected.

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, both earning their place: the first establishes the action, the second front-loads the behavioral nuance that matters most. No filler, no repetition of the name or annotations.

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 destructive tool with full schema coverage and annotations, the definition covers the core nuance (immediate vs deferred deletion). However, it omits relevant consequences such as whether contained campaigns/creatives are also removed, whether the async deletion can be reverted, and what the caller must supply in terms of permissions.

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% (both accountId and campaignGroupId are documented in the schema), so the baseline of 3 applies. The description adds no syntax, format, or identifier guidance beyond the schema.

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 (Deletes) and resource (LinkedIn campaign group) that is inherently distinct from siblings such as delete_campaign and update_campaign_group. It never explicitly routes the agent between those siblings, but the resource noun does the disambiguation work.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives like update_campaign_group or delete_campaign. The draft vs non-draft sentence describes behavior, not the conditions under which an agent should pick this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and idempotency profile is covered by structured data. The description adds only the set of returned field categories; it says nothing about authorization requirements, error behavior on an invalid/non-numeric ID, or rate limits.

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?

One sentence, front-loaded with the verb and resource, with zero filler or repetition. Every clause (the enumerated field categories) carries information.

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 one-parameter read-only tool with full schema coverage and annotations covering the safety profile, the description is nearly sufficient, and its enumeration of returned fields partially compensates for the absence of an output schema. It stops short of covering failure modes or ID format validation beyond the schema note.

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?

There is a single parameter with 100% schema description coverage, and the schema already supplies the key nuance ('numeric ID, not the URN'). The description adds no parameter-level detail beyond the schema, which is the expected baseline when coverage is high.

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 (Retrieves) and resource (LinkedIn Ad Account details) and enumerates the fields returned (status, currency, notification settings, linked organization). The phrase 'a specific ... Account' implicitly distinguishes it from list_ad_accounts, though the sibling is not named explicitly.

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 implied: it takes a single accountId and returns one account's details, so the agent can infer it is the point-lookup counterpart to list_ad_accounts. However, there is no explicit when-to-use/when-not guidance, no named alternative, and no prerequisites such as required permissions or valid-ID expectations.

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

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

Annotations already cover readOnly/openWorld/idempotent/destructive, so the safety profile is settled. The description adds a genuinely non-obvious operational behavior — that large metric selections are 'split and merged automatically', meaning results may be fetched via internal fan-out — which matters for latency and limit expectations and is not derivable from the schema or annotations.

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 with zero filler. The core capability is front-loaded in sentence one, and the auto-split/merge caveat follows immediately, earning its place by changing expectations about result assembly.

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?

There is no output schema, so return values need not be described, and annotations cover the safety profile. What remains missing for a 9-parameter, 0%-coverage query tool with demographic pivots and date parameters is format/permission guidance — accepted date strings, account scoping, and the practical meaning of the demographic pivot enum values.

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 0% across 9 parameters, so the description carries the burden and only partially does so: it names the metric, pivot, filter and granularity concepts but never explains date formats, ID formats, the 100-metric/500-entity caps, or what the 13 pivot enum values mean. It gives category-level mapping to the schema, not the format-level detail a 0%-coverage schema lacks.

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 (Query) and resource (raw LinkedIn analytics) and enumerates the dimensions of control: custom metrics, entity or demographic pivots, filters, time granularity. This implicitly distinguishes it from the fixed-shape siblings (get_campaign_performance, get_daily_trends), but it never names an alternative, so sibling differentiation is left to inference.

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 phrase 'custom metrics, entity or demographic pivots' implies this is the flexible/generic query tool to reach for when the prebuilt reports won't do, which is real implied guidance. However there is no explicit when/when-not statement and no mention of which sibling report tools it supersedes, so an agent must infer the routing.

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

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

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive), so the description's main contribution is the "12-24 hour delay" freshness caveat on demographic data, which the agent cannot learn from structured fields. It stops short of describing result volume, pagination, or whether the delay differs by dimension.

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 short sentences, front-loaded with what the tool returns and ending on the caveat. The "Essential for understanding..." sentence is mild sales framing rather than operational information, costing it a point.

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 read-only analytics tool with no output schema and full parameter documentation, the description covers purpose, the segmentation dimensions, and the data-latency caveat. Return shape is not explained, but no output schema exists to lean on, leaving a modest gap for a tool that can return ranked result sets.

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 all seven parameters including both enums are already documented in the schema. The description lists the demographic dimensions, but this only paraphrases the demographicType enum values and adds nothing on limit, metric, date handling, or campaignIds. 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 (retrieves demographic breakdown / performance segmented by dimension) and enumerates the segmentation dimensions, which implicitly separates it from get_campaign_performance and get_creative_performance. It never names a sibling tool outright, so an agent must infer the boundary rather than being told it.

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?

"Essential for understanding if you're reaching your target audience" gives a use case, but there is no guidance on when to prefer this over get_audience_reach, get_analytics, or compare_performance, and no exclusions or prerequisites. Usage is implied rather than specified.

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

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

Annotations already establish the read-only, idempotent, non-destructive, open-world profile, lowering the bar. The description adds domain context by defining the audiencePenetration metric and its formula, plus the 92-day date constraint, though the latter partly duplicates the schema.

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?

The definition leads with the purpose and keeps to four short sentences. The 'Helps understand what percentage...' sentence is somewhat redundant with the preceding metric definition, but overall it is well front-loaded and low-waste.

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, the description carries the burden of explaining return values, and it does define the key audiencePenetration metric. It stops short of describing other fields or aggregation/segmentation behavior, leaving a small gap for a reporting tool.

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 five parameters are already documented in the schema. The description adds no parameter-level syntax or format beyond the date-range note, so 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 (shows unique member reach / audience penetration for campaigns) and even names the exact metric returned (audiencePenetration). It does not, however, differentiate itself from siblings like get_audience_demographics or get_analytics, so an agent must infer when reach is the right report.

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: 'Helps understand what percentage of your target audience you've reached' suggests a reach-measurement context but gives no explicit when-to-use or when-to-prefer-a-sibling guidance. The 92-day constraint is included, which is useful, but no alternatives are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is fully covered structurally. The description adds useful domain context that campaign groups organize campaigns and control budget at a higher level, plus that performance data is optional and aggregated, but says nothing about pagination, result limits, or freshness of the performance metrics.

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 tight sentences with the core action front-loaded and no filler. The second sentence is explanatory rather than operational, but it is short and earns its place by disambiguating campaign groups.

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?

There is no output schema, so the description bears more burden for return values; it does say the response includes configuration and optionally aggregated performance, which is a reasonable sketch. However, it omits pagination, result limits, and how the date parameters interact with includePerformance, leaving gaps for a five-parameter list tool.

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 five parameters are already documented in the schema and the baseline is 3. The description's mention of optional aggregated performance loosely maps to includePerformance, but adds no syntax, date-format, or default details beyond what the schema provides.

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 ('Lists all campaign groups for an account') and clarifies the returned scope (configuration plus optionally aggregated performance). The second sentence explains what a campaign group is, which helps distinguish it from list_campaigns, though it never names that sibling explicitly.

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?

There is no when-to-use or when-not-to-use guidance, no mention of alternatives such as list_campaigns or get_campaign_performance, and no indication of when to enable performance or apply the status filter. The phrase 'optionally aggregated performance' hints at a use case but leaves the choice entirely to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive, so the safety profile is fully covered. The description adds the metric list returned, which is useful behavioral context given the absence of an output schema, but says nothing about rate limits, auth requirements, or response shape.

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 tight sentences: verb+resource first, return contents second, use case third. No filler, every sentence carries distinct information, and the actionable purpose is front-loaded.

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, the description compensates by listing the key metrics returned, and the schema fully documents all 7 parameters. It is nearly complete; a brief note on granularity/pagination behavior or how it relates to sibling performance tools would close the remaining gap.

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 7 parameters is documented in the schema itself, establishing a baseline of 3. The description adds no parameter-level detail (formats, filter behavior) beyond what the schema already 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?

States a specific verb and resource ('Retrieves performance metrics for campaigns') and enumerates the metrics returned, so the agent knows exactly what it gets. However, it does not differentiate itself from the many performance siblings (get_creative_performance, get_conversion_performance, get_daily_trends, compare_performance) beyond claiming to be the 'primary' tool.

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 primary tool for daily campaign monitoring and optimization decisions' implies a use case, which is better than nothing. But it names no alternatives and gives no when-not guidance, even though the sibling set contains several overlapping performance tools. The only alternative hint ('use get_analytics for raw custom metrics') lives in the schema, not the description.

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

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

Annotations already declare this is a read-only, idempotent, non-destructive, open-world operation, so safety is covered. The description adds genuinely useful output context (conversion attribution to campaigns, cost per conversion, conversion value), but says nothing about pagination, result limits, or latency on large date ranges.

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 compact sentences that front-load the primary purpose and then the return contents. No filler, no repetition of the tool name.

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, the description usefully sketches what comes back (per-conversion-type metrics with campaign attribution and cost/value). Given 100% schema coverage and full annotations, the only real gap is nothing about result size or granularity implications.

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 (dates, accountId, campaignIds, includePostView, timeGranularity) are already documented in the schema. The description adds no additional meaning about parameter behavior or formats, so 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?

States a specific verb ('Retrieves') and resource ('conversion metrics broken down by conversion type/action') and lists the payload dimensions (campaign attribution, cost per conversion, conversion value). It does not explicitly distinguish itself from siblings like get_campaign_performance or list_conversions, which an agent must infer from the 'by conversion type' framing.

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?

There is no guidance on when to choose this over get_campaign_performance, get_creative_performance, or list_conversions, nor any stated prerequisites or exclusions. Usage is only implied by the breakdown-by-conversion-type phrasing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context about what is returned (engagement metrics, video metrics, dwell time), but discloses no rate limits, aggregation behavior, or granularity semantics beyond the schema's default.

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 sentences, front-loaded with the core purpose and the metric categories, with no wasted filler. The closing marketing line ('Essential for creative optimization') is slightly promotional but harmless.

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, the description usefully enumerates the returned metric families, which is the key missing structured info. Safety and parameters are covered by annotations and schema, leaving little an agent needs that is absent.

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 all 7 parameters including date formats, granularity enum, and campaign/creative filters are already documented in the schema. The description adds no syntax or format detail beyond that, so 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?

States a specific verb ('Retrieves') plus resource ('performance metrics for individual ad creatives') and specifies the creative-level granularity, which implicitly separates it from campaign- or conversion-level siblings. However, it never names an alternative like get_campaign_performance or get_analytics, so the agent must infer the scope distinction.

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?

There is no explicit when-to-use or when-not-to-use guidance. 'Essential for creative optimization' is a benefit statement, not a routing rule, and no sibling or alternative is referenced.

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

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description usefully adds the return shape (time-series data), but says nothing about pagination, rate limits, or auth beyond what the schema implies.

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 tight sentences that front-load the core purpose before the analytic use cases. No filler, though the trailing purpose list is slightly redundant.

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 read-only reporting tool with full schema coverage and annotations covering safety, the description is adequate; it hints at the returned time-series nature. With no output schema, it could still say more about the structure of the trend series, but nothing critical to calling it is missing.

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 the schema already documents every parameter including formats and defaults. The description adds no syntax, defaults, or units beyond what the schema provides, making the baseline 3 appropriate.

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+resource combination ('Retrieves daily performance trends') and pins the granularity to daily time-series data. It is clear what the tool does, though it never names the sibling report tools (get_campaign_performance, get_analytics) it should be chosen over.

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 via the stated goals (visualizing patterns, spotting anomalies, day-of-week effects). There is no explicit when-to-use versus alternatives such as get_campaign_performance or compare_performance, nor any stated exclusions.

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

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 the returned metric set (submissions, qualified leads, cost per lead), which is useful. It says nothing about date-range behavior, granularity effects, row limits, or aggregation semantics.

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 with the core capability front-loaded in the first. The second sentence is soft marketing copy that gives an agent little actionable value, but the whole definition is short enough that nothing is buried.

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?

A read-only analytics tool with complete schema coverage and no output schema; the description compensates by naming the metrics returned. Safety is covered by annotations. Missing only guidance on the analytics siblings, which is a usage rather than completeness gap.

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 five parameters (accountId, startDate, endDate, campaignIds, timeGranularity) are documented at the schema level, including the enum and date format. The description adds no parameter-level meaning beyond that, so the 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 (retrieves) and resource (lead generation form performance) plus the three metric families returned: submissions, qualified leads, cost per lead. This distinguishes it from get_campaign_performance and get_conversion_performance by resource scope, though it never names those siblings explicitly.

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 only usage signal is the audience tagline 'Essential for B2B marketers running lead gen campaigns' – a persona statement, not a condition. It gives no guidance on when to pick this over get_conversion_performance, list_lead_forms, or get_analytics, and states no prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: it will not expose secrets and performs no network/API calls, which is exactly the kind of assurance an agent needs before surfacing config data.

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?

A single front-loaded sentence with no filler; the return content comes first and the two safety constraints ('without exposing secrets', 'without making API calls') are packed into the same clause without bloat.

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 zero-parameter, read-only status tool with full annotation coverage, the description is nearly sufficient — it names the data returned and the no-secrets/no-API guarantees. No output schema exists, and the description gives only a summary of the return shape rather than enumerating config fields, which is the one modest gap.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No syntactic or format guidance is needed for a no-arg call.

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 (Returns) and precisely names the two resources delivered: local configuration and token expiration status. The scope marker 'local ... without making API calls' cleanly separates it from the entire sibling set of ad-account/API tools.

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 — the 'local configuration and token expiration status' framing suggests a diagnostics/health-check use case, and 'without making API calls' hints at when it is cheap to call. No explicit when-to-use trigger or named alternative is given, so the agent must infer the context.

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

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.

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

Annotations already declare readOnly, idempotent, non-destructive, open-world reads, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it discloses result completeness (includes zero-impression DRAFT/PAUSED campaigns), which is exactly the trait an agent needs to reason about output. It doesn't mention pagination or result limits.

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, no filler, with the defining contrast front-loaded after the core purpose. Every sentence earns its place.

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 read-only list tool with full schema coverage and annotations, the description is nearly complete. The only unaddressed item is return volume/pagination behavior, which matters somewhat for a list endpoint with no output schema, but it is a minor gap.

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% and each parameter has its own description, so the schema carries the semantics. The description only echoes that campaign group and status filtering are supported, adding no syntax or format detail beyond structured data — baseline 3.

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 ('Lists campaigns') scoped to a LinkedIn Ad Account, and explicitly contrasts with get_campaign_performance by noting it returns ALL campaigns including DRAFT/PAUSED with zero impressions. An agent can distinguish it from the sibling 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?

Names the alternative (get_campaign_performance) and the condition that selects this tool instead (you need campaigns without analytics data). It stops short of stating an explicit when-not-to-use or a full routing rule, but the selection context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by listing the shape of returned fields and the account scoping, but says nothing about pagination, result limits, or permissions.

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 short sentences, front-loaded with the verb and resource, with the second sentence earning its place by previewing the returned fields. No filler.

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 read-only listing tool with full annotation coverage and complete parameter documentation, the description is nearly sufficient; listing the returned fields compensates for the absent output schema. Only the lack of any routing hint toward get_conversion_performance keeps it from being fully complete.

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 both accountId and the enabledOnly filter are fully documented in the schema; the description adds no syntax or format detail beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (Lists) and resource (conversion tracking rules) scoped to an account, and enumerates the returned fields (names, types, attribution windows, enabled status), which implicitly separates it from the performance-oriented sibling get_conversion_performance. It stops short of naming that sibling explicitly, so it is clear but not fully differentiated.

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?

There is no when-to-use or when-not-to-use guidance, and no mention of the closely named alternative get_conversion_performance. An agent must infer from 'configured for an account' that this returns configuration rather than metrics.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered without the description. The description adds that results include questions and settings, which is mildly useful, but says nothing about pagination, result limits, or ordering.

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 short sentences, front-loaded with the core action. The second sentence is largely redundant with the first ('their questions and settings' vs 'their configuration'), which is the only waste.

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 simple read-only list tool with no output schema, the description covers what is returned (forms plus questions and settings) and the account scope. Only the absence of any note on result volume or pagination keeps it from being fully complete.

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 accountId, status (DRAFT/PUBLISHED/ARCHIVED), and includeQuestions are already documented in the schema. The description adds no parameter-level detail such as default filtering behavior or the cost of including questions, so the 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?

The description names a specific verb and resource (lists lead generation forms), scopes it to an account, and even states what each item carries (questions and settings). It is unambiguous, though it does not explicitly differentiate itself from sibling listing tools like list_campaigns or list_saved_audiences.

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?

There is no explicit guidance on when to call this versus other list tools, and no prerequisites (e.g., that a valid accountId from list_ad_accounts is required). The second sentence, 'Helps understand what forms are available,' is a restatement of purpose rather than usable when-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety is well covered. The description adds that returned data covers names, sizes, and statuses, but does not mention pagination, rate limits, or the implications of the open-world/network dependency. Modest added value beyond annotations.

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 tight sentences, front-loaded with the verb and resource. Every clause earns its place, and no redundancy with the title or schema.

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 low-risk read-only list tool with full schema coverage and no output schema, the description covers purpose, scope, and returned fields sufficiently. The only minor gap is lack of routing guidance to sibling audience tools, which is not critical for invocation correctness.

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 three parameters (accountId, status, audienceType) are already documented in the schema. The description does not add filtering syntax, defaults, or enum semantics beyond what the schema provides, so 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 (Lists) and resource (saved/matched audiences) with clear scope ('available in the account for targeting'). Distinguishes itself from audience analytics siblings like get_audience_demographics or get_audience_reach by framing it as a discovery/list tool, though it doesn't explicitly name an alternative.

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 phrase 'to help plan campaign targeting' implies the use case (pre-campaign audience discovery), but it does not state when to use this versus get_audience_reach or get_audience_demographics, nor does it give any exclusions. Usage context is implied only.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is fully covered. The description adds behavior the annotations cannot: a hard cap of 25 results per request with an instruction to paginate, plus a summary of what the response contains (preview URLs, advertiser details, targeting info, impression stats). It does not mention auth requirements or rate limits, but the cap-and-paginate note is genuinely useful.

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?

Purpose is front-loaded in the first sentence and the practical constraint (25-result cap) is stated plainly. The second sentence ('Find and analyze real ads from any advertiser...') largely restates the first with marketing flavor, and the return-value inventory is a touch listy, but nothing is confusing or bloated.

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 14-parameter, zero-required, open-world search with no output schema, the description does solid work: it compensates for the missing output schema by naming the returned fields and warns about the pagination limit. It stops short of explaining default behaviors (e.g., the implicit recent date window) or how multiple filters combine, which would fully close the gap.

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% across 14 parameters, so the schema already documents syntax, formats, and defaults in detail. The description only enumerates filter categories (keyword, advertiser, country, date range, targeting facets, impression range), which maps to the schema but adds no meaning beyond it. 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 ('Searches the LinkedIn Ad Library for ads matching criteria') and immediately scopes it to 'real ads from any advertiser across different countries and time periods'. This is unmistakably distinct from every sibling, all of which operate on the caller's own accounts, campaigns, or creatives.

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 conveys the research context (analyze any advertiser's ads across countries/time periods), which implies when it is useful, but it never states an explicit when-to-use condition or names an alternative among the siblings. No exclusions or prerequisites are given, so the agent must infer the intended use case.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds the valuable partial-update semantic ('only specified fields are changed'), which tells the agent it won't clobber unrelated settings — a real behavioral detail beyond the annotations. It stops short of noting permissions or irreversibility of destructive changes.

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 tight sentences; the core action is front-loaded and the partial-update caveat is a useful closer. Every sentence earns its place, though it could be marginally denser.

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 15-parameter mutation tool with no output schema, the description covers the mutation and partial-update behavior adequately, but omits auth/permission requirements and what a successful response returns. Annotations carry the safety profile, but the mutation risk and side effects (e.g., targeting replacement) are only visible 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?

Schema description coverage is 100%, so the baseline is 3. The description names several updatable fields but adds no syntax or format detail beyond what the schema already documents (e.g., timestamp formats, currency pairing, enumeration values).

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 ('Updates an existing LinkedIn campaign') and enumerates the mutable fields (status, budget, name, targeting, bid). This clearly distinguishes it from sibling tools like create_campaign and delete_campaign without needing to open 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?

'Updates an existing' implies the campaign must already exist, giving implied usage context. However, it never states when to prefer this over create_campaign, delete_campaign, or update_campaign_group, and no exclusions or prerequisites are offered.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the agent knows this is a destructive, non-idempotent write. The description adds the concrete set of changeable fields, which is useful, but says nothing about permissions, reversibility, or partial-update semantics beyond what structured data covers.

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 tight sentences, front-loaded with the action and then the mutable fields, with no filler. Slightly padded by the parenthetical enum, which duplicates the schema.

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 destructive mutation tool with no output schema, the definition is adequate but thin: it doesn't clarify whether fields update independently, what a successful response looks like, or any rate/permission constraints. Annotations carry the safety profile, so the gap is moderate rather than severe.

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 seven parameters are already documented, including the ACTIVE/PAUSED/ARCHIVED/DRAFT enum and the Unix-millisecond end date. The description only restates the field list at a high level, adding no syntax or format detail beyond the schema.

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?

"Updates an existing LinkedIn campaign group" is a specific verb+resource, and it enumerates the mutable fields (status, budget, name, end date). The word "existing" implicitly separates it from create_campaign_group and delete_campaign_group, though no sibling is named explicitly.

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 says what can be changed but not when to prefer this tool over siblings like update_campaign or delete_campaign_group. No prerequisites, preconditions, or exclusions are stated, leaving usage entirely inferred.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is carried by structured fields. The description adds only the set of target statuses, and never mentions that archiving may be irreversible or what constraints apply to status transitions.

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 short sentences, front-loaded with the verb and resource, with zero filler. The allowed operations are stated immediately after the purpose.

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 three-parameter mutation tool with full schema coverage and complete annotations, the description is serviceable but omits two things an agent would want: whether ARCHIVED is recoverable and whether all status transitions are legal. No output schema exists, so return behavior is also unaddressed.

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 accountId, creativeId and the intendedStatus enum are all documented in the schema. The description echoes the status concept but adds no format or validation detail (e.g., URN vs numeric ID handling) beyond the schema.

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?

Names a specific verb (Updates) and resource (the intended status of a LinkedIn creative/ad), and enumerates the three effects: activate, pause, archive. No sibling performs creative-status changes, so differentiation is inherent, though the distinction between 'intended' and effective status is left unexplained.

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 three listed actions imply the use cases (activate/pause/archive a creative), but there is no explicit when-to-use guidance, no prerequisites (permissions, whether status changes can be reverted), and no pointer to the create_creative sibling for related work.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is partly covered. The description adds real context beyond that: supported formats (PNG/JPG/GIF) and the two-step initialize-then-upload-binary process. It omits auth/permission requirements and any warning that re-uploads are not idempotent.

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 short sentences, front-loaded with purpose, then format support, then the return value, then the mechanics. Each sentence carries distinct information with no repetition or filler.

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, the description usefully states what is returned (the image URN and its role as mediaId). Annotations cover the mutation/idempotency profile. The only gap is permission/auth context, which is only hinted at indirectly 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?

Schema description coverage is 100%, so all four parameters are already documented, including the organizationId URN options and the accountId/assetName pairing. The description adds no syntax or format detail beyond the schema, so 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?

States a specific verb and resource ('Uploads an image file to LinkedIn') and narrows the scope to ads, which separates it from read/analytics siblings like get_creative_performance. It also links the output to the downstream create-inline-ad workflow. It does not explicitly name a sibling tool, so it stops short of full 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?

The description implies usage ('for use in ads', 'used as the mediaId when creating inline ads') which gives useful context for when this tool fits. However, it states no explicit when-to-use/when-not conditions and never names an alternative or prerequisite, leaving the agent to infer the placement in the workflow.

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