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?

The annotations already mark this as a non-read-only, idempotent mutation, but the description adds billable AI usage, synchronous execution, forbidden task support, mutation modes, partial failure policy, and deterministic idempotency-key derivation. These details go well beyond the annotations and are directly useful for invocation.

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 and usage are front-loaded, but the description then appends a long block of generic assistant-response instructions ('Use assistantSummary first', 'Never display raw JSON') that are not tool-specific. These sentences add noise and make it longer than necessary, though the core sections remain clear.

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 25-parameter mutation with nested objects, the description covers timing, failure policy, billing, and idempotency, which is valuable. However, it omits any guidance on required parameters and domain concepts, so an agent must guess from parameter names alone. The output schema exists, but completeness is still limited by the missing parameter 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?

The input schema has 25 parameters and 0% schema description coverage, so the description must carry parameter semantics. It only meaningfully explains idempotencyKey behavior ('deterministic retry key... cannot create duplicate work'), leaving required fields like objective, audience, KPI, and funnelStage unexplained. This is insufficient compensation for the low schema coverage.

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 action ('Plan and create') and resource ('initial Studio creative set'), explicitly scoping to campaigns with no saved creatives. It also distinguishes from the sibling build_ad by naming it as the tool for rebuilding.

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

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

It gives an explicit exclusion: 'Do not use this tool to rebuild existing creatives' and points to build_ad with campaignId/campaignName. The 'initial ... no saved creatives' phrase states the intended condition, making selection straightforward.

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?

The description goes beyond the annotations by disclosing durable execution, validate_only/preview_only/execute mutation modes, completed_items_not_rolled_back partial failure policy, internal-state return JSON, idempotency key derivation, and the multi-seat seatId/seatName requirement. It is consistent with the readOnly=false, idempotent=true, destructive=false annotations and adds no contradictions.

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 long and front-loaded with the action and classification. However, it includes generic agent response guidelines (assistantSummary, raw JSON, language style) that are not tool-specific and could be omitted, making it less concise than ideal.

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 13-parameter mutation with mutation modes and partial failure semantics, the description lacks essential details: what each mode does, how dryRun relates to the modes, what constitutes a complete flight, and what fields are needed for a successful execute. The output schema is present, but the input semantics are underspecified.

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 13 parameters and 0% schema description coverage, the description only explains idempotencyKey and the seatId/seatName requirement. It does not describe the meaning or relationships of name, platform, flightId, accountId, campaignId, advertiserId, creativeConfigs, dryRun, expectedVersion, etc., leaving major gaps for an agent to correctly construct a create_flight request.

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 action 'create flight' with a specific verb and resource, and adds 'writes to Studio' to clarify the system context. It does not explicitly differentiate from siblings like update_flight or validate_flight, but the create verb is unambiguous.

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

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

The description provides context about mutation modes, execution durability, and partial failure policy, but it does not explicitly state when to use create_flight over alternatives. It includes a prerequisite that seatId/seatName must be supplied on the exact call for multi-seat writes, which is useful, but lacks exclusions 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?

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?

Beyond readOnlyHint and idempotentHint, it discloses synchronous execution, forbidden task support, internal JSON usage, formatting rules (assistantSummary first, no raw JSON), and next-action suggestion. This is valuable contextual 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 somewhat lengthy but front-loaded with the core purpose. The instructions are structured and useful, though slightly repetitive (same sentence in title and description) and includes a minor typo (double period).

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 covers return values, and annotations cover safety. The description adds execution and formatting context, but missing parameter explanations and sibling differentiation leave gaps for correct invocation.

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

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

Schema has 0% description coverage, and the description is silent on parameter semantics. brandName and brandUrl are required but not explained; forceRefresh and seatId are not mentioned at all. The description fails to compensate for the schema 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 clearly states the tool researches and returns a LeanrIQ brand profile, with a read-only, non-persistent scope. However, it does not differentiate from the similar leanriq_get_brand_profile sibling.

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

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

It implies use when you need brand profile research, but never explicitly contrasts with refresh_brand_profile or leanriq_get_brand_profile. It gives output-formatting guidance but not selection guidance.

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

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

Beyond annotations (readOnly, idempotent), the description adds 'Execution: synchronous', 'Task support: forbidden', and states the returned JSON is internal application state for orchestration. It also provides response handling guidance (use assistantSummary, avoid raw JSON). This adds useful behavioral context beyond what annotations declare.

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 clear, but the description then becomes a run-on list of operational instructions (classification, execution, task support, response formatting) that repeats annotation info. Several sentences about never displaying raw JSON and using assistantSummary are about user interaction, not the tool's behavior, making it overlong.

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?

Provides strong workflow context (when to use, read-only nature) but completely omits parameter details—especially options that control what assets are collected. With 7 parameters at 0% schema coverage and nested objects, the description is insufficient for an agent to know what values to pass. No mention of expected return structure despite an output schema existing.

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 0% description coverage and the description does not explain any of the 7 parameters, including required fields like advertiserId, brandName, websiteUrl. The collection goals are listed, but there is no mapping to options like maxLogos, fetchFonts, etc. Description fails to compensate for the lack of schema documentation.

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?

Clearly states the tool collects brand visual assets (logos, imagery, colours, fonts, previews) for Studio creative builds. The phrase 'Use this before build_ad' differentiates it from other getters in the workflow. Specific verb 'Collect' with a defined set of resources.

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?

Explicitly directs use 'before build_ad when a campaign needs visual grounding' and notes it does not save to Studio, setting expectation of read-only usage. However, it does not name alternative tools like get_brand_profile or refresh_brand_visuals, so it scores below the highest tier.

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?

