Heista

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

Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds valuable context: the pipeline downloads, runs vision tagger (classifies type, detects product name, flags is_primary_product), stores, and inserts a row, plus notes the vision tag credit cost. This goes beyond annotations 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 description is brief (two sentences for main purpose plus a necessary note). Every sentence adds value: the main description explains the action and pipeline, the note warns about implementation status. No fluff, front-loaded with key verb and resource.

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?

No output schema exists, so the description should explain return behavior. It mentions 'inserts a brand_assets row' but not what the function returns. The note says it returns a 'not implemented' envelope, which is useful but incomplete for fully describing the tool's behavior when functional. Adequate but with 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 coverage is 100% with descriptions for both parameters. The description adds extra meaning: for brand_id, hints to 'Get from list_brands'; for image_url, details the pipeline steps. While schema already covers basics, these additions improve usability, warranting a score above the baseline of 3.

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

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

The description clearly states 'Upload an image to a brand by URL', specifying the action, resource, and method. However, the note about 'not implemented' slightly undermines immediate clarity, but the core purpose is well-defined and distinguishes from sibling tools like list_brand_assets and delete_brand_asset.

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 states 'Not implemented in MCP yet' and provides alternatives: the REST endpoint and workspace UI uploader. This gives clear when-not-to-use guidance and alternative approaches, which is excellent for agent decision-making.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true; description adds that formulas are abstracted, include source ad count, average active days, confidence score, etc., and are not exact transcripts. 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?

All sentences contribute important information. The description is front-loaded with purpose, then details, then usage guidance, and there is no redundancy or fluff.

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?

No output schema exists, but description thoroughly covers return fields (source ad count, avg active days, etc.) and integration with generate_adscript. With 6 parameters all documented in schema and additional usage advice, the tool is fully specified.

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?

Input schema has 100% description coverage, so parameters are well-documented. The description adds value by suggesting filtering order and the prioritization strategy for selecting results, which goes beyond schema details.

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 returns 'proven ad formula blueprints' and differentiates from siblings like decode_ad and generate_adscript by specifying that formulas are abstracted structural patterns, not exact transcripts. It also notes the tool is free and provides filtering advice.

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?

Explicit guidance: 'Use for generate_adscript with source_type="formula".' 'Filter by vertical first, then narrow...' and a prioritized order for selecting results. Also tells when not to use it: 'For sentence-level fidelity, use a single decode 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 indicate read-only, idempotent, non-destructive behavior. The description adds specific return details (balance in cents, lifetime spend, monthly counts, top-up link), which enriches the behavioral model beyond annotations.

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

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

The description consists of two well-structured sentences. The first sentence details the tool's function and outputs, the second provides clear usage context. Every word adds value with no redundancy.

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

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

Given zero parameters, thorough annotations, and no output schema, the description adequately covers the tool's purpose and return information. It could optionally mention error cases or authentication needs, but the current level is sufficient for an agent to correctly invoke 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 zero parameters, so no parameter description is needed. According to the guidelines, a baseline of 4 is appropriate since the schema coverage is 100% and no parameters exist.

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 explicitly states the tool checks credit balance, usage breakdown by operation, and pricing for paid tools. It clearly identifies the verb 'Check' and the resources (balance, usage, pricing). No sibling tool overlaps with this 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 directly states 'Call when the user asks about credits, balance, usage, top-ups, or pricing.' This provides clear usage triggers. Although no explicit when-not-to-use is given, sibling tools are sufficiently distinct to avoid confusion.

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 credit cost (100 credits), output shape (same as create_powersource_url), and idempotency key usage. It does not contradict annotations (readOnlyHint: false, etc.). It could mention that it is non-destructive but this is already implied by annotations. Good balance.

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

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

The description is front-loaded with purpose and output, followed by usage context and parameter details. Every sentence adds value, and there is no redundancy. It fits essential information in a concise yet comprehensive paragraph.

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

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

Given the tool's complexity (5 parameters, no output schema, no enums), the description is comprehensive. It explains output shape by referencing a sibling tool, cost, and parameter behavior. Minor lack: it doesn't specify behavior when both file_ids and document_urls are provided, but overall it covers key aspects well.

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?

