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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds only that lookups are name-based and return URNs; it doesn't disclose whether results are account-scoped, what happens when no match exists, or that the facet governs the returned namespace.

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. It stays terse enough to be efficient, though it leans toward under-specification rather than crisp conciseness.

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 shape needn't be explained, and annotations cover safety. Still, for a three-parameter resolver the description omits what facets are usable, whether the query matches prefixes or exact names, and how the adAccountId scopes results — gaps an agent would want covered.

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 parameter (facet, query, adAccountId) is already fully documented including defaults and patterns. The description adds nothing beyond the schema; baseline 3 applies since the schema carries the parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb + resource: 'look up' + 'native targeting URNs', with a concrete example ('countries by name') that clarifies the name-to-URN resolution behavior. It does not differentiate from siblings (e.g., linkedin_validate_query or linkedin_get_entity, which could plausibly overlap), but the purpose itself 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?

Usage is implied rather than stated: an agent can infer this is the step for resolving human-readable targeting names before attaching them to campaigns, but the description names no alternatives, prerequisites, or when-not-to-use conditions. Given ~17 siblings with potentially overlapping lookup roles, explicit routing guidance would help.

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, openWorld. The description adds real behavioral context beyond that: the account read includes role-holding members and that role assignment governs what the connection can do on each account. It does not mention pagination or response shape, but the output schema exists to cover returns.

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, front-loaded with the core action and scope. The second sentence is slightly diagnostic but earns its place by warning about role-driven failures; nothing is wasteful.

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 rich annotations, a fully documented two-parameter schema, and an output schema, the description only needs to add purpose and behavioral nuance. It does so adequately, leaving only minor gaps around explicit alternatives.

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 both parameters are fully documented, so the baseline is 3. The description's mention of 'the members who hold a role on it' loosely maps to the includeUsers parameter but adds no syntax, default, 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?

States a specific verb (read) and resource (one LinkedIn ad account) with the scope 'in full, with the members who hold a role on it', which clearly distinguishes it from the plural linkedin_list_ad_accounts. Sibling differentiation is implied by 'one' and 'in full' rather than explicitly naming 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 second sentence gives useful diagnostic context for interpreting failures ('a read that fails on one account and works on another is usually a role, not a scope'), which implies when this tool is appropriate. However it never states explicit when-to-use conditions or names alternatives like linkedin_get_entity or linkedin_list_ad_accounts.

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 and destructiveHint=false, so safety is covered. The description adds that results carry budget, schedule and serving status and explains the LinkedIn hierarchy semantics, though it says nothing about pagination behavior beyond what the schema's pageToken field already conveys.

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, front-loaded with the action and scope; the second sentence earns its place by supplying domain context that aids tool selection, though it is the kind of background that could be trimmed for a terse agent.

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?

Annotations cover the safety profile and an output schema exists so return values need not be described; with all five parameters documented in the schema, the definition is sufficient for correct invocation, missing only explicit sibling routing.

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 name, status, pageSize, pageToken and adAccountId each documented in the schema. The description adds no parameter-level detail (e.g., how name matching or status filtering behaves), 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 (List) and resource (campaign groups) scoped to a LinkedIn ad account, and the second sentence explains the level's role (shared budget and bid strategy), which distinguishes it from the sibling linkedin_get_campaigns tool without the agent 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?

The phrase 'it is the level that explains why sibling campaigns stopped together' implies when this tool is useful (diagnosing group-level causes), but it never states explicit when-to-use conditions, prerequisites, or an alternative such as linkedin_get_campaigns for campaign-level data.

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 safety is covered. The description adds domain context about where targeting and bids live, but says nothing about pagination, the verbose includeTargeting behavior, or result 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?

