LeanrIQ

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, but the description adds real value beyond them: mutation modes (validate_only, preview_only, execute), the partial-failure policy (completed_items_not_rolled_back), synchronous execution, and the deterministic retry-key derivation. The seat-authorisation requirement for writes is genuinely useful operational context. It stops short of 5 because much of the remaining text is generic output-formatting boilerplate rather than tool behavior.

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

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

It opens with the classification facts, which is well front-loaded, but is then padded with a long block of generic presentation instructions ('use assistantSummary first', 'never display raw JSON') that applies to every tool rather than this one. That boilerplate crowds out the tool-specific information an agent actually needs.

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 does cover the safety/precondition profile for a destructive mutation. However, for a 24-parameter nested-schema write with 0% parameter documentation and no optimistic-concurrency guidance for expectedVersion, it is not complete enough to invoke confidently without guesswork.

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 24 parameters, so the description carries the full explanatory burden, yet it only addresses idempotencyKey and seatId/seatName. The two required parameters (accountId, advertiserId) are unexplained, and expectedVersion, dryRun, and the many locale/market parameters have no semantics at all; notably the relationship between dryRun and the advertised mutation modes is never stated.

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 restates the title ('archive advertiser') and adds classification metadata ('writes to Studio, destructive'), which tells the agent this is a destructive write, but it never explains what archiving an advertiser actually does (hard delete, soft hide, cascade to campaigns/creatives) or how it differs from update_advertiser or delete_flight. The verb+resource is identifiable, so it is not pure tautology, but the semantics are left implicit.

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 relative to the many sibling mutation tools (update_advertiser, archive_campaign, archive_creative). The only selection-relevant content is a precondition ('when more than one seat is authorised, seatId or seatName must be supplied') and the idempotency-key default, which are prerequisites rather than routing 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?

Beyond the annotations (destructive, idempotent, closed-world, not read-only), the description discloses synchronous execution, that task support is forbidden, the partial-failure policy 'completed_items_not_rolled_back', and the deterministic idempotency-key derivation on omitted idempotencyKey. The seat-selection requirement for writes is an auth/eligibility constraint that annotations do not capture.

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 purpose is front-loaded, but the body is a dense run-on of server-wide boilerplate about JSON presentation, assistantSummary usage, and next-action suggestions that is not specific to archiving a campaign. Every sentence is grammatical and information-bearing, yet a large share belongs in shared agent instructions rather than a tool definition.

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 plus the text cover safety and idempotency well. The gap is on the input side: 24 undocumented parameters with 0% schema coverage, and no statement of what archiving actually does to the campaign (halts delivery? becomes read-only?), leaves an agent under-informed for a destructive write.

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 24 parameters, so the description must carry the burden and it largely does not. It explains only seatId/seatName (write-time seat requirement) and idempotencyKey (retry-key derivation); accountId, campaignId, dryRun, expectedVersion, approvalId, flightId, and all locale/market fields remain unexplained.

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

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

The opening 'archive campaign' is essentially a restatement of the name and title, so the agent learns nothing new from it. The classification line ('writes to Studio, destructive') does clarify the operation class, but nothing distinguishes this from siblings such as archive_advertiser, archive_creative, delete_flight, or update_campaign used to pause delivery.

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 lists mutation modes (validate_only, preview_only, execute) and states that seatId/seatName must be supplied on a write when multiple seats are authorised, which are useful call-time conditions. However, it never says when to archive rather than delete, pause via update_campaign, or leave a campaign running, and gives no prerequisites for approvalId or expectedVersion.

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 destructive=true, readOnly=false, idempotent=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: synchronous execution, task support forbidden, mutation modes, and especially the partial-failure policy (completed_items_not_rolled_back) and idempotency-key derivation. The multi-seat requirement for writes is also valuable, though some of this is generic boilerplate applied across tools.

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 classification block is front-loaded effectively, but a large fraction of the text (assistantSummary usage, never display raw JSON, mention IDs only when useful, prefer concise language) is generic response-formatting boilerplate that is not specific to this tool and inflates length.

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 the description covers the operation's behavior reasonably. However, for a destructive 24-parameter mutation with 0% param coverage and close siblings, it leaves the invocation parameters and resource-distinction gaps unfilled.

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 24 parameters, so the description bears the full burden and does not meet it. Only idempotencyKey and seatId/seatName receive semantic explanation; accountId, creativeId, dryRun, expectedVersion, and the large set of locale/market parameters are undocumented in both schema and description.

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

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

The opening 'archive creative' restates the name almost verbatim and never differentiates from the near-identical siblings archive_advertiser and archive_campaign beyond the resource noun. 'Classification: writes to Studio, destructive' adds some substance about the operation type, but the core purpose (what archiving removes or hides, reversibility) is left unstated.

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 comparison against archive/delete/restore alternatives. It does provide invocation context via the mutation modes (validate_only, preview_only, execute) and the seat requirement, which is more than nothing but falls short of real routing 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?