Input schema covers all parameters with descriptions, so baseline is 3. The description adds significant value for the documents_inline parameter, including detailed instructions on extracting text and base64 encoding. For other parameters, it adds minimal extra detail beyond schema. Overall, it compensates for 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 clearly states the tool's purpose: building a creative intelligence profile from internal brand documents. It specifies document types (briefs, guidelines, etc.) and output fields (brand identity, buyer profile, tensions, etc.). It distinguishes itself from the sibling tool create_powersource_url by emphasizing the use of documents versus website URLs.

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

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

The description provides clear guidance on when to use this tool: 'when the truth lives in PDFs and DOCX, not on the website.' It also explains how to pass documents via file_ids or document_urls, and mentions optional context_url. However, it could be more explicit about when not to use it (e.g., if data is already in a structured format).

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 indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds cost (200 credits), requirement of both URL and document, and states result shape matches another tool. Does not detail any side effects or authorization needs, but context is sufficient.

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

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

Four well-structured sentences: purpose, use case, return shape, and alternatives. Front-loaded with key information, no wasted words.

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?

Covers usage, requirements, cost, and alternatives. Lacks output schema, but references shape of sibling tool. Adequate for a complex tool, though more detail on return fields would improve 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?

Schema coverage is 100%, but description adds critical nuance: 'Requires both a URL and at least one document' and provides detailed guidance on inline documents (text-only pipeline, handling PDF/DOCX). This significantly aids 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 clearly states it 'builds the highest-fidelity creative intelligence profile' by combining URL and documents, and distinguishes from siblings by mentioning single-mode variants for URL-only or docs-only.

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 says 'Use when you want public messaging triangulated against internal strategy' and advises 'For URL-only or docs-only, use the single-mode variants.' Also notes cost and requirements.

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?

Provides detailed behavioral traits beyond annotations: credit cost, caching rules, scope tags for data freshness (brand vs product level), and derived sections. 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?

Well-structured with bullet points and sections, front-loaded with purpose. Slightly lengthy but justified by complexity.

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?

Comprehensive coverage: explains caching, credit costs, output structure via scope tags, relationships with siblings, and no output schema needed as described.

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 already covers all 4 parameters with descriptions (100% coverage). The description adds context about caching interactions (force_refresh) but does not significantly enhance parameter meaning beyond schema.

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

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

Clearly states it builds a creative intelligence profile from a URL, specifies it's optimized for ad creative and not for executive strategy, and references sibling tools like generate_adscript that use the output.

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 describes usage context (ad scripts vs. executive strategy), caching behavior, credit costs, and how it feeds into other tools via brief_id or job_id.

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 detail beyond annotations: it reveals it's an async operation returning a job_id to poll, costs credits (15-20), and supports specific platforms. Annotations indicate not read-only and not destructive, which aligns with the write-like behavior of costing and polling.

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

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

Three sentences with clear structure: first sentence states core purpose, second details outputs and usage, third covers support and costs. Every sentence adds value without redundancy.

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

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

Despite no output schema, the description fully explains the async workflow (returns job_id), credit costs, supported platforms, and integration with generate_adscript. This is complete for a decode tool of medium 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?

With 100% schema coverage, the description adds value by explaining the URL supports multiple platforms and the idempotency_key's retry-safe behavior. This enhances understanding beyond the schema.

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

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

The description clearly states the tool reverse-engineers video ads into structural formulas, with specific outputs like beat-by-beat breakdown and hook classification. It distinguishes itself from siblings like decoder_intelligence and generate_adscript by focusing on decoding and linking to script generation.

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 explicit when-to-use context (reverse-engineer ads for structure) and links to generate_adscript. It lists supported URL formats and credit costs, though it doesn't explicitly state when not to use or alternatives for other ad types.

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 aligns with annotations (readOnlyHint, destructiveHint, idempotentHint). It adds context about the corpus source and the downstream use of the returned 'id', which goes beyond annotations. 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 three sentences with no redundancy. The first sentence states purpose and return value, the second explains downstream usage, and the third gives guidance and lists filters. Very efficient.

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

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

The description covers the tool's purpose, return structure, filter options, and a key downstream use case. It lacks explicit mention of filter combination logic (AND/OR) and default limit, but given the schema covers defaults, it's mostly 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?

All 7 parameters have descriptions in the input schema (100% coverage), so the description adds moderate value by providing examples and usage context. However, the schema already explains each parameter well, so the description's additional meaning is limited.

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 browses individual decoded ads and specifies the resource (decoded ads) and action (browse). It distinguishes from siblings by mentioning an 'id' for use in generate_adscript, implying a specific use case not covered by averaged formulas.

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 explicit when-to-use guidance: 'Use when you want a specific ad as a template, not an averaged formula.' This implies an alternative tool for averaged formulas, though it doesn't name it directly. The guidance is clear and helpful.

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 (destructiveHint=true, idempotentHint=true), the description explains exactly what gets deleted: the brand_assets row and, if uploaded, the storage object. This 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?