Two tight sentences with the operation and scope front-loaded; the second earns its place by explaining the LinkedIn object hierarchy rather than padding.

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 an output schema, full parameter descriptions and rich annotations, the description needs only establish purpose and scope, which it does. A brief note on pagination or the includeTargeting trade-off 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 every parameter including filters, pageSize/pageToken and includeTargeting is already documented. The description adds no filter syntax or defaults beyond what the schema states, 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 (list) and resource (campaigns in a LinkedIn ad account) plus the fields surfaced. The second sentence clarifies the campaign-vs-creative hierarchy, which implicitly distinguishes it from linkedin_get_creatives, though no sibling is named outright.

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 guidance, and no named alternative among the many siblings (get_campaign_groups, get_creatives, get_insights). The hierarchy note hints at the boundary with creatives but never states it as a selection rule.

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 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.

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is settled. The description adds real domain context (user status vs. system serving status, account-to-creative scan breadth), but says nothing about scan cost, pagination, or response characteristics.

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 zero filler. The diagnostic scope is front-loaded and the LinkedIn status-model note is a compact, useful follow-on.

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 a full output schema and annotations covering safety, the remaining burden is purpose and interpretation, both addressed. Only minor gaps remain around scan breadth when campaignIds is omitted and what the scan cost looks like.

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 account IDs, campaign filtering, and the includeCreatives default are already fully documented in the schema. The phrase 'down to the creative' loosely gestures at includeCreatives but adds no syntax or format guidance. 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 diagnostic verb ('explain why') and the exact question it answers: LinkedIn ad serving state from account down to creative. That cleanly separates it from reporting siblings like linkedin_get_insights or linkedin_run_statistics_report, although 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?

Usage is implied by the framing ('is or are not serving') rather than stated as a rule. There is no explicit when-to-use vs. when-to-use-instead guidance, no mention of prerequisites, and no exclusion of the reporting tools it overlaps with.

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 and non-destructive, so the safety profile is covered. The description does add one piece of behavioral context beyond annotations — that results come with LinkedIn's limits surfaced alongside the rows — but it doesn't specify which limits, row caps, or latency, so it remains modest 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 sentences, purpose front-loaded ahead of the caveat about limits. The middle clause ('the numbers LinkedIn is bought for') is marketing filler that doesn't earn its place, but overall it is tight and well-ordered.

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 an output schema, full parameter descriptions, and annotations covering the safety profile, the description only needs to convey purpose and scope — which it does. The one residual gap is not routing the agent away from general-insights siblings, but that is minor given the richness of the surrounding structured data.

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 (breakdown enum, metrics defaults, limit, campaignIds, resolveNames) is already documented in the schema. The description only restates the breakdown dimension list, adding no syntax, default behavior, or edge cases beyond the structured fields.

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 ('break down') and resource ('LinkedIn delivery by professional demographics') and enumerates the supported dimensions, which matches the breakdown enum. An agent can tell what it returns, though it never names the closest sibling (get_insights / run_statistics_report) to differentiate the demographic axis from general reporting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by the framing ('these are the numbers LinkedIn is bought for'), which signals audience/demographic analysis, but there is no explicit when-to-use versus linkedin_get_insights or linkedin_run_statistics_report, and no stated prerequisites beyond what the schema requires.

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 the safety profile is covered. The description adds that account ownership is verified, which is a real behavioral trait, but it is duplicated in the entityId/adAccountId schema text and says nothing about failure modes when ownership fails.

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, and the operation scope arrives first. It is perhaps too compressed, since a few words on what 'verify account ownership' means in practice would cost little.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, all three required params are documented, and annotations cover the safety profile. Only the ownership-verification failure behavior is left implicit.

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%, with the enum for kind and patterns for entityId/adAccountId fully documented, so the schema carries the semantics. The description only restates the three readable resource kinds; with the schema doing the heavy lifting, 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?

Uses a specific verb ('Read one') and enumerates the exact resource kinds (campaign group, campaign, creative), which cleanly sets it apart from the plural list siblings like linkedin_get_campaigns and linkedin_get_creatives. It stops short of naming those siblings explicitly, so differentiation is inferred from the singular phrasing rather than stated.

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?