Substantially exceeds the annotations: it discloses billable AI usage, durable execution, the validate_only/preview_only/execute mutation modes, a completed_items_not_rolled_back partial-failure policy, and two operational constraints not in the schema (automatic deterministic idempotencyKey derivation on mutation replay, and the requirement that seatId/seatName be passed on the exact write call when multiple seats are authorised). It also states the agent-facing response contract (use assistantSummary, don't dump raw JSON), which the annotations do not carry.

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 and routing are correctly front-loaded, which is good. But the text is padded with generic cross-tool boilerplate about assistantSummary, never displaying raw JSON, mentioning IDs only when useful, and concise human language, plus a duplicated title block and a stray double period; those sentences do not earn their place for this specific tool.

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 an extremely complex 40-parameter mutation with an output schema (so return values need no explanation), the description covers the essential behaviors: build path resolution, save-by-default vs preview, seat requirement, idempotency, billable usage, and failure semantics. The remaining shortfall is per-parameter meaning, which is a schema-coverage problem rather than a missing behavioral explanation.

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 only 3% across 40 parameters, so the description must carry the burden. It does explain the semantically critical ones (objective, requestedFormats, outputs with static JPEG/PNG requiring Studio persistence, persistence default vs preview_only, campaignId/campaignName, seatId/seatName, idempotencyKey), but dozens of parameters (brief, input, assets, prompt, template, marketContext, locale fields, skipTraffickedRebuild, etc.) get no clarification, leaving most of the surface undocumented.

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

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

The opening sentence gives a specific verb+resource+scope: 'Create AI Display CreativeDocuments from objective and requestedFormats without pre-existing creatives.' It also routes away for existing versions ('Export existing versions with export_creative'). However, with siblings like leanriq_build_ad, build_dooh, build_videoad and build_campaign_creative_set in the same family, it never explicitly says which build path this is versus those, so sibling differentiation is only partial.

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 concrete selection conditions: campaignId/campaignName triggers full persisted-campaign resolution and the Studio Gold build path, campaign-scoped calls save by default, and persistence preview_only is reserved for unsaved ad-hoc previews. It also names export_creative as the alternative for existing versions. What is missing is guidance on when to choose this over the near-identically-named leanriq_build_ad or the other build_* tools.

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 mutation/idempotency safety profile, and the description adds substantially beyond them: billable AI usage, synchronous execution, mutation modes (validate_only, preview_only, execute), and a partial-failure policy (completed_items_not_rolled_back). It also explains the deterministic idempotency-key derivation, giving concrete retry semantics rather than just repeating idempotentHint.

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 and routing are correctly front-loaded, but the body is a dense metadata dump followed by response-formatting instructions ("Never display raw JSON...") that read like a system prompt rather than tool-selection guidance. Some of that content earns its place, but the overall block is longer than the invocation task requires.

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?

Behavioral context is strong and an output schema exists (so return values need no explanation), but for a 40-parameter create tool with zero schema description coverage the description leaves required-input semantics and input formatting essentially undocumented. Adequate on behavior, incomplete on inputs.

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 40 parameters, so the description is the only source of parameter meaning — but it explains only idempotencyKey. Nothing is said about the five required fields (campaignName, objective, audience, KPI, funnelStage) or the many nested/optional structures, so the gap is largely unmitigated.

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 ("Plan and create an initial Studio creative set") plus a clear scope condition ("for a campaign that has no saved creatives"), and explicitly names the sibling to use instead (build_ad) for the rebuild case. An agent can separate this from build_ad/build_dooh without opening a 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?

Gives both the when-to-use condition (a campaign with no saved creatives) and an explicit when-not-to-use with the named alternative ("Do not use this tool to rebuild existing creatives; use build_ad with campaignId or campaignName"). Routing is unambiguous.

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?

Beyond the annotations, it discloses billable AI usage, durable execution, mutation modes (validate_only/preview_only/execute), and a partial-failure policy that completed items are not rolled back. It also clarifies idempotency-key derivation and the requirement that seatId/seatName be supplied on this exact call for writes when multiple seats are authorised. This is rich behavioral context that annotations alone (readOnly/destructive/idempotent hints) do not convey.

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 opening sentences are well front-loaded and dense with useful constraints, but the block is padded with generic orchestration guidance (assistantSummary usage, 'never display raw JSON', 'prefer concise human language') that is not specific to selecting or invoking this tool. Several sentences do not earn their place in a tool definition.

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 described, and the safety/idempotency profile is covered. However, for a 35-parameter, zero-required, deeply nested mutation with 0% schema coverage, the description only addresses a handful of parameters; an agent still lacks guidance on the core payload (copy, assets, format, doohContext). Adequate but with clear 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 0% across 35 nested parameters, so the description must carry the load. It meaningfully explains saveToStudio (false = unsaved preview), seatId/seatName (required on the write when multiple seats exist), and idempotencyKey fallback behavior, but the large majority of parameters (copy, assets, format, doohContext, locales, designEvidenceContext, etc.) are left undocumented. It compensates for a few high-impact parameters but not the breadth of 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?

The description states a specific verb and resource (build a DOOH-native poster from an existing Studio creative) plus its two key behaviors: comparing native renders and saving the editable working version by default. It explicitly differentiates itself from the sibling build_ad ('does not route through Display build_ad') and rules out CTA buttons, so an agent can place it against build_ad/build_videoad without opening the schema.

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

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

It gives clear operating conditions: default saves, explicit saveToStudio=false yields an unsaved preview, and below-threshold review retains a technically valid non-released version. It also names the medium it is not (Display build_ad). It stops short of stating when to choose DOOH over the other build_* siblings for a given 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false), the description discloses several traits the annotations do not: it creates billable AI usage, execution is durable, mutation modes, the partial-failure policy (completed_items_not_rolled_back), deterministic idempotency-key derivation, and the seat-provision requirement on mutations. These are meaningful additions, though the 'never claims an MP4 master before Studio certifies' statement is somewhat promotional.

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 purpose is front-loaded, but the opening sentence is copied verbatim from the title (including a duplicated period) and several trailing sentences are generic orchestration boilerplate about assistantSummary and not displaying raw JSON that are not specific to this tool. The mutation/seat notes do earn their place; the response-format boilerplate does not.

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 high-complexity mutation tool with an output schema present, the description covers lifecycle and safety behaviors (modes, partial failure, idempotency, seat requirement) reasonably well. It does not help an agent choose this tool over its video-adjacent siblings, and it leaves 43 of 45 parameters unexplained, which is a notable gap given the schema's richness.

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

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