Two substantive sentences plus a directive, front-loaded with the core purpose. Every sentence adds value.

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

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

For a simple single-parameter destructive tool, the description covers purpose, behavioral effects, and usage steps. Minor gap: no mention of return value or behavior on non-existent asset, but idempotentHint suggests safe re-calls.

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

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

Schema coverage is 100% with a description referencing list_brand_assets. The description reinforces this guidance but adds no new meaning beyond the schema.

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

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

The description clearly states the action (delete), resource (brand asset by asset_id), and distinguishes from siblings like list_brand_assets and add_brand_asset. It specifies the scope: removes row and optionally storage object.

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 (destructive deletion) and prerequisite (use list_brand_assets first to find asset_id). Directs confirming with user before calling, which is strong 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 goes beyond the annotations by detailing behavioral traits such as auto-rotation of tensions and selling points across variants, metered pricing with a pre-flight credit ceiling, and the effect of the idempotency_key. Since annotations are minimal (readOnlyHint=false, etc.), the description fully covers the tool's non-destructive but consumptive behavior and pricing model.

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 paragraph of 6 sentences, tightly packed with essential information. Each sentence serves a purpose: core function, parameter sourcing, mode distinctions, variant generation, and pricing. No wasted words, and the most critical information is front-loaded.

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

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

Given the tool's complexity (11 parameters, no output schema), the description is comprehensive. It explains how to obtain prerequisite IDs from sibling tools, the difference between blueprint and remix modes, auto-rotation of variants, and the credit pricing model. The only minor gap is a precise description of the output structure beyond 'hook, beat-by-beat body, and CTA close,' but this is adequate for an AI agent to understand the return value.

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 100% schema coverage, the baseline is 3. The description adds value by explaining the provenance of source_id (from specific tools) and powersource_id (from create_powersource_*), clarifying that duration only works in remix mode, and noting auto-rotation of tensions/selling points for the count parameter. These enrich the schema descriptions without repeating them.

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's function: generating direct-response video ad scripts from a proven structure and a brand's PowerSource. It specifies the output format (hook, beat-by-beat body, CTA) and distinguishes itself from siblings by referencing where to obtain the required source_id and powersource_id (adformula_intelligence, decoder_intelligence, etc.), making its role in the workflow 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 explicit instructions on when to use the tool, including how to pass source_id, source_type, and powersource_id from specific sibling tools. It also explains the two script modes (blueprint vs remix) and when each is appropriate. However, it does not include explicit 'when not to use' or alternatives among siblings, which would further enhance guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint as true. Description adds 'free, read-only' and specifies output contains full body payload, providing some additional context but not extensive behavioral detail beyond what annotations cover.

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

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

Two efficient sentences: first states purpose and output, second provides usage guidance. No wasted words.

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

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

For a simple retrieval tool with one parameter and no output schema, the description fully covers what it does, what it returns, and how to obtain the required input.

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?

Single parameter 'id' has full schema description with format and regex. Description reiterates the discovery method, adding value but baseline for high coverage is 3.

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

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

Clearly states the verb 'Get' and resource 'ad formulas preset by id', and specifies it returns the full body payload including framework and agent config. Distinguishes from sibling list tool.

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

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

Explicitly advises to call the matching list tool first to discover ids, and notes it is free and read-only. Lacks explicit when-not-to-use, but context makes it clear.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description confirms read-only and adds detail on returned fields and free access, providing useful context beyond annotations.

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

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

Two sentences, no fluff. Purpose, content, and usage are front-loaded and 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 simple read tool with one parameter and no output schema, the description fully covers what the tool does, what it returns, and when to use it, especially with supporting annotations and sibling list.

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

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

Schema coverage is 100% with a description for the single parameter. Description doesn't add extra parameter semantics beyond what schema provides, meeting the baseline.

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

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

Description clearly states it retrieves a full brand record listing specific fields (name, domain, voice, story, visual identity, counts), distinguishing it from sibling tools like list_brands and get_powersource.

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 says to use for inspecting brand before running Heist context or reading brand voice when writing copy. Also notes 'Free, read-only' and points to list_brands for obtaining brand_id.

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?