'Read one' implies the single-entity fetch case versus the list tools, and the ownership-verification clause hints at a prerequisite. But there is no explicit when-to-use/when-not guidance and no named alternative for bulk retrieval.

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, so the description is free to add the non-obvious behavior it does add: ratios like CTR, CPC and CPM are not returned by the API and are computed by this tool. That is genuinely useful and not derivable from annotations or schema. It still omits row limits, pagination and any cost/latency characteristics of an openWorld report call.

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 before the caveat about computed ratios. Every sentence carries information, though 'any granularity, and up to 20 fields' is loose phrasing that adds little precision.

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 12 parameters, 4 enums, full schema descriptions, a complete annotation set and an output schema, the remaining burden on the description is small and mostly met: purpose, pivot model and the computed-ratio behavior are covered. The main gap is sibling disambiguation, which matters given how many report-oriented tools share this namespace.

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 every parameter carries its own description, so the schema already does the heavy lifting and a 3 is the baseline. The description adds only marginal semantic value — that ratios can appear in the metric set because they are computed, and that fields include dateRange/pivotValues — and its 'up to 20 fields' claim sits awkwardly against the schema's maxItems 40.

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 (run a LinkedIn Ads report) and pins the scope with 'grouped by one pivot'. It implicitly contrasts itself with multi-pivot/report siblings ('This is the analytics finder: one pivot'), but never names linkedin_run_statistics_report or linkedin_get_demographics, so the agent still has to guess which analytics sibling to pick.

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 rather than stated: 'one pivot, any granularity' hints at the single-pivot case, but there is no explicit when-to-use or when-not-to-use rule, and no alternative is named despite several overlapping siblings. Nothing tells the agent whether to reach for this or linkedin_run_statistics_report first.

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 behavior, so the safety profile is covered. The description adds two useful behavioral facts: the returned URL is re-resolved/refreshed (suggesting a freshly signed, potentially expiring URL) and the call validates library membership. It does not say what happens on a media URN outside the account library (error vs empty result), which is the main behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no filler, and the core action leads. It is arguably over-compressed: 'Refresh' carries the whole semantic load and would benefit from one clarifying clause about when a refresh is needed.

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 two-parameter read with full schema coverage, an output schema, and rich annotations, the description supplies enough to call it correctly. The remaining gap is guidance on error/edge behavior when the media is not in the library, plus routing versus linkedin_list_media.

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 both parameters document their formats (URN pattern, numeric account ID restricted to LINKEDIN_ADS_ACCOUNT_IDS), so the schema carries the parameter burden. The description adds only the framing that the media must be associated with the selected account's library, not per-parameter detail.

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 concrete action on a concrete resource: fetch/refresh a single image or video URL and confirm it belongs to the account's media library. The singular 'one image/video' implicitly contrasts with the sibling linkedin_list_media, though neither that sibling nor any other alternative is named.

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: an agent can infer this is for a single already-known media URN rather than enumerating a library. There is no explicit 'use this when X, use linkedin_list_media when Y', and no stated preconditions beyond the implicit library-association requirement.

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 openWorldHint, so the safety profile is covered. The description legitimately adds the CRM-dependency and date-window constraints, which are real behavioral limits, but says nothing about what happens when the CRM is absent (empty result vs. error) or about pagination/result 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?

Two sentences, front-loaded with the resource and the returned metrics, followed by the two gating constraints. Nothing redundant or padded.

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 an output schema present, the return values need no explanation, and the description covers purpose plus both gating conditions. It is essentially complete, only missing failure-mode behavior for accounts without a connected CRM.

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% and every parameter is documented in-schema, including the 30–366 day window and pivot defaults. The description only restates the window constraint already present in startDate's description, adding no new semantics.

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 ('Read the LinkedIn Revenue Attribution Report') plus exactly what it returns: pipeline and closed won revenue from the CRM attributed to LinkedIn advertising. That is enough to distinguish it from the statistics/insights siblings, though it never names an alternative 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?

