LeanrIQ

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

The description goes well beyond the annotations (destructiveHint, idempotentHint) by detailing mutation modes (validate_only, preview_only, execute), the partial failure policy (completed_items_not_rolled_back), the derived idempotency key behavior, and the seat requirement. This gives the agent critical execution-time expectations.

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 verbose and repetitive; the first two words merely echo the tool name, and most of the long middle section is generic mutation/response boilerplate that doesn't help distinguish this tool. A focused description of what 'archive' does and which parameters matter would be far more 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?

Although an output schema exists, the description omits core domain knowledge: what archiving an advertiser actually does, any prerequisites or side effects, and what the 12 parameters are for. The generic operational details don't compensate for this lack of tool-specific completeness.

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 0% schema description coverage, the description was expected to compensate, but it only mentions seatId/seatName in the seat-authorization rule and idempotencyKey in the retry note. The remaining 10 parameters (accountId, advertiserId, dryRun, flightId, expectedVersion, etc.) are completely unexplained, forcing the agent to guess their meaning.

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 'archive advertiser,' clearly identifying the verb and resource, and the sibling tools (archive_campaign, archive_creative) confirm the scope is advertiser-specific. However, it never states what archiving does or how it differs from related operations, so it's clear but not fully explicit.

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

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

No explicit guidance on when to use this tool versus alternatives like update_advertiser or delete_flight. The generic mutation boilerplate ('Task support: forbidden') offers no decision-making context, leaving the agent to infer usage from the name alone.

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 (destructiveHint=true, idempotentHint=true, readOnlyHint=false), the description adds substantial behavioral context: execution is synchronous, task support is forbidden, mutation modes are validate_only/preview_only/execute, and partial failures are not rolled back. It also explains idempotencyKey fallback behavior, the seatId/seatName requirement for multi-seat mutations, and how the returned JSON should be presented to users. No contradiction with 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 description is a single dense paragraph with useful information, but it is not concise. The first sentence 'archive campaign' is redundant with the title, and many sentences contain generic instructions about response formatting (e.g., 'Use assistantSummary first,' 'Never display raw JSON') that are not specific to this tool. It is structured as a sequence of metadata declarations rather than a clear, scannable explanation.

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 description covers many operational aspects: execution mode, mutation modes, partial failure, idempotency, seat rules, and response handling. However, it does not clarify the business effect of archiving (what happens to the campaign), whether the action is reversible, or how the optional parameters apply to this tool. The presence of an output schema reduces the need to document return values, but the core purpose and parameter applicability remain incomplete.

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 0% schema description coverage, the description carries the burden of explaining parameters. It does add semantics for idempotencyKey (deterministic retry key) and seatId/seatName (must be supplied on the call when multiple seats are authorized). However, it leaves the other 10 parameters unexplained, including dryRun and several optional IDs (flightId, creativeId, resourceId, etc.) whose relevance to archiving a campaign is unclear. The four mutation modes are not mapped to the dryRun parameter.

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 begins with 'archive campaign,' which simply restates the tool's name and title. It does not explain what archiving entails (e.g., moving to an inactive state, hiding from active lists, or unavailability for further edits) and does not distinguish this from sibling tools like archive_advertiser or archive_creative beyond the resource name. The verb 'archive' is specific, but the intended business effect is absent.

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 provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where archiving is appropriate, nor does it exclude cases where other actions (e.g., delete_flight, update_campaign, cancel_task) would be preferable. The metadata about mutation modes and partial failure is useful but does not address selection criteria.

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 significant behavioral context: synchronous execution, task support forbidden, mutation modes (validate_only, preview_only, execute), partial failure policy, idempotency key derivation, and seat requirements on writes. No contradiction with 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 description is lengthy and includes a large amount of generic boilerplate about response formatting (e.g., 'Use assistantSummary first', 'Never display raw JSON') that is unrelated to the tool's core function. Although it starts with 'archive creative', the extra sentences dilute the message and could be trimmed significantly.

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 description provides useful behavioral context (mutation modes, partial failure, idempotency, seat requirements) and an output schema exists, so return values are covered. However, it does not explain which of the 12 parameters are required, what 'archive' entails, or whether the operation is reversible. This leaves gaps for a destructive tool with many parameters.

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 no parameter descriptions in the schema, the description must compensate, but it only touches on idempotencyKey and seatId/seatName. Core parameters like accountId, creativeId, flightId, and others remain unexplained. Partial value is added for two parameters, but the majority are 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 with 'archive creative', a specific verb and resource, clearly distinguishing it from sibling archive tools like archive_advertiser and archive_campaign. The subsequent classification 'writes to Studio, destructive' reinforces the operation's nature.

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 does not provide explicit when-to-use or when-not-to-use guidance specific to this tool. It does not mention alternatives or conditions for archiving. Usage is implied by the name and initial phrase, but no concrete selection guidance is offered.

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

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

The description goes well beyond the annotations by disclosing partial failure policy (completed_items_not_rolled_back), durable execution, billable AI usage, seatId/seatName requirements for multi-seat mutations, and a deterministic retry-key mechanism when idempotencyKey is omitted. These are concrete behavioral traits that help predict side effects. The description is consistent with the idempotentHint annotation, so no contradiction.

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

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

The first two sentences efficiently state the primary purpose, but the remainder contains extensive generic response-handling instructions ('Use assistantSummary first...', 'Never display raw JSON...') that are not specific to this tool and are likely boilerplate. The description is lengthy and dilutes the signal-to-noise ratio, making it harder to parse the essential tool-specific details.

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 description covers many operational aspects: default save behavior, partial failure policy, seat authentication rules, and idempotency, which gives a fairly complete picture of the tool's runtime behavior. However, given the large parameter count (27) and 0% schema coverage, the lack of definitions for most parameters and the absence of a clear distinction from similar sibling build tools leaves significant gaps for an agent trying 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?

With 0% schema description coverage and 27 parameters, the description carries the full burden of parameter explanation. It only clarifies campaignId/campaignName, persistence, idempotencyKey, and seatId/seatName. Core parameters such as brief, assets, template, creativeIds, and instructions remain completely undefined, leaving an agent unable to correctly construct a valid call.

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

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

Opens with a clear verb-object phrase 'Build and save existing Studio creative records,' immediately conveying the tool's core function and its focus on existing records. The campaign-scoped behavior and default save action add specific scope. However, it does not explicitly differentiate from sibling tools such as build_campaign_creative_set or leanriq_build_ad, which could cause confusion in an agent's tool selection.

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

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