Description adds context beyond annotations by specifying the returned payload includes 'full body payload (framework, agent config, etc.)'. Annotations already declare readOnlyHint and idempotentHint, so description complements them well.

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?

Description is two sentences, front-loaded with the main action, contains no filler, and each sentence adds distinct value.

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

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

For a simple tool with one parameter and no output schema, the description is sufficiently complete: it states the purpose, prerequisite, and nature (free/read-only). Could be slightly more explicit about the return structure, but 'full body payload' is adequate.

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

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

Schema coverage is 100%, and the description merely mentions 'by id' without adding new semantics beyond what the schema provides (UUID format, discover via list). Baseline of 3 is appropriate.

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

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

Description clearly states 'Get one creative agents preset by id, including its full body payload', specifying the verb (get), resource (preset), and scope (by id). It distinguishes from sibling list tool by advising to call the list tool first.

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 instructs to 'Call the matching list tool first to discover ids', providing a clear prerequisite. Also states it is 'Free, read-only', indicating when it's safe to use.

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

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

Annotations declare readOnly and idempotent. Description adds polling behavior and status-checking logic, which is valuable beyond annotations. 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?

Two sentences, front-loaded with purpose, then usage details. No wasted words.

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

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

Complete for a polling tool: explains retrieval, status check, and retry logic. No output schema needed provided. Annotations cover safety.

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?

Input schema has 100% coverage with description for job_id referencing decode_ad. Description reinforces where to get the parameter, adding value over schema alone.

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 retrieves a completed decode or checks status, with specific verb 'Retrieve' and resource 'decode result'. It distinguishes from sibling decode_ad by referencing it as the source of job_id.

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 clear usage context: pass job_id from decode_ad, and if status is processing, wait 15 seconds and retry. Lacks explicit 'when not to use', but guidance is strong.

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 and idempotentHint. Description adds 'Free, read-only' and that it returns 'full body payload', which adds context beyond annotations. However, without an output schema, more detail on the payload structure would be ideal but not critical.

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

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

Two sentences, each serving a distinct purpose: stating the action and giving usage guidance. No superfluous text, front-loaded with the core functionality.

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 (1 param, no nested objects, no output schema), the description covers everything needed: what it does, how to use it, and its read-only nature. No gaps are apparent.

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 single parameter 'id' has 100% schema description coverage. The description repeats 'Discover ids by calling the matching list_<type>_presets first' which is redundant with the schema's description. No additional meaning is added beyond what the schema provides.

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

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

The description clearly states 'Get one decoded ads preset by id, including its full body payload', specifying the verb (get) and resource (decoded ads preset). It distinguishes from sibling list tools that discover IDs and other get_*_preset tools by covering different preset types.

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 instructs to 'Call the matching list tool first to discover ids', providing clear sequential dependency. Also notes 'Free, read-only' which reassures about side effects, though no explicit when-not-to-use is given.

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 value beyond annotations by disclosing that the tool is free and returns specific data types (examples, templates, psychology, performance data). Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior, 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?

Two sentences plus a filtering note. Every sentence is essential: first states purpose, second gives usage context and filtering options. No fluff, well 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?

Given it has 3 optional parameters, no required ones, no output schema, the description does a good job listing what the tool returns. It could be slightly more specific about the structure of the response, but it's adequate for the 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 100% with descriptions for each parameter. The description adds guidance on omitting parameters to get top-performing types or all verticals, which goes beyond the schema. It could mention the marketing_angle parameter explicitly, but the schema covers it.

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 that the tool returns proven hook patterns from a corpus of winning ads, including examples, templates, psychology, and performance data. It uses the verb 'Get' and resource 'hook intelligence', which distinguishes it from sibling tools like 'adformula_intelligence' or 'decode_ad'.

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

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

The description tells the user to use it for writing scroll-stopping openers, mentions it's free, and provides filtering options. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide.

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 and idempotentHint. The description adds that the call is 'Free' and includes the full body payload, which provides additional 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?

Two concise sentences that front-load the action and result, with no wasted words. Every sentence adds value.

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

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

For a simple one-parameter tool with no output schema, the description adequately covers purpose, usage, and behavior. The context of sibling list tools is clear, and the return structure is hinted.

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

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

Schema description coverage is 100%, so the parameter is well-documented. The description adds little beyond mentioning the payload, but the schema already guides the agent to use the list tool. Baseline 3 applies.

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

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