With 45 parameters at 0% schema description coverage, the description must carry the burden, and it explains only a few: seatId/seatName, idempotencyKey, and the channel distinction (pre-roll vs CTV). The vast majority of parameters (sourceShotMaps, lockedSourceChoices, designEvidenceContext, copyPolicy, etc.) get no semantic explanation anywhere.

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 name and opening sentence give a specific verb+resource ('Create an advertiser-aware pre-roll or CTV video composition'), which cleanly separates it from build_dooh and the generic build_ad sibling. It lacks an explicit 'unlike build_ad, this one is video-only' statement, so sibling differentiation is inferred 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?

There is no explicit when-to-use / when-not-to-use guidance relative to build_ad, leanriq_build_ad, or build_campaign_creative_set. It does state mutation modes (validate_only, preview_only, execute) and a prerequisite that seatId/seatName must be supplied on write calls with multiple authorised seats, which is partial usage 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?

The description explicitly states 'Classification: read-only' while the annotations declare readOnlyHint=false, and the same text describes mutation modes (validate_only, preview_only, execute) and write-oriented seat requirements. This directly contradicts the structured annotation and would mislead an agent about whether the call mutates state.

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 purpose is front-loaded, but roughly half the text is generic orchestration/UX boilerplate (use assistantSummary first, never display raw JSON, suggest the next best action) that belongs in a system prompt rather than a tool definition, and it duplicates the title verbatim with a double period. The tool-specific signal is buried in 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?

An output schema exists so return values need not be explained, and the description does cover mutation modes, partial-failure policy, and idempotency. But for a 16-parameter tool with 0% schema coverage and deeply nested approved-context objects, it omits any explanation of prerequisites, identity configuration requirements, or input structure, and its 'read-only' claim conflicts with the actual write behavior.

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 16 parameters, including large nested objects (advertiserContext with dozens of fields, marketContext, campaignContext), so the description carries the full burden — yet it only adds meaning for seatId/seatName and a node named idempotencyKey that is not even in the schema. The remaining parameters, including the entire advertiserContext payload, are left undocumented.

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 — building a versioned advertiser research graph from configured identity and approved context — which is far more than a name restatement. It does not, however, differentiate itself from the many sibling research tools (get_world_research_profile, leanriq_build_world_research_profile, get_world_research_summary), so an agent gets the 'what' but not a decisive 'this one vs that one'.

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 provides real prerequisites for invoking the tool — the seatId/seatName requirement on the exact mutation call when more than one seat is authorized, and idempotencyKey derivation on omission — plus the available mutation modes. But it never says when to choose this tool over the adjacent get_world_research_* or build siblings, so the routing guidance is implied 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?

The description asserts "Classification: read-only" while the annotations declare readOnlyHint=false, a direct contradiction that could lead an agent to treat a mutating cancel as a safe read. Although useful details follow (completed_items_not_rolled_back partial-failure policy, deterministic idempotencyKey derivation), they sit alongside mutation-mode boilerplate that further muddies whether this call changes state.

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?

Only the first two words address the tool itself; the rest is a generic response-formatting policy (assistantSummary, never display raw JSON, mention IDs sparingly) plus an execution/metadata preamble that would be identical across the suite. It is front-loaded on paper but wastes most of its length on harness boilerplate rather than selection-relevant 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?