The description gives a concrete usage scenario: supplying campaignId/campaignName triggers a full persisted inventory build, and it explicitly restricts persistence preview_only to unsaved ad-hoc previews. It also mentions mutation modes and task support. But it never names alternative tools or states when not to use this tool, leaving the when-to-use guidance implicit 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 only cover readOnly/idempotent/destructive/openWorld; the description goes well beyond them by disclosing billable AI usage, synchronous execution, task support forbidden, the three mutation modes, and a partial-failure policy (completed_items_not_rolled_back). It also explains idempotencyKey derivation behavior, which materially changes how an agent should retry.

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 in the first two sentences, but the remainder is padded with generic orchestration boilerplate (assistantSummary-first, never display raw JSON, mention IDs only when useful) that is not specific to this tool and inflates the definition. The dense metadata block earns some of its space, but the response-formatting prose 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?

An output schema exists, so return values need not be described, and the behavioral block covers cost, execution mode, and failure semantics for a high-complexity tool. However, with 27 parameters, 5 required, two enums, and nested objects at 0% schema coverage, the definition is materially incomplete on the input side, which is the main thing an agent must get right here.

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 27 parameters, including nested brand and doohContext objects, so the description carries the full burden of explaining parameters and largely does not. Only idempotencyKey receives any treatment; required fields like audience, KPI, funnelStage, objective, and the billing/channel enums get no semantic guidance, 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 first sentence states a specific verb ('plan and create'), a specific resource ('an initial Studio creative set'), and a scope constraint ('for a campaign that has no saved creatives'). It explicitly names the sibling it must not be confused with (build_ad) and the disambiguating condition, so an agent can separate it from the other ~80 build/create tools 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?

States when to use (a campaign with no saved creatives), when not to use (rebuilding existing creatives), and the concrete alternative with its required arguments ('use build_ad with campaignId or campaignName'). This is exactly the when/when-not/alternative pattern, with nothing left to inference.

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

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

Annotations cover safety (readOnly=false, destructive=false, idempotent=true), and the description goes well beyond them: billable AI usage classification, durable execution, completed_items_not_rolled_back partial-failure behavior, deterministic idempotency-key derivation on omission, and the 'must supply seatId/seatName on this exact call' write constraint. This is the substantive context an agent needs before a paid mutation.

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 sentence is front-loaded and earns its place, but the description duplicates the title verbatim (including a stray '..'), then pads with generic response-style boilerplate about never showing raw JSON and assistantSummary that is not tool-specific. Roughly half the text is reusable cross-tool guidance rather than this tool's semantics.

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 still covers mutation modes, failure policy, idempotency, and seat auth. The main gap is guidance on the many nested creative/dooh parameters, though the schema's typing and enums carry much of that load.

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 has to compensate; it does so for only two (idempotencyKey derivation and seatId/seatName write requirement). The rich nested objects (copy, assets, format, doohContext) are left entirely to the schema structure, so the compensation is partial.

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

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

The description names a specific verb and resource set: DOOH-native two-concept build, comparison of Studio-rendered posters, and return of an editable non-interactive CreativeDocument. It explicitly distinguishes itself from the Display path ('does not route through Display build_ad'), so an agent can separate it from the many build_* 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?

It tells the agent what this is not (build_ad), lists the mutation modes (validate_only, preview_only, execute) that drive how to call it, and states the seat requirement for writes. It stops short of naming when to prefer leanriq_build_dooh or build_videoad, so alternative routing is only partially resolved.

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 behavior beyond the annotations: it flags billable AI usage, durable execution, optional task support, the three mutation modes, a partial-failure policy (completed_items_not_rolled_back), and the guarantee that no MP4 master is claimed before Studio renders and certifies one. It also explains the idempotency fallback and the exact-call seat requirement, which annotations alone do not cover. This is richer context than the readOnly/idempotent hints provide.

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 balloons with orchestration boilerplate about how to phrase responses to the user and display rules that are tangential to invoking this specific tool, plus a duplicated sentence-ending period after "certified one..".

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

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

For a complex mutation with an output schema present, the description covers the failure policy, idempotency, seat authorization, and mode behavior, so an agent has enough to call it safely. The main shortfall is the near-total absence of parameter-level semantics across 24 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?

With 24 parameters and 0% schema description coverage, the description should carry the semantics, but it only explains idempotencyKey and the seatId/seatName requirement. The remaining ~21 parameters (channel, objective, durationSeconds, sourceAssetIds, composeInStudio, etc.) are left entirely to the bare schema, leaving a large 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 description states a specific verb ("Create") and resource ("advertiser-aware pre-roll or CTV video composition") with channel constraints, which distinguishes it from generic build_ad and build_dooh siblings. It does not explicitly name those siblings, but the pre-roll/CTV framing is specific enough for an agent to select it correctly.

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 conveys execution modes (validate_only, preview_only, execute) and the seat requirement for writes, which imply usage conditions. However, there is no explicit guidance on when to choose this over build_ad, build_dooh, or leanriq_build_ad, and no stated prerequisites or exclusions beyond seatId/seatName.

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,' yet annotations set readOnlyHint=false, and the text itself references 'mutation modes' and 'on a mutation,' creating a direct contradiction. This is a serious inconsistency that would mislead an agent about the tool's side effects.

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 generic instructions about response formatting and JSON handling unrelated to cancel_task's operation. The core purpose is buried under boilerplate, violating front-loading principles.

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?

Despite an output schema existing, the description fails to convey cancellation semantics, side effects, or failure modes. The contradictory classification and generic metadata leave the agent without a reliable mental model.

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 0% schema description coverage, the description must explain all parameters, but it only hints at idempotencyKey and seatId/seatName behavior. The required taskId parameter remains entirely undocumented, and reason and accountId are not explained.

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 simply repeats the tool name ('cancel task') without explaining what cancellation entails, its effects, or how it differs from sibling operations like retry_task or delete_flight. This is a tautology that provides no specific purpose clarification.

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 cancel_task versus alternatives. The generic notes about seatId and idempotencyKey apply to mutations broadly but do not address tool selection or context.

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

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