The description clearly states it retrieves one static ads preset by ID and includes the full body payload. It distinguishes from sibling list tools and other get tools by specifying the resource type.

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 instructs to call the matching list tool first to discover IDs, and notes that the operation is free and read-only, providing clear context for when and how to use.

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 (read-only, idempotent), description details polling behavior, partial progressive results, and examples of returned fields. 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?

Two concise sentences with key information front-loaded. No extraneous text.

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?

Adequate for a single-param retrieval tool without output schema. Describes polling and partial results, though could mention completion states or error handling.

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 covers job_id fully, but description adds value by explaining its source (create_powersource_* calls) and usage direction.

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 clearly states it retrieves completed PowerSource or checks status, referencing job_id from create_powersource_* calls. Distinguishes from sibling creation tools and other retrieval tools like get_decode.

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 tells to pass job_id and wait 3-5 seconds if processing. Could mention not to use before creation, but context implies 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?

Description adds details beyond annotations: confirms read-only, mentions 'full body payload' return, and states it's free. Consistent 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?

Two concise sentences cover purpose, return content, usage guidance, and safety. No waste.

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

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

For a simple read tool with one parameter and no output schema, the description covers all essential information: what, how to call, and what to expect.

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?

Parameter 'id' is fully described in schema; description adds crucial context on how to obtain it (via list tool), which is not in the schema.

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

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

Clearly states the tool gets a saved visual idea preset by ID and includes its full body payload. Distinguishes from sibling get_*_preset tools by specifying the resource type and mentioning the prerequisite list call.

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 instructs to call the matching list tool first to discover IDs. Also states 'Free, read-only' to indicate safety and cost profile.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true. Description adds that it's 'Free, read-only' and includes 'full body payload', which clarifies the return nature beyond annotations. 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?

Two sentences: first sentence states the action and return value, second provides workflow guidance and cost hint. No redundant information; every word serves a 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 single-id retrieval tool with no output schema, the description fully covers what the tool does, how to prepare (list first), and what kind of data to expect (full body payload). Combined with annotations, it provides sufficient context for the agent to use correctly.

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

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

Schema coverage is 100% with one parameter 'id'. Description adds context on how to obtain the id ('discover ids by calling the matching list_<type>_presets first'), which is not present in the schema's format/pattern alone. This helps the agent understand the parameter's sourcing.

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 clearly states 'Get one visuals preset by id, including its full body payload'. The verb 'Get' and resource 'visual preset' are specific, and the mention of 'full body payload' distinguishes it from simpler list operations. Among sibling tools with similar get_* names, it uniquely identifies this preset type.

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 advises to 'Call the matching list tool first to discover ids', which guides proper workflow. Also notes it's 'Free, read-only', indicating low cost and safety. Does not explicitly state when NOT to use it, but the instruction to list first implies the tool requires a known id.

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 and idempotentHint true, and the description adds 'Free, read-only' which reinforces but does not contradict. It also mentions 'full body payload' giving a hint about the return content, adding some value beyond annotations.

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

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

Two sentences with no wasted words. The purpose is front-loaded, and each sentence serves a clear function: stating the action and providing usage guidance.

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

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

For a simple get-by-id tool with full schema coverage and clear annotations, the description is complete. It mentions the return content ('full body payload') and the prerequisite, leaving no significant gaps.

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

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

Schema description coverage is 100% and already includes a description of the id parameter including how to discover ids. The description text duplicates this guidance but does not add new semantic meaning beyond the schema.

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

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

The description clearly states 'Get one visual styles preset by id' with specific verb and resource. It distinguishes from sibling list tools by implying this is for retrieval of individual preset details.

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 explicitly advises to 'Call the matching list tool first to discover ids', providing clear prerequisite guidance. It lacks explicit when-not-to-use instructions but is sufficient for typical use.

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

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