An output schema exists, so return values need no explanation, but the description still omits everything an agent needs about the operation itself: what a cancelled task becomes, whether cancellation is reversible, what task states permit it, and how it differs from its sibling retry_task. For a mutation with 18 parameters at 0% schema coverage, this is a significant shortfall.

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 18 parameters, so the description must carry the load. It adds real semantics for only three: idempotencyKey derivation on omission, and the seatId/seatName requirement on mutations when multiple seats are authorised. The other 15 parameters — reason, accountId, locales, marketContext, languageVariantGroupId, and so on — are neither explained nor mapped to the cancel operation.

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 opens with "cancel task." — a verbatim restatement of the tool name and title — and never explains what cancelling actually does (abort a running job vs. mark it cancelled vs. discard queued work). The remaining text is harness metadata (classification, execution, mutation modes) rather than a statement of purpose, and it does not distinguish this from siblings such as retry_task, delete_flight, or archive_campaign.

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 cancel a task versus retrying it (retry_task), listing it (get_task/list_tasks), or leaving it alone; no prerequisites such as required task state are stated. The only conditional instruction is parameter-level ("when more than one seat is authorised, seatId or seatName must be supplied"), which is not tool-selection 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 write/idempotent/non-destructive, but the description adds substantive behavioral context beyond them: synchronous execution, task support forbidden, the three mutation modes, and the partial-failure policy 'completed_items_not_rolled_back'. The idempotency-key derivation rule and the requirement that seatId/seatName be passed on the exact write call are genuinely useful operational disclosures.

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

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

It is front-loaded with the tool name and structured as labeled fields, which helps scanning. However, the bulk of the text is generic response-formatting boilerplate (assistantSummary, never display raw JSON, suggest next LeanrIQ action) that is not specific to cloning and displaces tool-relevant 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?

An output schema exists, so return-value explanation is not required, and the operational concerns (idempotency, seat, partial failure) are well covered. But for a 20-parameter, nested-object mutation the description never conveys the business semantics of the localization/market inputs, leaving the agent under-informed about how to construct the 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 0% across 20 parameters, so the description carries the full burden and largely fails: it explains only idempotencyKey and the seatId/seatName write requirement. Business parameters such as targetMarket, contentLocale, expectedVersion, marketContext, and languageVariantGroupId are undocumented in both schema and description.

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 first sentence, "clone creative," is a verbatim restatement of the name and title and is the only statement of purpose. The only added substance is metadata ('writes to Studio', 'synchronous'), which classifies the operation but never explains what cloning produces (a copy? a variant?). No sibling is named for differentiation (e.g., create_creative_version, revise_creative), so it lands at tautology.

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 statement of when to use this tool versus alternatives like create_creative_version or revise_creative, and no prerequisites or exclusions. The mutation-modes line (validate_only/preview_only/execute) hints at run modes but is not framed as usage guidance. No guidance is present.

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?

Strong behavioral disclosure: synchronous execution, mutation modes (validate_only, preview_only, execute), partial-failure policy 'completed_items_not_rolled_back', idempotency-key derivation, and the seatId/seatName requirement on multi-seat writes. These go well beyond the annotations, which only declare readOnly=false, idempotent=true, destructive=false. The main gap is that it doesn't say which permissions or account scoping are required, and 'Studio' is undefined.

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?

Behavioral facts are front-loaded (classification, execution, mutation modes, failure policy), which is good. But the response-formatting guidance about assistantSummary, raw JSON, IDs, and next-best-action is UI/prompt boilerplate rather than tool definition, and it dilutes the operative content across several 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?

Output schema exists, so return values need not be described, and the annotation safety profile is supplemented. However, a 20-parameter create tool with 0% schema coverage still lacks documentation for the advertiser object, accountId, expectedVersion, and the relationship between dryRun and the mutation modes. The description is operationally helpful but not complete enough to call blind.

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 0% and there are 20 parameters, so the description should compensate more. It does explain idempotencyKey (auto-derivation) and the seatId/seatName requirement, which are the two most consequential params. But the advertiser object fields (name, domain, websiteUrl, status, metadata), accountId, expectedVersion, market/locale params, and dryRun vs the three mutation modes are left entirely to the bare 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?

The description opens with 'create advertiser', which restates the name/title without adding a specific verb+resource framing beyond the schema's 'advertiser' object with name, domain, status. It doesn't distinguish from sibling resolvers like leanriq_resolve_or_provision_advertiser or create_campaign. The classification 'writes to Studio' adds some scope but not purpose specificity.

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 use this vs alternatives such as leanriq_resolve_or_provision_advertiser (which provisions) or get_advertiser. The only usage-like statement is a seat-supply rule for multi-seat writes, which is a prerequisite, not a when-to-use decision. An agent has no routing signal among the 100+ 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?

Goes well past the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false). It discloses the partial-failure policy (completed_items_not_rolled_back), the three mutation modes, deterministic retry-key derivation, and the multi-seat authorisation precondition  exactly the kind of write-time behavior an agent cannot get from 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?

Front-loaded and the field-mapping sentence is the most valuable part, but the block is long and repeats the title verbatim at the start. A large share of the text is response-formatting policy (assistantSummary, never display raw JSON) that is orchestration guidance rather than tool-invocation guidance, diluting the signal.

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 are adequately covered elsewhere, and the annotations plus description cover the safety/idempotency profile well. The gap is on the input side: for a 20-parameter, deeply nested write with 0% schema description coverage, the description accounts for roughly a third of the parameters and says nothing about optional locale/market-context plumbing or versioning.

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 20 parameters, so the description must carry the load. It does map natural-language phrasing to concrete fields (calledcampaignName, funnel/awareness termsfunnelStage, impression goalstargetImpressions, KPI labelsprimaryKpi/secondaryKpi) and explains idempotencyKey and seatId/seatName, but leaves many top-level parameters such as accountId, approvalId, expectedVersion, marketContext, and the locale fields entirely undocumented.

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 (Create a Studio campaign) and adds that all campaign fields must be nested inside the `campaign` object, which is a real structural instruction. It does not differentiate from close siblings such as `launch_creative_campaign`, `leanr_build_campaign_creative_set`, or `leanriq_campaign_builder`, so an agent must still infer which creation path applies.

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?