The description goes well beyond the annotations (which only indicate it's a write, idempotent, and non-destructive). It reveals that execution is synchronous, mutation modes include validate_only/preview_only/execute, partial failures are not rolled back, and a deterministic idempotency key is derived if omitted. It also mandates seatId/seatName for multi-seat writes. These are rich behavioral details that help an agent understand side effects and error handling.

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 overcrowded with generic response-formatting instructions (assistantSummary, raw JSON, mention IDs only when useful) that are not specific to this tool and could be global boilerplate. While the action and key behavioral traits appear early, the critical idempotency and seat rules are buried at the end. The structure could be tightened by separating tool-specific facts from generic response guidelines.

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?

Despite having an output schema and annotations, the description does not clarify the core cloning semantics: what exactly is cloned, how creativeId points to the source, or what approvalId, expectedVersion, and dryRun do. With 8 parameters and 0% schema coverage, an agent would struggle to invoke the tool correctly. The added operational details are helpful but not sufficient to make the description complete.

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

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

Schema description coverage is 0%, so the description must explain parameters. It partially explains idempotencyKey (derived if omitted) and seatId/seatName (required for multi-seat mutations), but leaves creativeId, accountId, dryRun, approvalId, and expectedVersion entirely unexplained. This is insufficient for an agent to correctly populate required parameters like creativeId.

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 'clone creative', which is a specific verb+resource pair that clearly indicates the tool's action. It is distinct from sibling tools like archive_creative or create_creative_version. However, it does not elaborate on what cloning entails (e.g., whether it duplicates an existing creative into a new one), leaving some ambiguity about the exact operation.

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

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

No explicit guidance is provided on when to use clone_creative versus alternatives such as create_creative_version or retraffick_creative. The description mentions 'Task support: forbidden' but this is a constraint, not usage guidance. There is no mention of scenarios, prerequisites, or when another tool would be more appropriate.

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 discloses substantial behavioral detail beyond the annotations: mutation modes (validate_only, preview_only, execute), partial failure policy (completed_items_not_rolled_back), idempotency key derivation when omitted, and the seat requirement on mutations. These are valuable context that annotations alone do not provide. No contradiction with 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 description is verbose and mixes tool-specific behavior with generic response guidelines (e.g., 'Use assistantSummary first', 'Never display raw JSON'). The redundant opening 'create advertiser' restates the tool name. Many sentences are operational policy that applies to all tools, making the description bloated and harder to scan.

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 description provides rich operational context (mutation modes, partial failure, idempotency, seat requirements) but lacks domain context about what an advertiser is in the Studio system and does not explain how this tool relates to similar sibling tools. The output schema exists, so return values are covered, but the description is incomplete for a tool with 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 coverage is 0%, so the description must compensate. It adds meaning for idempotencyKey (omission behavior) and seatId/seatName (conditional requirement), but leaves other parameters like accountId, advertiser, approvalId, expectedVersion, and dryRun unexplained. The schema itself provides structure, but the description only partially compensates for the lack of semantic guidance.

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 the core action clearly: 'create advertiser' and 'writes to Studio'. This makes the tool's purpose unambiguous and distinct from update/advertiser or archive_advertiser by the verb 'create'. However, it does not differentiate from leanriq_resolve_or_provision_advertiser, which may also create an advertiser.

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

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

There is no explicit guidance on when to use this tool versus other advertiser-related tools like update_advertiser or resolve_or_provision_advertiser. The description provides some operational constraints (e.g., seatId/seatName required when multiple seats are authorized) but does not address tool selection or prerequisites beyond that.

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 discloses write classification, synchronous execution, mutation modes, partial failure policy, idempotency behavior, and seat requirements. It goes well beyond the annotations (readOnlyHint false, idempotentHint true) by explaining the derived retry key and seat authorization rule.

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 excessively long and includes generic response-handling instructions (e.g., never display raw JSON, use assistantSummary first) that are not specific to this tool. The first part is concise, but the appended meta-information makes it bloated.

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

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

The tool is complex with nested structures, mutation modes, and idempotency concerns. The description covers these aspects well, including failure policy and seat requirements, and with an output schema present, return-value explanations are not needed. Some details like the meaning of validate_only vs execute could be expanded, but overall it is comprehensive.

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 0% schema description coverage, the description adds useful mappings for campaignName, funnelStage, targetImpressions, and primaryKpi/secondaryKpi. However, it does not explain many other parameters such as budget, status, dates, or the sizes arrays, leaving gaps in understanding.

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 clearly states the tool creates a Studio campaign with a specific verb and resource. It also clarifies that all fields go inside the campaign object and provides natural-language mappings, distinguishing it from sibling tools like update_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?

The description gives clear context for creating a new campaign, including mapping natural language terms to fields and structural guidance ('Put all campaign fields inside campaign'). It also notes seat requirements for writes, but does not explicitly name alternative tools for other operations.

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 it writes to Studio, creates billable AI usage, is synchronous, forbidden as task, has multiple mutation modes, partial failure policy, permission requirements for seat selection, and deterministic retry behavior. This far exceeds annotation coverage.

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 repeats the title nearly verbatim, uses a stray '..', and appends a long series of policy statements without clear structure. While dense, it is not concise and front-loads only the first sentence before a sizable block of instructions.

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?

Given the complexity (27 params, output schema present, annotations), the description provides substantial behavioral context: mutation modes, failure policies, auth requirements, retry logic, and response presentation rules. However, the mismatch between 'saveToStudio' in the description and 'persistence' in the schema, plus minimal coverage of most parameters, prevents a perfect completeness score.

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

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

The schema has 0% description coverage across 27 parameters, so the description must compensate. It explains the role of creativeIds, saveToStudio (persistence), seatId/seatName, and idempotencyKey, but leaves the majority of parameters (brief, input, assets, audience, campaign, template, etc.) undescribed, adding limited meaning for the full parameter set.

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?

Description opens with a clear verb+resource: 'Generate Studio-ready design briefs for one or more creatives,' and specifies the inputs (campaign context, brand rules, audience, offer, format constraints). It also distinguishes the conditional save behavior, separating it from purely read or versioning tools.

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

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

The description gives clear context on when the tool saves vs proposes ('When creative IDs and saveToStudio are supplied... otherwise returns a non-destructive proposal'), and lists mutation modes (validate_only, preview_only, execute). However, it doesn't explicitly name sibling alternatives or state 'use instead of X', so not a full 5.

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 goes well beyond the annotations by disclosing synchronous execution, 'Task support: forbidden', partial failure policy ('completed_items_not_rolled_back'), and mutation modes (validate_only, preview_only, execute). It also explains the automatic derivation of idempotency keys when omitted, which adds meaningful behavioral context.

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 lengthy yet unfocused. It mixes core tool behavior with generic agent response guidelines (e.g., 'Use assistantSummary first', 'Never display raw JSON'), which are not specific to this tool and dilute the message. The essential purpose is buried under orchestration instructions.

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 11 parameters, a nested object, and an output schema, the tool is complex, but the description omits what a creative version is, what the parameters mean, and when to use this tool. The provided behavioral details are useful but do not compensate for the missing core semantics.

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%, so the description must compensate, but it only touches on idempotencyKey and seatId/seatName in passing. The meanings of creative, versionId, approvalId, changeSummary, expectedVersion, and dryRun are never explained, leaving the agent to guess.

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 the exact tool title 'create creative version', which is a tautology. It adds 'writes to Studio' and 'mutation modes' but never defines what a creative version is or how it differs from sibling tools like clone_creative or revise_creative.

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 guidance is given on when to prefer this tool over alternatives. The description provides behavioral constraints (mutation modes, idempotency, seat requirement) but does not explain the circumstances under which create_creative_version should be invoked versus other creative-related 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 declare the write/idempotent/non-destructive profile, and the description adds substantial context beyond that: durable execution, the partial-failure policy (completed_items_not_rolled_back), automatic derivation of a deterministic idempotency key, and the rule that a seatId/seatName must be supplied on the exact write call when multiple seats are authorised. These are genuinely useful traits an agent could not infer from the annotations alone.

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 block of directives; the mutation-mode and idempotency lines earn their place, but the response-presentation boilerplate (never display raw JSON, use assistantSummary, mention IDs only when useful) is generic guidance not specific to create_flight. It is front-loaded with the tool name first, but the signal-to-noise ratio is mediocre.

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 for a 14-parameter mutation with nested creativeConfigs and zero required-field guidance, the description is incomplete: it never states what a flight is, how the campaign/advertiser/account fields interrelate, or which fields are mandatory in practice.

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 14 parameters, so the burden falls on the description, yet it only addresses two of them (idempotencyKey and seatId/seatName). Core fields such as name, platform, accountId, advertiserId, campaignId, expectedVersion, and the creativeConfigs/thirdPartyTags structures receive no explanation at all.

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 flight.', which simply restates the tool name, and never explains what a flight actually is or how it relates to campaigns, advertisers, or creatives. 'Classification: writes to Studio' adds a hint about the write target but no differentiating scope from siblings like create_campaign or build_ad.

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

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

No when-to-use guidance is given against alternatives such as validate_flight, update_flight, or create_campaign. The mutation modes (validate_only/preview_only/execute) hint that validate-only is possible, but the description never says when to prefer this tool or which sibling to reach for instead.

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 goes well beyond the sparse annotations by disclosing billable AI usage, synchronous execution, forbidden task support, mutation modes, partial-failure rollback policy, response formatting rules, and idempotency-key derivation. This gives an agent important operational expectations not available from 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 description is dense but well organized with labeled categories and no wasted words. For a complex tool with 17 parameters, this length is acceptable, though the response-formatting guidance could be condensed.

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?

High complexity (17 params, nested objects, billable side effect, output schema) demands a clear functional definition, but the description never states what a production plan is, how inputs relate to it, or how to choose among sibling tools. The operational policies are useful but leave the core invocation context missing.

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

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

Schema description coverage is 0% and the description names none of the 17 parameters, including all four required fields (brand, campaignName, format, brief). Worse, the claimed mutation modes (validate_only, preview_only, execute) do not match the schema's mode enum (planning, studio_instructions), adding confusion rather than clarifying parameter usage.

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 begins with 'create production plan,' exactly restating the tool name and title without defining what a production plan is or what it contains. 'Classification: creates billable AI usage' describes a side effect, not the tool's core purpose.

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 tool versus alternatives such as leanriq_create_production_plan or create_creative_brief. Constraints like 'Task support: forbidden' and mutation modes are mentioned, but they do not help an agent decide if this is the right tool for a given request.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds useful generic behavioral context about mutation modes (validate_only, preview_only, execute), partial failure policy, and the deterministic idempotency-key derivation. However, it does not disclose delete-specific side effects such as whether the action is reversible or how it affects related campaigns or creatives.

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 long but front-loads a tautology and then spends most of its length on generic orchestration guidance (e.g., 'Use assistantSummary first', 'Never display raw JSON') that is unrelated to this tool. This boilerplate inflates token count and is not appropriately sized for the tool's purpose.

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

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

For a destructive tool with 12 parameters and no parameter descriptions, the description omits tool-specific behavior: what deletion does, prerequisites, effect on associated entities, and reversibility. The generic mutation modes and failure policy provide structural context, but the agent is left without the essential information needed to safely invoke delete_flight.

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 12 parameters and 0% schema description coverage, the description must compensate, but it only explains idempotencyKey and the seatId/seatName requirement. It does not clarify the roles of flightId, accountId, dryRun, expectedVersion, approvalId, or the various resource IDs. Most parameter meanings remain opaque.

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 begins with 'delete flight', which is identical to the tool name and title, providing no additional specificity. It does not explain what deleting a flight entails or distinguish it from sibling tools like archive_flight or validate_flight. The rest of the text is generic mutation boilerplate 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 guidance on when to use this tool versus alternatives such as archive_flight or update_flight. The seat and idempotency rules are generic to all mutations and do not help an agent decide whether deletion is appropriate for a given task. No exclusions or alternatives are mentioned.

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 (readOnly, idempotent), the description adds meaningful context: synchronous execution, task support forbidden, returned JSON is internal state, and explicit instructions on how to present results (use assistantSummary, avoid raw JSON). This adds significant behavioral clarity.

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 consists of multiple short fragments and directives, all relevant but somewhat choppy. It could be more polished, but the information density is acceptable. Not as tight as the two-sentence ideal, so a 3 is appropriate.

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 five parameters and no schema descriptions, the lack of parameter explanation leaves a major gap. The description does provide output-handling instructions and operational constraints, but it ignores input semantics and when the tool should be invoked. The overall completeness for this complex tool is insufficient.

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

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

The schema has zero description coverage, and the description does not explain any of the five parameters (type, seatId, flightId, seatName, accountId). The tool description fails to compensate for the schema's lack of semantics, leaving the agent without guidance on parameter meanings.

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 clearly states the verb 'export' and resource 'trafficked assets', indicating a focused export operation. However, it does not differentiate from siblings like get_trafficked_assets, so it stops short of a 5.

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 does not specify when to use this tool versus alternatives such as get_trafficked_assets or preview_trafficking_output. It mentions execution mode and task support restrictions, but these are operational constraints, not 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 thoroughly discloses behavior beyond the annotations: synchronous execution, forbidden task support, mutation modes, partial failure policy, idempotency fallback, and seat-specific write constraints. This is consistent with annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) and adds valuable context.

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, but the description includes a lengthy block of generic response formatting instructions (assistantSummary, never display raw JSON, etc.) that are irrelevant to the tool's invocation and bloat the description. The core tool-specific details get lost in boilerplate.

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 description provides strong operational context but omits essential domain context: what an adserver tag is, the relationship between flightId/creativeId, prerequisites (e.g., existing flight or creative), and the meaning of the output JSON beyond 'internal application state'. This is a gap for a tool with a complex schema and mutation semantics.

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%, so the burden falls on the description to explain parameters. It only touches on idempotencyKey and seatId/seatName, leaving the required flightId and creativeId completely unexplained, along with platform, accountId, approvalId, and force. This is insufficient for correct parameter usage.

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 the specific verb-object pair 'generate adserver tag' and immediately classifies it as 'writes to Studio', distinguishing it from the read-only sibling get_adserver_tag. This is a clear statement of what the tool does.

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

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