Gives hard eligibility conditions: the Business Manager must have a CRM connected, and the reporting window must be 30–366 days. These are actionable prerequisites, but there is no routing advice (e.g., 'use linkedin_run_statistics_report for non-CRM metrics'), so the agent must infer when this beats its siblings.

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, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds the non-obvious fact that this is a prerequisite read for write preparation, which is genuine context beyond the annotations. It does not need to explain returns since an output schema exists.

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. It is terse to the point of being slightly clipped ('Read account, supported formats...'), but every clause 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?

With an output schema, full parameter documentation, and rich annotations, the description only needs to state purpose and timing. It does both, leaving little an agent needs that isn't already structured.

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?

One parameter with 100% schema description coverage, including the LINKEDIN_ADS_ACCOUNT_IDS constraint, so the schema does the work. The description adds nothing about adAccountId semantics; 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 verb 'Read' is paired with three concrete resources: account, supported formats, and native LinkedIn write requirements. It is distinguishable from siblings like linkedin_get_account_details because it returns setup/format guidance rather than raw account data, though the description never states that distinction 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?

'before preparing changes' implies the trigger condition (use prior to authoring mutations), which is real usage context. But no alternatives are named and no exclusion is given, so the agent must infer whether this replaces or supplements linkedin_get_account_details.

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/idempotent/destructive/openWorld, so the description earns credit for what it adds: it explicitly probes the reporting endpoint and exposes the API version header, and guarantees the token itself is never returned — a security-relevant detail not present in the structured fields.

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 dense sentence that front-loads the read-only framing and then lists the checks. Nothing is wasted, though the trailing clause about the token makes it slightly long for what is essentially a four-item checklist.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description is complete for a zero-required-parameter diagnostic tool; the only real gap is routing guidance versus sibling validation/diagnostic tools.

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 the single adAccountId parameter is fully documented in the schema, including its default behavior. The description alludes to 'configured ad accounts it can reach' but adds no new semantics about the parameter, 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 and resource ('Read-only LinkedIn Ads health check') and enumerates exactly what it verifies: token validity, reachable ad accounts, reporting endpoint, API version header. That clearly separates it from the data-fetching siblings like linkedin_get_insights or linkedin_list_ad_accounts, though it never explicitly names those alternatives.

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 diagnostic framing implies you call this to validate credentials/configuration before running real queries, but the description never says when to prefer it over, say, linkedin_validate_query or linkedin_list_ad_accounts, nor any exclusion criteria. Usage is inferable 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 readOnly, idempotent, non-destructive behavior, so the bar is lower; the description still adds real value by disclosing the hard scoping rule (only accounts in the LINKEDIN_ADS_ACCOUNT_IDS config are ever returned) and the default exclusion of test accounts. It does not discuss pagination or result caps for accounts outside the allowlist, leaving only a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, and the description covers scope, defaults and exclusions for a zero-required-parameter read tool. The only thing an agent might still want is whether the allowlist is enforced as an error or a silent filter when adAccountIds includes unconfigured IDs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each of the three parameters is already documented, establishing a baseline of 3. The description reinforces the adAccountIds default ("every configured account") and the includeTestAccounts default, but adds no filtering semantics for the status array beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds one genuine behavioral fact — that delivery metrics are excluded — but says nothing about pagination behavior, coverage fields, or the adIds resolution path beyond what the schema states.

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 primary action and resource, followed by output-shape and scope notes. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description plus schema together cover the key facts an agent needs. The only gaps are competitive positioning against sibling media tools and the adIds-vs-paging interaction.

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 adAccountId, adIds, limit and pageToken in detail. The description adds no parameter-level meaning (e.g., that adIds bypasses paging, or that limit counts ads scanned rather than creatives returned), 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 and resource ("List the images and playable videos used by the ads of an account") and adds a useful qualifier ("with the actual ad names"). It does not explicitly distinguish itself from near siblings like linkedin_list_media or linkedin_get_creatives, so an agent still has to infer which media-listing tool to pick.

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?