Provides genuine operational context: mutation modes (validate_only, preview_only, execute), the requirement that seatId/seatName be passed on the exact write call when multiple seats are authorised, and the fact that idempotencyKey is auto-derived on omission. However, it never says when to prefer this tool over the campaign-building siblings, which is the main routing decision an agent faces here.

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?

Beyond the annotations it discloses classification (writes to Studio, creates billable AI usage), synchronous execution, forbidden task support, mutation modes, a partial-failure policy, idempotency-key derivation, and the seat authorization requirement. This is rich disclosure the annotations alone do not provide, and it is consistent with readOnlyHint=false and destructiveHint=false.

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, but the text duplicates the title nearly verbatim in sentence one (with a dangling '..'), and much of the body is generic orchestration/response-formatting boilerplate that is tangential to tool selection. Signal is present but 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?

An output schema exists so return values need not be explained, and the mutation/safety behavior is well covered. However, given 40 parameters at 3% schema coverage, the description is not complete enough to tell an agent how to populate the many input fields.

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 only 3% across 40 parameters, so the description must carry the load. It adds genuine meaning for a few (idempotencyKey derivation, seatId/seatName authorization, saveToStudio behavior) but leaves the overwhelming majority of parameters undocumented in both the schema and the text.

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

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

The opening sentence gives a specific verb+resource ('Generate Studio-ready design briefs') plus the driving inputs (campaign context, brand rules, audience, offer, format constraints). This clearly distinguishes it from read/build siblings like build_ad or create_production_plan, though it never names an alternative tool to route against.

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 describes the save-vs-proposal branch when creative IDs and saveToStudio are supplied, which is a usable condition. But it offers no explicit when-to-use/not-use guidance relative to close siblings (leanriq_create_brief, create_production_plan, create_creative_intelligence_plan), leaving selection 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?

The description adds substantial behavioral context beyond annotations: mutation modes (validate_only, preview_only, execute), partial failure policy (completed_items_not_rolled_back), idempotency key derivation, and the seatId/seatName requirement for writes when multiple seats are authorised. This is rich disclosure, though the awkward 'Classification: read-only' text conflicts with the write-oriented mutation modes listed.

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 description is bloated with boilerplate orchestration instructions (assistantSummary guidance, 'never display raw JSON', tone directives) that crowd out the actual tool-specific information. The most important facts – what the tool does and its mutation modes – are buried after a long metadata preamble.

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?

It covers the mutation lifecycle and idempotency/seat requirements, and an output schema exists so return values need not be explained. But with 16 parameters at 0% schema coverage, the description leaves most input semantics undocumented, falling short for a tool of this 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 0% with 16 parameters, so the description must compensate. It covers the seatId/seatName requirement and idempotencyKey behavior, which is valuable. But it doesn't explain advertiserId, opportunityId, targetMarket(s), locale fields, or the language variant parameters at all, leaving most of the 16 params undocumented.

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: 'Create a concise proposed campaign plan from one grounded opportunity.' The title adds the key caveat that studio approval is required before campaign creation, which distinguishes this from launch_creative_campaign or create_campaign. It is clear, though it doesn't explicitly name those siblings.

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 ('from one grounded opportunity') and the title notes studio approval is required before actual campaign creation, hinting at the validate/preview/execute mutation modes. However, it never explicitly states when to choose this over run_creative_intelligence, select_world_opportunity_for_campaign, or create_campaign. No explicit when-not or alternative 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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds substantial behavioral context: synchronous execution, task support forbidden, the completed_items_not_rolled_back partial-failure policy for multi-item writes, and the deterministic retry-key derivation when idempotencyKey is omitted. The seat-binding rule (a remembered seat is insufficient for a write) is exactly the kind of precondition an agent must know before calling.

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 opening is front-loaded with the useful mutation facts, but a large block is generic response-formatting boilerplate ("Use assistantSummary first... Never display raw JSON... suggest the next best LeanrIQ action") that applies to every tool and dilutes this one. The redundant "create creative version." lead-in also costs a sentence.

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, return values need no explanation, and the description covers the mutation contract, idempotency, and seat requirement well. However, for a 23-parameter nested write with 0% schema description coverage, the near-total silence on parameter meaning leaves the definition incomplete for correct invocation.

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 23 parameters, so the description carries the full burden — and it only explains idempotencyKey and seatId/seatName semantics. Nothing is said about creative, approvalId, expectedVersion, dryRun, or the many locale/market parameters, leaving most inputs undocumented.

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?

"create creative version" essentially restates the tool name and title, though "Classification: writes to Studio" adds that it is a write in the Studio domain. It does not distinguish this from near siblings such as clone_creative, revise_creative, or restore_creative_version, so an agent gets no help disambiguating the version-creation family.

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 discloses the valid mutation modes (validate_only, preview_only, execute) and a real precondition: when multiple seats are authorised, seatId/seatName must be supplied on the exact call. That is useful operational guidance, but there is no statement of when to reach for this tool over clone_creative / revise_creative, and no explicit 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?