No explicit guidance is given for when to use this tool versus alternatives. While operational constraints like 'Mutation modes' and 'seatId or seatName must be supplied' are mentioned, these are requirements, not usage guidelines that help select the tool.

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

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

The description discloses execution mode (synchronous), task support (forbidden), and provides important response-handling instructions (use assistantSummary, avoid raw JSON). These go beyond the annotations' readOnly/idempotent hints, which align without contradiction.

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

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

The core purpose is front-loaded and clear, but the description includes several generic presentation instructions that pad length. The first sentence repeats the title, and the latter half is generic agent behavior guidance rather than tool-specific details.

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?

Given the output schema and annotations, the behavioral aspects are well covered. However, the lack of parameter semantics and explicit usage guidance leave some gaps for a 6-parameter tool, making it adequate but not complete.

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

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

Schema coverage is 0%, and the description does not explain individual parameters like seatId, accountId, or idempotencyKey. It does connect 'one or more creatives' to creativeId/creativeIds, but leaves other parameters undocumented, so the description only partially compensates.

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 clearly states the tool generates public review preview links for one or more saved Studio creatives, and explicitly notes it does not change campaign content. This distinguishes it from the singular get_preview_link sibling by supporting multiple 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?

No explicit alternatives or exclusions are provided. The phrase 'without changing campaign content' implies a safe preview use case, but it does not contrast with get_preview_link or other preview tools. Usage 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 adds behavioral traits beyond the annotations: 'Execution: synchronous' and 'Task support: forbidden' are explicit and not present in the annotations. It also discloses that the returned JSON is internal application state for LeanrIQ/ChatGPT orchestration and gives clear response-handling rules (use assistantSummary first, never display raw JSON, mention IDs only as needed). This enriches the agent's understanding of the tool's 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 description is relatively concise, but the first sentence 'get adserver tag' is entirely redundant with the tool name. The subsequent metadata and response instructions are structured and to the point, but the tautological opening wastes space and lacks tightness.

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?