Annotations declare readOnlyHint, idempotentHint, and openWorldHint=false; the description confirms 'Read-only, free' and adds behavioral details: mutual exclusion of filters, pagination, and that the data is Heista-curated. 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 extremely concise: two sentences delivering purpose, behavior, and usage guidance. Every word is functional and front-loaded. No wasted sentences or repetitions.

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 no output schema, the description covers purpose, filter options, pagination, and read-only status. It hints at the use case ('served as a generation parameter'). Could be slightly more explicit about what the returned list contains, but overall sufficient.

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 100% coverage so baseline is 3. The description adds meaning by explaining the filter scope ('same toggle as the in-app library lens') and mentioning that only_workspace/only_official are mutually exclusive, which enhances understanding beyond the schema comments.

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 identifies the resource as 'Cluster-level structural formulas derived from decoded ads' and specifies it is 'Heista-curated'. The verb 'List' combined with 'Ad formulas' in title makes the action explicit. It distinguishes from siblings by noting the cluster-level and generation parameter 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 states it is 'Read-only, free' and describes filtering options with mutual exclusivity (only_workspace/only_official) and pagination (limit+offset). It provides clear context for usage but does not explicitly state when NOT to use or compare to alternatives like list_decoded_ad_presets.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'Free, read-only. Paginated via cursor.' and lists return fields (asset_id, signed url, type, etc.), providing behavioral context beyond the annotations. 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 two sentences, front-loading the action and filters, then providing usage advice and return info. Every sentence adds value with no redundancy or fluff.

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 7 parameters, no output schema, and presence of annotations, the description covers purpose, filters, usage guidance, return structure, and pagination. It is mostly complete; minor omissions like default ordering do not significantly hinder understanding.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters. The description adds minimal extra value by grouping filters ('Filter by PowerSource... by on-pack product_name...') but does not significantly expand on the schema descriptions. Baseline 3 is appropriate.

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

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

The description clearly states 'List images for a brand' and enumerates all filter options, distinguishing it from sibling tools like add_brand_asset or delete_brand_asset. It also provides a concrete use case: 'Use this BEFORE generating any image-based output so you pick from the brand's real assets, not generic stock.'

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 explicitly advises 'Use this BEFORE generating any image-based output', giving a clear when-to-use recommendation. It does not explicitly list when not to use it or alternatives, but the sibling tools are distinct (e.g., add/delete/retag). This is nearly excellent 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?

Annotations already declare readOnlyHint and idempotentHint, so the description adds context about the include_all parameter and 'free, read-only' nature. Does not contradict 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?

Three paragraphs with useful information, front-loaded with core purpose and usage. Could be slightly more concise but no extraneous content.

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

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

Completely covers what the tool returns (fields listed), how to use it, and distinguishes from related concepts, despite having no output schema.

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

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

Schema coverage is 100%, and description adds meaning by explaining the effect of include_all=true (transient/signal-less drafts) and ties default to UI behavior, going beyond schema details.

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 clearly states 'List every brand in this workspace' with specific verb and resource, and distinguishes from sibling tools like list_strategies and create_powersource_* by explaining the difference between Brand and PowerSource.

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 advises using before creating a PowerSource to avoid duplicates, and for discovering brands for Heist pivoting. Provides example user queries and distinguishes from related tools.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds that it is read-only and free, and clarifies the mutual exclusivity of filters, which is beyond what annotations provide.

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

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

Four sentences, each serving a purpose: purpose, scoping, nature (read-only), and filtering. Front-loaded with key information. No fluff.

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?

Covers listing scope, filtering options, and pagination. Lacks explicit mention of what the output contains (e.g., preset names), but is fairly complete for a list tool without output schema.

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

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

With 100% schema coverage, baseline is 3. Description adds value by explaining mutual exclusivity of only_workspace and only_official, comparing to a UI toggle, and noting that brand_id only affects workspace presets.

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 clearly states the tool lists reusable creative agents for handoff targets, distinguishing between workspace and official presets. This differentiates it from sibling tools like list_brand_assets.

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 guidance on when to use only_workspace vs only_official, notes mutual exclusivity, and mentions paging. However, doesn't explicitly state when not to use 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'Read-only, free' which aligns with annotations but doesn't disclose additional behavioral traits (e.g., rate limits, data freshness).

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 four sentences, front-loading the core purpose, then providing key details on data sources, filters, and pagination. Every sentence adds value with no redundancy.

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

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

For a list tool with 5 parameters and no output schema, the description adequately explains data sources, filter options, and pagination. However, it omits return value structure or example usage, which would enhance 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that 'only_workspace' and 'only_official' are mutually exclusive and analogous to an in-app UI toggle, which clarifies their usage beyond the schema.

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

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

The description states it lists 'Structural references for script-led Heists' and specifies the data sources, distinguishing from sibling list tools that focus on different preset types (e.g., ad_formula, image_ad_scan). However, it uses jargon that may be unclear to new users.

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 mentions filtering with 'only_workspace' and 'only_official' and pagination, but does not explicitly state when to use this tool versus alternatives like 'get_decoded_ad_preset' or other list tools. Usage context 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?