Beyond the annotations, the description discloses the partial failure policy (completed_items_not_rolled_back), durable execution, mutation modes, and the deterministic idempotency-key derivation. These are genuine behavioral traits the annotations do not carry, though permission/authorization specifics remain thin.

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 description is a dense metadata block that front-loads a tautology before reaching substantive content. The response-formatting and orchestration instructions are verbose, though they are structured and arguably useful; several sentences could be trimmed without loss.

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 reasonably covers idempotency, seat authorization, and mutation modes. But for a 26-parameter tool with zero schema coverage, the absence of any parameter-level explanation makes it incomplete for correct invocation.

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 26 parameters, so the description bears full responsibility. It adds meaning for only seatId/seatName and idempotencyKey, leaving name, platform, flightId, marketContext, creativeConfigs, and the rest entirely undocumented. This is far short of compensating for the coverage gap.

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

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

The opening line "create flight" is a tautology that merely restates the tool name, and the term "flight" is never defined. "Classification: writes to Studio" adds a small amount of resource context but does not specify scope, required inputs, or how this differs from siblings like create_campaign or validate_flight. An agent cannot tell from this text what a flight actually is.

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 mutation modes (validate_only, preview_only, execute) and the seat prerequisite ("seatId or seatName must be supplied on that exact tool call when more than one seat is authorised") give implied invocation guidance. However, there is no explicit when-to-use guidance versus alternatives such as validate_flight or update_flight, leaving the choice 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?

Beyond the annotations, the description discloses that this is billable AI usage, that execution is synchronous, that task support is forbidden, the mutation modes (validate_only, preview_only, execute), the partial failure policy (completed_items_not_rolled_back), and the deterministic idempotency-key derivation on retry. These are exactly the operational traits an agent needs and they are not derivable from the 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?

The sentence is front-loaded with the tool name, but a large share of the text is generic output-style boilerplate ('Never display raw JSON,' 'Mention IDs only when useful,' 'Prefer concise human language') that applies to every tool rather than this one. It is structured but padded with non-specific guidance.

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 highly complex tool (29 parameters, nested objects, required brand/campaignName/format/brief), the description explains operational behavior but leaves the entire parameter surface undocumented, which is insufficient for correct invocation. The output schema does relieve it of explaining return values, but the parameter gap dominates.

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 29 parameters (brand, brief, format, template, marketContext, etc.), so the description must carry parameter meaning, and it does not. The only parameter-like reference is 'idempotencyKey,' which is not even present in the input schema. No field-level semantics are added anywhere.

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 opens with 'create production plan,' which simply restates the tool name and title verbatim. It never explains what a production plan is, what it produces, or how it differs from siblings like create_creative_brief or create_creative_intelligence_plan. This is tautological restatement rather than a purpose statement.

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 guidance, no prerequisites, and no alternatives named. The description notes execution mechanics (synchronous, task support forbidden) and mutation modes, but never tells the agent when this tool is the right choice versus the many sibling 'create_*' / 'build_*' tools.

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=true, but the description adds real value: durable execution, the partial failure policy 'completed_items_not_rolled_back', the deterministic retry-key derivation when idempotencyKey is omitted, and the multi-seat authorisation requirement. It still does not say what else is destroyed along with the flight.

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 is dominated by generic response-formatting boilerplate ('Never display raw JSON', 'Use assistantSummary first') that applies to every tool and does not help select or invoke this one. The tool-specific content is buried among orchestration instructions rather than 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?

An output schema exists so return values need not be described, but for a 24-parameter destructive mutation at 0% schema coverage the description is incomplete about most inputs. It covers seat authorisation and idempotency but leaves the rest of the parameter surface undocumented.

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 24 parameters, so the description must carry the burden, yet it only touches seatId/seatName and idempotencyKey. The required accountId and flightId, plus 19 other fields (dryRun, expectedVersion, campaignId, etc.), get no explanation anywhere. It only marginally compensates for the coverage gap.

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 first sentence, 'delete flight', is essentially the tool name restated, so the core purpose is only tautologically stated. It adds the classification 'writes to Studio, destructive', which signals scope, but it never explains what a flight is or what deleting one entails (dependent creatives/ads). No sibling differentiation from update_flight, validate_flight, or retraffick_flight.

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 lists mutation modes (validate_only, preview_only, execute) and a concrete rule that seatId/seatName must be supplied on the exact write call when multiple seats are authorised, which is genuine usage guidance. However it never states when to use this tool versus sibling flight tools, nor any preconditions for deletion.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false), the description adds real operational context: synchronous execution, task support forbidden, partial-failure policy 'completed_items_not_rolled_back,' deterministic idempotency-key derivation on replay, and the rule that seatId/seatName must be supplied on the exact write call. These are meaningful traits the annotations do not convey, though the 'writes to Studio' classification and generic orchestration guidance are boilerplate.

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 purpose is front-loaded, but the description duplicates the title verbatim (including a doubled period) and then appends a large block of generic orchestration boilerplate about assistantSummary and never displaying raw JSON that is not specific to exporting. Every sentence does not earn its place for this tool.

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 described, and the description does cover the versionId default and seat authorization. However, for a 21-parameter, nested-object tool with 0% schema description coverage, the description leaves most inputs unexplained, so it is only partially complete given 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 0% across 21 parameters, so the description carries the full burden and largely fails it. It clarifies versionId omission semantics and the seatId/seatName requirement, but leaves the export-defining parameters (format, quality, maxBytes, flightId, accountId, locale/market fields) entirely undocumented, and it references 'Mutation modes' for which no schema parameter exists.

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

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