Given the tool's complexity (9 parameters, 2 required), the description is incomplete. It focuses heavily on response formatting but fails to explain what an adserver tag is, how the parameters relate to the tag, or any practical usage context, leaving the agent under-informed 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?

None of the 9 parameters (e.g., flightId, creativeId, force) are explained in the description. With schema description coverage at 0%, the description does nothing to compensate, leaving the agent without any guidance on what values to provide.

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 'get adserver tag,' which simply restates the tool name without explaining what an adserver tag is or what it represents. It does not distinguish this tool from siblings like generate_adserver_tag, leaving the purpose as a 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 guidance on when to use this tool versus alternatives such as generate_adserver_tag or other getters. No prerequisites, exclusions, or contextual triggers are provided, and the response-handling instructions do not aid in tool selection.

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, so the description's addition of 'Execution: synchronous' and 'Task support: forbidden' provides some extra behavioral context not in the structured annotations. However, the description focuses more on how to present results than on operational behavior like error handling or auth requirements.

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 five sentences, but most are dedicated to output formatting and behavioral rules (e.g., 'Never display raw JSON,' 'Prefer concise, human language') that belong in a system prompt rather than a tool description. The first sentence is a tautology, and the structure buries any useful operational detail under generic agent instructions.

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?

Given the tool has 11 parameters and no parameter descriptions, the description fails to explain what an 'advertiser' is or how the various IDs (seatId, flightId, campaignId, etc.) relate. The output schema exists, which covers return shape, but the description's vague 'internal application state' does not compensate for the lack of parameter semantics or usage context.

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%, and the description does not explain any of the 11 parameters. It never mentions advertiserId, seatId, or other fields, leaving the agent to guess that advertiserId is the primary identifier. The description adds no semantic value for choosing or filling parameters.

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 'get advertiser,' which is essentially the tool's name and title, providing no elaboration on what exactly is retrieved or returned. It does not distinguish this tool from siblings like get_campaign or get_asset, and the rest of the text is about response presentation, not purpose.

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 tool versus alternatives like list_advertisers or update_advertiser. The instruction 'Use assistantSummary first' refers to response composition, not tool selection, and the 'suggest the next best LeanrIQ action' is generic advice that doesn't clarify the tool's intended use case.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable beyond-annotation details: execution is synchronous, task support is forbidden, the returned JSON is internal orchestration state, and missing scope results in INVALID_INPUT rather than an empty result. These clarify expected behavior and failure modes. No contradiction with 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 description is overly long and front-loaded with a tautological opening. Much of the content is generic response-handling instructions (never display raw JSON, use assistantSummary first) that apply to many tools, not specific to get_asset. While the scoping details are well-structured, the response-formatting boilerplate could be omitted for conciseness. Two or three sentences could convey the essential behavioral 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?

Given the tool's complexity (11 parameters, numerous sibling get_* tools), the description is incomplete. It doesn't differentiate this tool from get_creative or get_advertiser, doesn't explain the remaining parameters, and creates ambiguity by mentioning 'listing assets' without specifying the tool for that action. The output schema exists, so return values aren't a gap, but the parameter semantics and tool-selection context are insufficient.

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%, so the description must compensate. It explains the roles of assetId, advertiserId, and creativeId (as scopes), but entirely ignores the other 8 parameters (seatId, flightId, campaignId, etc.). These parameters may be filter or context fields, but their meaning and usage are never addressed. The description only partially clarifies the most critical parameters, leaving a significant semantic 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 description begins with the tautological phrase 'get asset' and only indirectly states its purpose via 'when retrieving one asset.' It implies retrieval of an asset's internal state but doesn't clearly define what an 'asset' is or how it differs from sibling tools like get_creative or get_advertiser. The scoping requirement (advertiserId/creativeId) hints at a specific resource type but lacks explicit 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?

Provides usage context for scoping: 'pass one of those scopes together with assetId when retrieving one asset' and warns about INVALID_INPUT. However, there is no explicit guidance on when to use this tool versus alternatives like list_assets or get_creative. The instruction to 'Use assistantSummary first' is about response formatting, not tool selection. The guidance is implied rather than explicitly contrasted with sibling 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 cover read-only, idempotent, open-world, and non-destructive behavior. The description adds value by disclosing synchronous execution, not saving to Studio, and that the returned JSON is internal application state for orchestration. It also provides response-handling constraints, such as not showing raw JSON unless explicitly requested, which goes beyond the structured 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 description is reasonably compact and front-loaded with the core purpose, but it repeats read-only information already in the title and annotations. Several sentences focus on response presentation rather than tool invocation, and there is a typo ('Studio..'). It is structured enough to be readable, but not every sentence earns its place.

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

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