The description discloses useful behavioral traits beyond annotations: it creates billable AI usage, executes synchronously, supports mutation modes (validate_only, preview_only, execute), has a partial failure policy, and returns internal application state. It also notes idempotency behavior. These details add value beyond the annotations, though some are generic boilerplate.

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

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

The description is overly long but contains mostly generic operational text (classification, execution, task support, mutation modes) that likely applies to many tools. It is not front-loaded with tool-specific purpose; instead it begins with a repetition of the name followed by boilerplate. Each sentence does not earn its place relative to the tool's actual function.

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 is incomplete for a tool with this complexity. It fails to explain the core function (what competitor intelligence is), the meaning of key parameters, or how to interpret results. The output schema may cover return values, but the description still lacks domain context and selection guidance, leaving the agent uncertain about when and how to use the 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?

The input schema has 8 parameters (brandName, website, limit, region, seatId, adFormat, seatName, vertical) with 0% description coverage. The description provides no explanation of what any parameter means, how they relate, or example values. It only mentions idempotencyKey, which is not even in the schema. This is a critical gap for correct 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 starts with 'get competitor intelligence', which merely restates the tool name/title without adding specificity. It does not explain what type of competitor intelligence is returned or how this differs from sibling tools like get_vertical_intelligence or leanriq_get_competitor_creative_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?

There is no guidance on when to use this tool versus alternatives. The only usage-related instruction is about how to format responses, which applies after invocation, not for tool selection. It fails to mention prerequisites, use cases, or exclusion conditions.

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?

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.

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

The description adds behavioral context beyond the annotations by stating execution is synchronous, task support is forbidden, and the returned JSON is internal application state. It also specifies response-handling rules (never display raw JSON, mention IDs selectively). These are useful traits not captured by the readOnly/idempotent/not-destructive hints. However, it does not disclose error behavior or the nature of template data beyond being internal state.

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

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

The description is a single run-on sentence containing several instructions. It redundantly repeats 'Classification: read-only,' which is already in annotations, and includes a mix of tool purpose and global orchestration rules. It is not excessively long but lacks clear structure and could be tightened to separate purpose from 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, the description is incomplete for an 11-parameter tool with no parameter documentation. It does not explain what a template is, when to fetch it, or how the returned internal state should inform the assistant's response beyond vague formatting rules. The description leaves major gaps in domain 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 provides absolutely no explanation of any of the 11 parameters. Even the required templateId is undocumented in both the schema and description. The description does not compensate for the missing parameter semantics, leaving the agent to guess which IDs are needed and how they relate.

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 restates the name 'get template' without adding any specificity about what a template is or what getting it accomplishes. It does not distinguish this tool from siblings like list_templates or get_asset. The phrase 'internal application state' is vague and does not clarify 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?

No guidance is provided on when to use this tool versus alternatives. The only usage-related instruction is 'Use assistantSummary first when responding to the user,' which is a generic response rule, not a tool-selection criterion. There is no mention of prerequisites or scenarios where this tool is preferred.

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 (read-only, idempotent, non-destructive), the description adds 'Execution: synchronous' and 'Task support: forbidden', and clarifies that 'The returned JSON is internal application state' not meant for direct display. It also instructs the agent to summarize and suggest next actions, which is valuable behavioral context. 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 each sentence adds distinct information: classification, execution, task support, output nature, and response guidelines. It is front-loaded with the purpose and avoids unnecessary verbosity, though it lacks structured separation.

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?

Even with an output schema, the description leaves the agent without context on parameter meanings, what exactly constitutes a 'trafficked asset', or how this tool differs from export/preview variants. The high complexity (11 params, 0% schema coverage) requires more contextual guidance to be 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?

The schema has 11 parameters with 0% description coverage, and the description provides no explanation for any parameter. It doesn't mention that flightId is required or what any of the IDs refer to. The description completely fails to compensate for the schema gap, leaving the agent without essential semantic context.

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 uses the specific verb 'get' and states the resource 'trafficked assets', clearly indicating it retrieves trafficked assets. However, it doesn't explicitly differentiate itself from sibling tools like export_trafficked_assets or preview_trafficking_output, so it lacks sibling distinction.

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

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

The description provides no guidance on when to use this tool instead of alternatives. It focuses on response formatting (e.g., 'Use assistantSummary first', 'Never display raw JSON') rather than selection criteria. 'Task support: forbidden' is a constraint, not a usage guideline.

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 'Execution: synchronous' and 'Task support: forbidden,' and reveals that the output is 'internal application state,' all of which go beyond the annotations. It also provides concrete handling rules (never display raw JSON unless asked, use assistantSummary first) that add behavioral context without contradicting 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 compact paragraph but mixes core tool semantics with lengthy output-presentation instructions. The 'Classification: read-only' line is redundant with the annotations, making the structure less efficient 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 27 undocumented parameters and no output schema preview in this assessment, the description is inadequate for understanding the tool's operation. It explains neither what 'vertical intelligence' is nor how inputs relate to outputs, leaving a massive functionality gap.

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

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

The schema has 27 properties with zero descriptions, and the description does not mention any parameter or hint at how to fill them. With 0% schema description coverage, the description completely fails to compensate, leaving the agent without any semantic understanding of inputs.

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 vertical intelligence' which merely restates the tool name without defining what 'vertical intelligence' actually is or what it does. The added context that the returned JSON is 'internal application state for LeanrIQ and ChatGPT orchestration' hints at a purpose but remains too vague to distinguish it from sibling tools like leanriq_get_vertical_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?

No guidance is provided on when to call this tool versus alternatives, what problems it solves, or any exclusions. The only usage-like instruction is 'Use assistantSummary first when responding to the user,' which addresses post-call response formatting, not tool selection.

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