The opening sentence names a specific verb and resource (export an existing Studio CreativeDocument version) and the artifact produced (production JPEG or PNG), and it explicitly rules out adjacent behaviors with 'Does not generate or replace editable creative state,' which separates it from siblings like create_creative_version, generate_preview_links, and traffick_creative. It is clear, though it largely restates the title verbatim rather than adding new 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?

The description implies usage via 'Omit versionId to resolve the current persisted active version' and the negative boundary 'Does not generate or replace editable creative state,' but it never names a concrete alternative tool or the condition that would select one (e.g., export_trafficked_assets vs. generate_preview_links). Guidance is inferable rather than explicit.

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 read-only, idempotent, non-destructive, closed-world. The description adds genuinely useful behavioral facts beyond them: synchronous execution, task support forbidden, and that the payload is internal state with an assistantSummary field. It stops short of permissions, scope, or what 'trafficked assets' actually 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?

The tool-specific content is one redundant sentence; the rest is generic orchestration boilerplate ('Use assistantSummary first', 'Never display raw JSON', 'Prefer concise, human language') that would apply to nearly every tool. The opening sentence wastes the front-loaded position on a tautology.

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, but for a 17-parameter export tool with a single required field and no schema descriptions, the definition omits the parameter meaning and selection context an agent needs to invoke it correctly.

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 17 parameters, so the description carries the full burden of explaining flightId, the json/csv type enum, seat/market/locale fields, and the nested marketContext object. It mentions none of them, leaving every parameter undocumented.

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 opens by restating the title verbatim ('export trafficked assets') and never explains what a trafficked asset is, what the export contains, or how it differs from close siblings like get_trafficked_assets, export_creative, or preview_trafficking_output. It is essentially a tautology of the name.

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 statement of when to choose this tool over the many sibling tools (get_trafficked_assets, export_creative, preview_trafficking_output, traffick_flight). The bulk of the text is generic guidance on how to phrase the user-facing response, which is not selection 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?

Genuinely useful additions beyond the annotations: the partial-failure policy (completed_items_not_rolled_back), the deterministic retry key derived when idempotencyKey is omitted, and the rule that a remembered seat is not valid for a write. However, the listed mutation modes (validate_only, preview_only, execute) have no corresponding schema parameter, which can mislead an agent into passing a non-existent mode, and nothing is said about whether generation is reversible or side-effect scope.

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 first sentence duplicates the title verbatim, and roughly half the text is generic response-formatting boilerplate (assistantSummary, never display raw JSON, suggest the next actionable step) that applies to every tool rather than this one. The genuinely tool-specific facts (partial-failure policy, idempotency derivation, seat rule) are buried at the end of the paragraph.

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, but for a 21-parameter, nested-object, write-classified mutation the description omits what a tag actually contains, whether the flight must be trafficked first, and the meaning of nearly every input. The framing is dominated by chat-presentation instructions rather than what the agent needs to invoke the tool correctly.

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 21 parameters, so the description carries the full burden and discharges only a fraction: idempotencyKey derivation and seatId/seatName requirements are explained, but the required flightId/creativeId, plus platform, accountId, approvalId, force, the locale/market family, and marketContext/marketLanguageProfile objects are entirely undefined. An agent cannot tell which optional fields are meaningful for tag generation.

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

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

The opening sentence "generate adserver tag" simply restates the tool name and title, adding only a classification tag ("writes to Studio") and execution mode. It never states what an ad server tag is, that it is produced for the required flightId/creativeId pair, or how it differs from the sibling get_adserver_tag. An agent learns the verb but not the object it acts 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?

There is no when-to-use guidance and no mention of alternatives, notably the sibling get_adserver_tag which retrieves an existing tag, nor any prerequisite such as a validated or trafficked flight. The only conditional guidance is operational (seat must be supplied when multiple seats are authorised), which does not help the agent choose this tool over 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?