The description covers the read-only/no-save behavior and response safety constraints, and an output schema exists, so return values need not be described in prose. However, parameter semantics for requestedSections and forceRefresh are absent, and there is no guidance relating this tool to refresh_brand_profile or the leanriq alias. Overall it is adequate for a read tool but has 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%, and the description provides no explanation of the seven input parameters. Required fields like brandName and brandUrl are inferable from their names, but requestedSections and forceRefresh are left undefined by both the schema and the description. With low schema coverage, the description needed to compensate and 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 description states a clear verb and resource: 'Research and return a LeanrIQ brand profile.' It also clarifies this is a read capability that does not save to Studio, which distinguishes it from mutating tools. However, it does not differentiate from the similarly named sibling leanriq_get_brand_profile or from refresh_brand_profile.

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, and no alternatives are named. The read-only/no-save phrasing implies a research use case, but it never tells an agent when to choose this tool over refresh_brand_profile or leanriq_get_brand_profile. The 'Task support: forbidden' line is cryptic and does not provide actionable 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 cover read-only/idempotent/non-destructive safety, so the bar is lower, and the description adds useful context: synchronous execution, task support forbidden, and that it does not persist to Studio. It omits operational traits like scraping/browser-fetch latency, failures on unreachable URLs, or rate limits for the open-world fetch.

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 core purpose and routing sentence is front-loaded and tight, but the opening sentence duplicates the title verbatim and is followed by boilerplate classification lines and a long orchestration/presentation-policy paragraph. Roughly half the text is not about tool selection.

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 annotations carry the safety profile. However, for a tool with a 17-field options object, nested storage config, and zero schema documentation, the description leaves an agent unable to reason about how to configure 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 7 parameters, and the nested options object exposes ~17 undocumented knobs (useBrowser, scrapeSocial, includeAiGeneratedImages, storage bucket/prefix/cdnBaseUrl) with no explanation of defaults or effects. The description contributes no parameter meaning at all, leaving required advertiserId/brandName/websiteUrl and all option flags 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?

States a specific verb (collect) and resources (logos, imagery, colours, fonts, visual previews) plus the downstream consumer (Studio creative builds). An agent can distinguish it from get_brand_profile and refresh_brand_visuals from the description 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?

Gives explicit timing ('Use this before build_ad when a campaign needs visual grounding') and a negative constraint ('does not save to Studio'). It does not name the obvious alternative, refresh_brand_visuals, or say when refresh is preferable.

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 behavior. The description adds valuable behavioral context: warns that Studio aiActivation/adBuild fields are workflow state, not creative inventory, preventing misinterpretation. It also notes the returned JSON is internal state and should not be displayed raw, which goes beyond structured 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 description is verbose and includes extensive presentation instructions (e.g., 'Use assistantSummary first,' 'Never display raw JSON') that are unrelated to tool selection or invocation. Essential information about purpose and alternatives is buried among general response-style guidance, reducing clarity.

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?

Although an output schema exists, the description lacks technical specifics: it does not clarify how the many optional parameters interact, what happens when multiple identifiers are provided, or error conditions. The behavioral warning about aiActivation/adBuild fields is helpful, but the tool invocation context remains incomplete.

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 11 parameters and 0% schema description coverage, the description provides no explanation for any parameter except an implicit mention of campaignId in the usage note. It fails to define seatId, taskId, assetId, or other parameters and their interactions, leaving the agent without semantic understanding for invocation.

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 clearly states 'get campaign' and 'Campaign metadata only,' specifying the verb and resource. It also distinguishes from sibling tools by explicitly noting it is not for creative inventory and directing to list_creatives. However, the purpose is embedded in a lengthy description with unrelated presentation guidance.

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 explicit when-to-use and alternative guidance: 'If the user asks for creatives or creative inventory for a known campaignId, call list_creatives directly; do not preflight get_campaign.' This clearly tells the agent when not to use the tool and which sibling tool to use instead.

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 and idempotent. The description adds that execution is synchronous, task support is forbidden, and the returned JSON is internal application state for orchestration. It also provides instructions on how to handle the response (not showing raw JSON, suggesting next steps). This adds useful behavioral context beyond 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 description is a series of short, directive sentences that are easy to parse. It front-loads the purpose and classification, then adds behavior and response guidelines. No unnecessary words; every sentence contributes either to purpose or usage instructions.

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?

Given the tool's simplicity (no required params, output schema present), the description still lacks essential context: it doesn't explain what capabilities are returned, how the parameters affect results, or when this tool should be chosen over sibling tools. The output schema may cover return values, but the description's focus on presentation rules leaves functional 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% and the description does not mention any of the three parameters (seatId, seatName, includeHidden). The description provides no meaning or usage hints for the parameters, so it completely fails to compensate for the missing schema descriptions.

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 starts with 'get capabilities' which clearly identifies the action and resource, but provides no scope or distinction from similar tools like get_permissions or get_current_seat. The rest of the description focuses on output formatting rather than clarifying what capabilities are. This is a clear but under-specified purpose.

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 guidance on when to use this tool vs alternatives. The description mentions using 'assistantSummary first' when responding to the user, but this is about response strategy, not tool selection. There are no explicit when/when-not or alternative tool references.

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 annotations (readOnlyHint, idempotentHint, destructiveHint false), the description adds 'Execution: synchronous', 'Task support: forbidden', and detailed instructions on handling returned JSON (never display raw JSON, use assistantSummary, suggest next action). These are meaningful behavioral disclosures not present in structured 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 description is front-loaded with the primary purpose and contains useful behavioral guidance in a structured format. It has minor redundancy (first sentence repeats the title) and a double period, but it remains concise and informative for its 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?

The output schema exists, covering return values, and the description covers key behavioral constraints and usage context. However, it does not explain parameter semantics or explicitly differentiate from related tools like leanriq_get_competitor_creative_intelligence, leaving some gaps for an 8-parameter tool.

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

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

Schema description coverage is 0% and the description does not explain any of the 8 parameters (e.g., seatId, competitorId, includeEvidence). The only hint is 'advertiser-scoped competitor' in the title, which does not define parameter meaning. This is a significant gap for a tool with many parameters.

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 clearly states the verb 'Read' and the resource 'saved canonical LeanrIQ Competitor Intelligence V2 for an advertiser-scoped competitor.' It explicitly notes what it does not do ('does not reacquire evidence or generate new recommendations'), distinguishing it from sibling tools like run_competitor_intelligence.

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 provides clear context on when to use the tool (for reading saved intelligence) and explicitly excludes reacquisition or new recommendations, implying it is not for fresh generation. However, it does not name specific alternative tools, so it lacks explicit when-not-to-use references.

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 useful behavioral context beyond the annotations: synchronous execution, 'task support: forbidden,' and the fact that return data is internal application state. It also provides response-handling directives (avoid raw JSON, prefer concise language) that help the agent behave correctly after invoking the tool. No contradictions with 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 description is relatively compact and front-loaded with 'get creative,' followed by a tight list of execution traits and response rules. Some redundancy exists (e.g., 'Classification: read-only' duplicates annotations), but the overall length is reasonable and the most actionable instructions are included.

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?