Annotations already declare readOnlyHint and idempotentHint. The description adds 'Read-only, free' and pagination details, but does not disclose additional behavioral traits like rate limits or error conditions.

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

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

Three sentences, front-loaded with purpose, no unnecessary words. Efficient and well-structured.

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

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

With no output schema, the description does not detail return format, but the tool is simple and parameters are fully described. Lacks output structure but otherwise sufficient.

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

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

Schema coverage is 100%. The description adds context that only_workspace and only_official are mutually exclusive and analogous to an in-app toggle, which goes beyond the 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 clearly states the tool lists static-ad references for image-led Heists, distinguishing it from sibling tools like list_ad_formula_presets. It uses a specific verb and 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?

The description explains filtering with only_workspace/only_official and pagination, but does not explicitly state when to use this tool versus alternatives. No when-not or comparative guidance.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'Read-only, free' and 'Page with limit + offset,' which are consistent. However, the phrase 'Workspace-only' is slightly misleading because the only_workspace and only_official filters allow toggling scope, contradicting the implication of an exclusive workspace scope.

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

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

The description is extremely concise (two sentences) and front-loaded. Every sentence serves a purpose: identifying the resource, specifying scope/read-only nature, explaining filter usage, and pagination. No superfluous content.

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

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

The tool has no output schema, yet the description does not explain what each returned item contains or the default behavior (e.g., ordering). It covers pagination and filters but lacks details on result format, which is needed for full completeness given the absence of output schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal parameter value: it notes mutual exclusivity of only_workspace/only_official and likens them to an 'in-app library lens,' but this is not a significant semantic addition beyond the schema.

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

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

The description clearly states the tool lists 'Visual ideas you saved from prior generations.' It specifies the resource (saved visual ideas) and action (list). The mention of 'Workspace-only' and filters distinguishes it from other list tools like list_visual_preset_presets.

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 explicitly guide when to use this tool vs. its siblings. It provides filter usage details but no alternatives or exclusion criteria. For example, it doesn't differentiate from list_visual_style_presets or list_image_ad_scan_presets, which are similar list 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?

Description adds 'Free, read-only' and 'Paginated via cursor' beyond annotations, which already declare readOnlyHint and idempotentHint. No contradictions; it reinforces and supplements behavioral traits.

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 compact (5 sentences) and well-structured, front-loading the main purpose and progressively adding detail. Every sentence provides useful information without redundancy.

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

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

For a list tool without output schema, the description enumerates returned fields and mentions pagination and cost. It could discuss error behavior or empty results, but it is sufficiently complete for typical use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the context of parameters (e.g., brand_id from list_brands) and the returned fields, which helps beyond the schema definitions.

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 it lists all PowerSource strategies for a brand, specifying the verb and resource. It distinguishes from siblings like list_brands by focusing on strategies and adds nuance about product-page strategies and returned fields.

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 guidance on when to use (to list strategies per brand) and how to use the results (labeling or product-focused generation). Could be improved by explicitly mentioning alternatives like get_powersource for a single strategy, but still clear enough.

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 indicate readOnly, idempotent, and not openWorld. The description adds valuable behavioral details: returns specific sources (buyer_profile, primary_audience) with cardinality constraints (one max, up to 3). It also notes the UI picker reads the same projection, implying consistency. 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 extremely concise: two main sentences plus a clarifying sentence. It front-loads the purpose and returns, with no superfluous text. Every sentence adds value.

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 no output schema, the description explains the return structure (sources and counts). It provides context about the UI picker. However, it could mention potential error cases or pagination behavior, but the tool's simplicity and annotations mitigate the need. Overall, fairly complete.

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

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

Schema coverage is 100% with a detailed parameter description that already explains the parameter's purpose and source. The tool description does not add additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists audience archetypes for a strategy (PowerSource), specifying the exact types returned: Buyer Decoder archetype and primary_audience segments. It also differentiates from sibling tool list_strategies by emphasizing this operates inside a single strategy.

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 states the use case: 'Use this to pick which audience to target before generating copy / scripts / hooks.' It clearly distinguishes from list_strategies, providing appropriate context for when to use this tool versus alternatives.

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

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