"Does not report delivery" is a real exclusion that implicitly routes delivery questions to linkedin_get_delivery_status, but the guidance is purely negative. There is no positive statement of when to choose this over linkedin_list_media or linkedin_get_creatives.

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, and open-world, so safety is covered. The description adds that library items come with download URLs and processing status, which hints at the read payload, but says nothing about rate limits, library scoping, or pagination behavior beyond what the schema states.

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 compact sentence with the resource front-loaded and the exclusion clause at the end. Dense but every clause carries information; nothing is 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?

With full schema coverage, annotations, and an output schema, the description only needs to convey scope and exclusions, which it does. A brief note on single-asset retrieval versus linkedin_get_media 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 kind, limit, start, and adAccountId are all documented with enums, defaults, and bounds in the schema itself. The description adds no parameter-level detail (e.g., how kind interacts with returned URL types), so this sits at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list account image/video library files) plus the payload it returns (download URLs, native processing status). The 'not ad performance' clause separates it from the insights/report siblings, though it doesn't distinguish it from the close sibling linkedin_get_media or linkedin_list_ad_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 'not ad performance' phrase gives a when-not signal, implying use this for asset retrieval rather than metrics. There is no explicit when-to-use statement and no named alternative for fetching a single asset, so the agent must infer the boundary with linkedin_get_media.

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 safety is covered. The description adds only the three-pivot ceiling, which the schema also states, and says nothing about the outbound API call behavior, payload size, or latency that would matter for a wide report.

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, capability stated first and the differentiator second. Nothing redundant or padded; every clause 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?

The tool is read-only, has an output schema, and has fully described parameters, so the burden is light. However, for an 11-parameter reporting tool the description never mentions the required trio (adAccountId, pivots, startDate) or the default behavior for metrics and time granularity, leaving the agent to open 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 coverage is 100%, so the baseline is 3, but the description earns extra credit by naming concrete pivot values ('campaign', 'device', 'campaign group', 'serving location'). That is genuinely useful since 'pivots' is an unconstrained string array with no enum in 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: run a LinkedIn Ads report grouped by up to three pivots. The 'only way to cross campaign with device, or campaign group with serving location' phrasing functionally differentiates it from linkedin_get_insights and the other getters, 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?

It implies when to reach for it (multi-pivot cross-tabulation) but never states when not to, nor names linkedin_get_insights or another sibling as the simpler alternative for single-dimension pulls. Usage is inferable rather than directed.

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?

Discloses non-obvious behavior: no network call is made, and validation surfaces both accepted and dropped fields plus the twenty-field ceiling. Annotations already cover the read-only/idempotent safety profile, so this adds real context; there is mild tension with openWorldHint=true, though that plausibly reflects the rule catalog rather than a live request.

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: purpose and cost-saving rationale first, return shape second. No filler and nothing 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?

With an output schema, full param coverage and annotations, the description covers the essentials. The only omission is what a validation failure looks like versus a successful-but-truncated result, which matters for a pre-flight check.

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 pivots, metrics, dates and granularity are already documented with defaults and formats. The description only references the 'pivot and metric combination' and adds no syntax or constraint detail beyond the schema (e.g. the 1-3 pivot / 40 metric caps).

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+resource (validate a pivot/metric combination against LinkedIn reporting rules) and frames its role relative to actually spending an API call. An agent can distinguish this dry-run validator from linkedin_run_statistics_report 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?

'before spending a call on it' gives a clear trigger condition for when to use this instead of the real reporting tool. It stops short of explicitly naming linkedin_run_statistics_report or stating when validation is unnecessary, so it is clear context rather than full when/when-not guidance.

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