Although an output schema exists, the description is incomplete for invocation because it never explains how to use the 11 input parameters or what the tool actually does beyond 'get creative.' Annotations cover safety properties, but the agent lacks enough context to confidently select parameters or understand the tool's role.

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 0% schema description coverage, the description must explain parameters, but it does not mention a single one. The required creativeId is not described, and the 10 optional identifiers remain opaque strings with no guidance on their meaning or selection.

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 'get creative,' which merely restates the tool name and title without defining what a 'creative' is or what the retrieval operation returns. It adds that the returned JSON is 'internal application state,' but this does not clarify the core purpose relative to sibling get_* tools like get_asset or get_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?

There is no explicit guidance on when to use this tool versus alternatives. The instruction to 'Use assistantSummary first' is about response composition, not tool selection, and 'Task support: forbidden' is a vague constraint without suggesting when the tool should or should not be invoked.

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 read-only and non-destructive behavior, but the description adds useful context: execution is synchronous, the output is internal state for orchestration, and it instructs the agent on how to present results (e.g., suggest next action). This goes beyond the structured fields and helps the agent behave correctly with the returned data.

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

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

The description is moderately sized and front-loaded with the tool name, but it includes several instruction-like sentences that could be considered general communication guidance. It is not overly verbose, but some content feels like boilerplate rather than tool-specific 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?

Given its simplicity (read-only, two optional params, output schema present), the description should clearly explain what a 'seat' is and how to use the parameters. Instead, it focuses on response handling and leaves the core semantics ambiguous. The cryptic 'Task support: forbidden' adds confusion rather than clarity.

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

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