Annotations declare readOnlyHint and idempotentHint as true, and openWorldHint false. The description adds significant behavioral detail: the tool currently returns at most one entry (the synthesized tone_of_voice), is limited to POWER-mode bundles, and has a list-stable shape for future expansion. 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 three sentences, front-loaded with the core purpose. Every sentence adds value without redundancy. The structure is efficient and easy to parse.

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 simple input schema (1 parameter, no enums, no output schema), the description fully explains the tool's behavior, current limitations, and future stability. It covers everything needed for an agent to use it correctly.

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

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

Schema description coverage is 100% for the single parameter powersource_id. The description adds context by explaining where to get the id (list_strategies) and what it returns, providing useful semantics beyond the schema's format constraints.

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 a specific verb ('list') and resource ('tone profiles for a strategy'), clearly distinguishing it from siblings like list_strategies and list_strategy_audiences. It adds context about the synthesized tone_of_voice and POWER-mode exclusivity.

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 advises using this tool 'before writing copy, hooks, or scripts' to align with brand voice. While it doesn't explicitly state when not to use it, the context is clear. No alternative tools are mentioned, but the guidance is sufficient.

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 indicate read-only and idempotent. The description adds 'Read-only, free' and clarifies the current scope (official-only) and future workspace surface. No contradictions. Additional context about mutuality of filters and pagination adds transparency beyond annotations.

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

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

The description is two sentences, very concise, and front-loaded with the tool's purpose. Every word adds information, no fluff. Structure is clear and easy to parse.

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 5 optional parameters and no output schema, the description covers the main use case and filtering but does not describe the return format or fields of the response. It lacks information about default ordering or response structure, which could be important for an agent. However, schema descriptions are complete, so the gap is minor.

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

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

Schema coverage is 100% with clear descriptions. The description adds value by explaining the mutual exclusivity of only_official and only_workspace, and connects them to the in-app library lens. It also mentions pagination with limit/offset, reinforcing the schema.

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

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

The description clearly states it lists 'Heista-curated visual heists (style DNA + photography presets)' and mentions filtering scope. However, it does not explicitly differentiate from sibling tools like list_visual_style_presets, but the specificity of 'presets' and 'visual heists' provides reasonable clarity.

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 usage context: 'Read-only, free', filter with mutually exclusive only_workspace/only_official, and pagination. But it does not explicitly tell when to use this vs. other list tools, nor does it mention prerequisites or alternatives. The 'Official-only today' hint is helpful but limited.

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 indicate read-only, idempotent, and not open-world. The description adds 'Read-only, free' and explains the two preset categories and filtering. No contradictions, but no additional behavioral details like rate limits or auth.

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 very concise, with five short sentences each conveying essential information. No fluff, front-loaded with the core purpose, and well-structured.

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

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

The description explains the input and filtering but does not describe the output format or fields. Given no output schema, the return structure is omitted, which is a minor gap for a list tool.

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

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

Schema coverage is 100%, so each parameter is already documented. The description reinforces mutual exclusivity of only_workspace and only_official and gives a real-world analogy. This adds marginal value beyond the schema.

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

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

The description clearly states the tool lists visual style presets used in image-led Heists. It distinguishes between workspace and official categories, which differentiates it from sibling list tools like list_ad_formula_presets.

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 explains when to filter by workspace or official presets and notes pagination. However, it does not explicitly state when not to use this tool or compare it directly to similar list tools, leaving some inference needed.

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 indicate non-read-only and non-destructive, but the description adds valuable behavioral context: it costs a vision tag credit, it's not implemented, and invoking it returns a structured 'not implemented' envelope. This goes beyond annotations to set accurate 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 brief (three sentences) and front-loaded with the core purpose. The note about implementation status is necessary but slightly long. Overall efficient.

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 (not implemented, cost, alternatives), the description covers all critical aspects: purpose, use case, cost, implementation status, workaround. The lack of output schema is mitigated by the explicit description of the return envelope. Could mention idempotency or success/error codes, but it's largely 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 only parameter (asset_id) is well documented in the schema with format and provenance hints. The description adds no additional semantic detail beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly states 'Re-run the vision tagger on one brand asset,' which is a specific verb-resource combination. It also distinguishes the tool from siblings like add/list/delete by focusing on retagging. However, the 'Not implemented in MCP yet' note slightly muddles the immediate purpose, though it accurately reflects the current state.

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 explicitly states when to use ('when the original tagger run missed or misclassified an image'), provides a cost warning, and gives concrete alternatives ('re-run a brand scan with force_refresh=true' or 're-upload via REST POST path') since the tool is not yet implemented. This is excellent guidance.

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