The description adds classification (read-only), execution mode (synchronous), and task support (forbidden), which are useful behavioral traits beyond what annotations declare. Most of the remaining text is output-presentation etiquette (summarize, don't dump raw JSON), which is useful orchestration context but not core tool behavior. The annotations already cover readOnly/idempotent/destructive, so the description modestly enhances them rather than repeating them.

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 first sentence is concise and front-loaded, but the description is padded with a stray double period and a long block of output-formatting instructions that, while not useless, dilute the tool-specific content. Structure is acceptable but not tight.

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?

Context is high complexity: 18 params, 0% schema description coverage, nested objects, and an output schema. The description covers none of the parameter semantics and only partially addresses behavior, leaving the agent without enough guidance to select creatives or set locales correctly. It is under-specified for this 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 coverage is 0% across 18 parameters (creativeId vs creativeIds, sourceLocale, targetMarkets, marketContext, idempotencyKey, etc.), and the description says nothing about any of them. With such a large, undocumented parameter surface, the description should explain the single-vs-array creative pattern, locale handling, and how idempotencyKey works; it does none of this.

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: generate public review preview links for saved Studio creatives, and adds the key distinction 'without changing campaign content'. It is not tautological and differentiates from mutating siblings like traffick_creative or launch_creative_campaign. Slightly weakened by an apparent dangling period after 'content..' but the purpose is clear.

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 relative to the closest siblings (get_preview_link, preview_trafficking_output). The 'without changing campaign content' phrase implies use for review-only flows, but the agent must infer it. 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, openWorldHint=false and destructiveHint=false, so the phrases "Classification: read-only", "Execution: synchronous" and "Task support: forbidden" add nothing new. The description does contribute genuine behavioral context about the payload's intended audience and how it should be surfaced (assistantSummary first, never dump raw JSON), which is useful but concerns presentation rather than the tool's own behavior.

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 of the opening clauses merely echo annotations, and the response-formatting paragraph is long relative to what the tool does. Much of the text is generic orchestration boilerplate that would apply to any read tool, rather than content that earns its place here.

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 21-parameter read tool with nested objects and an output schema, the definition says nothing about what the returned tag represents, which parameters scope the lookup, or error/permission conditions. Output-format guidance is present and the output schema exists, but the input-side picture is essentially blank.

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 21 parameters, so the description must carry the burden and it carries none of it. Neither the required keys (flightId, creativeId) nor the relationship among seatId/platform/accountId/marketContext is explained, leaving the agent to guess which identifiers are needed and why.

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?

"get adserver tag" is a near-restatement of the tool name and title, giving no more specificity than the name itself. It never states what an adserver tag is or how it differs from the sibling generate_adserver_tag, so an agent cannot distinguish a retrieval of an existing tag from generation of a new one.

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 guidance, no prerequisites, and no named alternative. The obvious sibling generate_adserver_tag is never referenced, so the agent gets no routing signal between fetching versus generating a tag.

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 closed-world, so the safety profile is covered. The description adds real context beyond that: synchronous execution, task support forbidden, and that the payload is internal orchestration state containing an assistantSummary field. It stops short of describing size, pagination, or failure behavior.

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 text is dominated by generic, template-like response-formatting boilerplate ("Prefer concise, human language...", "suggest the next best LeanrIQ action") that crowds out tool-specific information. It also opens by restating the tool name rather than front-loading anything useful.

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 23-parameter, deeply nested read tool, the definition omits everything an agent needs to invoke it correctly (parameter meaning, required advertiserId, scope). The output schema exists so return values needn't be explained, but the input side and selection context are essentially 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?

There are 23 parameters at 0% schema description coverage, including a required advertiserId, yet the description says nothing about any of them—no meaning for seatId, flightId, locale fields, or the nested marketContext. With this many undocumented inputs the description must compensate and it does not.

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

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

The opening "get advertiser" merely restates the tool name/title and never says what data is returned or how it differs from siblings like list_advertisers, get_current_seat, or get_campaign. The remaining text is presentation guidance, not purpose specification. An agent learns nothing about scope from this line.

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 call this tool versus the many alternatives (list_advertisers, create_advertiser, update_advertiser, leanriq_resolve_or_provision_advertiser). The instructions present are about how to phrase responses to the user, not about tool selection or preconditions.

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?

The annotations already declare readOnly, idempotent, non-destructive and closed-world, but the description adds material the annotations cannot: the INVALID_INPUT-not-empty-result error contract, the mandatory scope pairing, and orchestration rules about surfacing assistantSummary and withholding raw JSON. Those are real behavioral disclosures beyond the structured hints.

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 most actionable content (scope requirements and the accepted error behavior) is placed last, after a metadata preamble ('Classification: read-only. Execution: synchronous. Task support: forbidden') that partly repeats the annotations and adds little. The presentation guidance is reasonable but not front-loaded, and the ordering works against fast scanning.

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 shape need not be explained, and the critical invocation constraint (scope plus assetId) plus the error contract are covered. Still, for a 23-parameter tool with zero schema documentation, the description leaves most inputs undefined, which is thin for this level of 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 0% across 23 parameters, so the description carries the burden, and it only clarifies the scope triad (assetId, advertiserId, creativeId). The remaining twenty parameters — seatId, flightId, campaignId, templateId, and every locale/market field — get no meaning from either the schema or the description, so it partially compensates at best.

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

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

The opening 'get asset' is a tautology, but the closing sentences do specify the real work: retrieving a single Studio asset scoped by advertiserId or creativeId plus assetId. The listing-vs-retrieving distinction implicitly separates it from the sibling list_assets, though that sibling is never named. Purpose is recoverable, just buried.

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 concrete preconditions (which scope identifiers must accompany assetId) and states the failure mode when scope is missing, which is genuinely useful routing info. However, it never says when to reach for get_asset versus list_assets or get_creative directly, so the when-to-use decision is only implied by the scope discussion.

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