The schema has two optional parameters (seatId, seatName) with 0% description coverage. The tool description does not mention these parameters at all, leaving the agent without any guidance on what they mean, when to provide them, or how they affect the result. This is a significant 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 description states 'get current seat' which is a clear verb+resource pair, and adds that it returns internal application state. However, it does not explain what a 'seat' is, nor does it distinguish this tool from similar siblings like leanriq_current_seat or list_accessible_seats. The purpose is understandable but ambiguous.

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 provides response-formatting rules such as 'Use assistantSummary first' and 'Never display raw JSON', but gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or what problem it solves in the workflow. The 'Task support: forbidden' line is cryptic and not actionable.

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 readOnly/destructive/idempotent annotations, the description explicitly states synchronous execution, 'task support: forbidden', and that the returned JSON is internal application state. It provides detailed output-handling rules (don't expose raw JSON, use assistantSummary, concise human language, suggest next action). No contradiction with 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 description is longer than minimal but front-loaded with the purpose and safety classification. The later sentences cover critical output-handling rules and are not waste, though some classification details repeat annotation information. No structural clutter.

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 description conveys operation type, safety, execution, and output handling, and an output schema exists. However, it omits parameter semantics and the relationship to sibling tools, leaving gaps for a tool with optional seat parameters and similar seat-related tool names.

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

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

The input schema has two optional parameters (seatId, seatName) with 0% schema description coverage, and the description never mentions them or their purpose. The agent receives no guidance on whether or how to set them, so the description fails to compensate for the missing schema descriptions.

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 'get current user', a specific verb+resource, and the title matches. It does not explicitly distinguish from sibling tools like get_current_seat or leanriq_current_seat, but the user/seat distinction is inferable. It lacks detail on what 'current user' encompasses.

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 alternative selection guidance is provided. The description mentions 'Use assistantSummary first' and 'suggest the next best LeanrIQ action', but these are response-formatting directives, not tool selection criteria. It does not tell the agent when to prefer this over get_current_seat or list_accessible_seats.

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 provide readOnlyHint=true and idempotentHint=true, so the description's addition of 'Classification: read-only' is redundant. It does add that execution is synchronous and that task support is forbidden, which are useful behavioral hints. The note about 'internal application state' is a mild disclosure, but it doesn't detail any side effects, permissions, or limitations beyond what annotations already 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 description is relatively short but is structured as a run-on sentence that mixes operational metadata (classification, execution) with generic output formatting instructions. Some parts, such as 'Mention IDs only when useful,' are not specific to this tool and appear to be global instructions, making the description less focused than it could be.

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?

Given the tool's complexity (11 parameters, output schema, many sibling tools), the description is incomplete. It does not explain what a flight is, what data the tool retrieves, or how it fits into the broader workflow. The presence of an output schema helps, but without context about the resource and its relationship to other tools, the description fails to provide sufficient operational context.

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 11 parameters and 0% schema description coverage, the description carries the full burden of explaining parameters like flightId, seatId, assetId, etc. It does not mention any of them, leaving the agent completely in the dark about what each parameter is for or how they relate to the tool's purpose. This is a critical gap for a tool with this many parameters.

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 begins with 'get flight,' which merely restates the tool name and provides no additional detail about what a flight represents or what the tool actually does. It fails to distinguish this tool from siblings like list_flights or get_campaign, and the mention of 'internal application state' is vague and unhelpful for understanding the resource.

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

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

There is no guidance on when to use this tool versus alternatives such as list_flights or validate_flight. The description focuses entirely on output presentation rules (e.g., use assistantSummary, avoid raw JSON) rather than the tool's intended usage context, leaving the agent without direction on selecting the appropriate tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so restating 'Classification: read-only' is largely redundant. It does add value beyond annotations by disclosing synchronous execution, forbidden task support, and orchestration behavior (use assistantSummary first, never surface raw JSON, mention IDs only when useful). That output-handling contract is genuinely useful context not covered by structured fields, but the repetitive safety restatement dilutes it.

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, which is wasted space, and the trailing period-doubling from concatenation is sloppy. The behavioral/orchestration guidance that follows is reasonably front-loaded and earns its place, but roughly a third of the text is redundant with the title and annotations.

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

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

An output schema exists, so the description is not obligated to document return values, and the pointer to assistantSummary is a helpful complement. What is missing is any guidance on the two undocumented seat parameters and any routing signal versus the many overlapping capability/permission/seat siblings. For a discovery/bootstrap tool in a crowded toolset, this leaves a real selection 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?

Two parameters (seatId, seatName) exist with 0% schema description coverage, and the description says nothing about them at all. An agent cannot learn what a seat ID is, whether it is required, how seatId and seatName interact, or what happens if both or neither are supplied. The description does not compensate for the schema gap in any way.

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?

It names a verb ('Describe') and a resource ('LeanrIQ outcomes... capability profile, safe starting action, boundaries'), which is more specific than a bare name restatement. However, the opening sentence is a verbatim copy of the title, so it adds no new discriminating information, and it never distinguishes itself from the sibling get_capabilities, get_permissions, or get_current_seat tools. An agent cannot tell from this text which discovery 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?

There is no explicit statement of when to call this versus get_capabilities / get_permissions / get_current_seat, which all plausibly answer overlapping 'what can I do' questions. The phrase 'safe starting action' hints at a bootstrap role but is not framed as usage guidance. Most of the text is output-formatting instruction aimed at the model rather than 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds extra behavioral context: execution is synchronous, task support is forbidden, the JSON is internal application state, and there are explicit instructions on how to present results. This goes beyond the structured annotations and helps the agent handle the response appropriately. No contradiction with 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 description is relatively concise and front-loaded with the primary purpose. It uses structured labels (Classification, Execution, Task support) and gives clear response-handling rules. Minor issues include a typo ('reporting..') and a slight ramble into presentation style, but overall it is organized and not redundant.

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

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

Despite having an output schema, the tool is complex (15 params, nested objects) and the description provides no information about what delivery data is returned, how media_buy_ids are used, or what filtering options exist. The description focuses on output formatting rather than tool function, leaving the agent underinformed about when and how to invoke it effectively.

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

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

The schema has 15 parameters and 0% description coverage. The description provides no explanation of any parameter (e.g., media_buy_ids, start_date, end_date, filters). Since the schema alone is insufficient for an agent to know how to populate fields, the description's complete lack of parameter guidance is a major deficiency.

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 the tool provides 'AdCP-standard media-buy delivery reporting,' which indicates a specific resource and action (reporting on media buy delivery). It is distinct from sibling getters like get_flight or get_campaign by focusing on media buy delivery. However, it does not specify what metrics or data are included, leaving some ambiguity.

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

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

There is no explicit guidance on when to use this tool versus alternatives. It mentions the returned JSON is for 'LeanrIQ and ChatGPT orchestration' and gives response-formatting instructions, but these are not usage criteria. No exclusions or alternative tool references are provided, so the agent gets no clear decision support.

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 discloses several behavioral traits beyond annotations: execution is synchronous, task support is forbidden, and the returned JSON is internal application state not to be displayed raw. These add useful context and do not contradict the readOnlyHint/idempotentHint/destructiveHint 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 description is a long paragraph mixing tool purpose with response-format instructions (e.g., 'Never display raw JSON', 'Suggest the next best LeanrIQ action'). This is bloated and not appropriately front-loaded; much of the content belongs in a system prompt rather than a tool description.

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?

While the tool has an output schema and some behavioral context (read-only, synchronous, internal state), the description lacks usage guidelines and parameter semantics. For a tool with three undocumented parameters and no guidance on when to use it, the description is incomplete despite the output schema covering return values.

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

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

Schema description coverage is 0% and the description does not explain any of the three parameters (seatId, seatName, accountId). The description entirely fails to compensate for the missing schema descriptions, leaving the agent with no semantic guidance for parameters.

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 'get permissions' as a specific verb+resource, clearly indicating the tool retrieves permission information. However, it does not explicitly differentiate this tool from the many other 'get_*' tools in the sibling list, so it earns a 4 rather than a 5.

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 provides no guidance on when to use this tool versus alternatives. It mentions 'Task support: forbidden' which is a restriction, but does not state appropriate use cases or point to sibling tools. This is minimal guidance at best.

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 behavioral context beyond the annotations: it states execution is synchronous, task support is forbidden, and the returned JSON is internal application state for heavyweight orchestration. It also instructs how to present results (never raw JSON, mention IDs only when useful). These are meaningful behavioral disclosures that help the agent understand side effects and output sensitivity. The read-only claim matches the annotation, so there is no contradiction.

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

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

The description is not excessively long, but the opening sentence is tautological and adds no value. The subsequent sentences deliver useful usage instructions, but they are somewhat scattered, mixing classification, execution mode, and user-interaction guidelines. While each sentence is short, the overall structure weaves general orchestration policies into a tool-specific description, making it less crisp than it could be.

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?

Despite having an output schema, the description leaves critical gaps. It never states what the preview link looks like, what input identifiers are needed, or what operational prerequisites exist. With 11 parameters and no schema descriptions, the tool remains poorly documented. The note that the returned JSON is 'internal application state' is helpful but does not compensate for the missing parameter information and overall purpose clarity.

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 11 parameters and 0% schema description coverage, the description carries a heavy burden to explain parameters, but it mentions none by name or meaning. It does not even identify the required 'previewId' or any ID relationship. The description is entirely silent on parameter semantics, leaving the agent to guess the purpose and constraints of each field.

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 begins with 'get preview link', which merely restates the tool name and provides no additional verb or object detail. It fails to specify what the preview link is for, what it contains, or how it differs from sibling tools like 'generate_preview_links' or 'preview_trafficking_output'. The rest of the description focuses on output handling instructions rather than clarifying the tool's core purpose.

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

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

The description gives no explicit guidance on when to call this tool versus alternatives. It mentions using 'assistantSummary first' and never displaying raw JSON, but these are general response-formatting rules, not usage conditions. No prerequisites, typical scenarios, or alternative tools are referenced, leaving the agent without decision criteria for selection.

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 synchronous execution, forbidden task support, and detailed output-handling instructions (use assistantSummary, don't display raw JSON, suggest next action). It aligns with annotations (readOnlyHint=true) and provides context beyond 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?

The first sentence is a clear purpose statement, but the description includes redundant information (e.g., 'Classification: read-only' duplicates readOnlyHint) and a long block of output-presentation instructions that are somewhat tangential. Still, it is structured and 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?

For a polling tool, the description covers purpose, source of tasks, and post-poll behavior. With an output schema present, it doesn't need to describe return structure. It lacks explicit error/retry guidance, but that is partially covered by sibling 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 has 0% description coverage; the description does not explain the three parameters (seatId, taskId, seatName). It only implies taskId via 'returned by build_ad...' but gives no semantics for seatId/seatName, leaving a significant gap for a 3-parameter tool.

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 a specific verb ('Poll') and resource ('durable LeanrIQ task'), names the originating capabilities (build_ad, revise_creative, trafficking), and signals continuation with the completed output. This clearly distinguishes it from siblings like list_tasks, cancel_task, and retry_task.

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 specifies that tasks are returned by queued capabilities and that the agent should continue with completed output. It does not explicitly mention alternatives like list_tasks for enumeration or retry_task for failures, but the context of polling a specific task is clear, with no misleading exclusions.

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