Dali by Lulu

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

Annotations declare readOnlyHint=true, and description 'parse' is consistent. However, description adds no extra behavioral context beyond what annotations convey.

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

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

Single sentence, front-loaded, 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?

Minimally adequate given output schema existence and simple parameters. Lacks detail on 'medium' parameter usage.

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

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

Schema has 0% coverage; description only hints at 'prompt' as input. Optional parameter 'medium' with default 'auto' is unexplained.

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

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

The description uses a specific verb 'parse' and resource 'creative prompt' with a clear outcome 'structured intent dimensions'. It distinguishes from siblings like 'enhance_prompt' or 'score_prompt'.

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

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

No guidance on when to use this tool versus alternatives like 'score_creative' or 'enhance_prompt'. No context or exclusions provided.

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=true, which aligns with the analysis nature. The description goes beyond by detailing outputs (formula, benchmark, analyzed, saved) and conditions (email supplied). 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 front-loaded with a clear purpose and structured into paragraphs. It is informative but slightly verbose in the middle section; still earns its space.

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 inputs, process, outputs, and conditions comprehensively. Output schema existence complements the description; no missing aspects.

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

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

With 0% schema description coverage, the description fully explains each parameter: csv (ads export with specific columns), email (for saving/emailing), category (for benchmark). Adds meaning beyond names.

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 identifies winning ad formulas from user data. It uses specific verbs ('Find', 'analyzes') and distinguishes from sibling tools like score_creative by requiring a CSV export.

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: when you have an ads CSV and want to uncover winning attributes. It hints at alternatives (cold-start fallback) but does not explicitly exclude other tools.

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

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

Annotations already declare `readOnlyHint: true`, confirming no side effects. The description adds context about what the tool returns (score, missing patterns, ROI patterns), which goes beyond annotations. However, it does not disclose other behavioral traits like auth requirements, rate limits, or the nature of the comparison. With annotations covering the safety profile, the description adds moderate value.

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

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

The description is two sentences long (78 words total), front-loads the core purpose in the first sentence, and wastes no words. Every sentence adds value—purpose then return values. This is an exemplary model of conciseness.

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

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

The tool has two required string parameters, is read-only, and has an output schema (not shown). The description covers the return values (score, missing patterns, ROI patterns) adequately. It does not elaborate on what 'community top scorers' means or how the comparison works, but given the output schema likely provides that information, the description is sufficiently complete for the complexity level.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by mentioning 'your prompt' and 'this generator', implying that `prompt` is the user's prompt and `generator` is the generator name. This adds essential meaning beyond the schema, but lacks further detail like format or constraints. Given the baseline of 4 for zero params, this is adequate.

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: 'Compare your prompt against community top scorers for this generator.' It specifies the action (compare), the resource (prompt vs community top scorers), and mentions the return values (score, missing patterns, ROI patterns). This distinguishes it from sibling tools like 'score_prompt' which likely only returns a score, or 'enhance_prompt' which modifies the prompt.

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

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

The description provides clear context on when to use the tool: when you want to compare your prompt to community benchmarks for a specific generator. However, it does not explicitly exclude scenarios or name alternatives, which would warrant a 5. The implicit guidance is sufficient for an agent to infer usage, but lacks explicit prohibition or sibling differentiation.

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, so the description correctly avoids repeating that. It adds context about the underlying 'V3 graph brain (Supabase PostgreSQL)' and that every scored prompt contributes, which is useful but doesn't cover potential performance or data freshness characteristics.

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

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

The description is three sentences, front-loaded with the main question, and no extraneous text. However, it would be improved by integrating parameter details, which would not add significant length.

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

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

While the tool has an output schema (so return values are not needed), the description fails to cover the input parameters and usage context, making the tool incomplete for an agent to select and invoke without external knowledge. The description is adequate for a human who knows the parameters but not for an autonomous agent.

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

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

Schema description coverage is 0%, and the description provides no explanation of the two parameters (generator, grade). The word 'high-grade' hints at the grade parameter, but the description does not explicitly define how to use grade or confirm that generator is required. This is a critical gap for correct invocation.

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

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

The description clearly states it's a community graph that returns top patterns by type, enhancement unlocks, and cross-model universal patterns, distinguishing it from siblings like score_prompt or enhance_prompt. However, it uses a rhetorical phrase rather than a direct imperative verb like 'Get' or 'List', slightly reducing 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?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for discovering high-grade patterns for a generator, but never discusses when-not-to-use or mentions sibling tools like analyze_winning_formula.

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 readOnlyHint=true, and the description adds that it returns version and changelog, which is consistent and goes beyond annotations by clarifying the type of information returned.

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, no unnecessary 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 no-parameter, read-only tool with an output schema, the description fully covers purpose and usage scenarios.

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 zero parameters and 100% schema coverage, the description does not need to explain parameters. Baseline of 4 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 explicitly states it provides the current Dali MCP version and changelog, distinguishing it from all sibling tools which perform other functions like analyzing intent or scoring prompts.

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?

Clearly specifies when to use ('whenever you want to know what tools are available, what changed, or which version is running'). No alternatives to exclude are needed given the tool's uniqueness.

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 that the tool mines the Dali graph and surfaces patterns, which is a read-only analysis. This aligns with the annotation 'readOnlyHint: true'. There is no contradiction, and the description adds valuable behavioral context beyond the annotation.

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 concise, with three distinct sections: a clear main sentence, a brief explanation of method, and a bulleted list of usage scenarios. It is front-loaded with the core purpose and contains no redundant information.

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

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

The description explains the input and the general operation (mining the Dali graph for patterns). Since there is an output schema (not shown), the description does not need to detail return values. It is sufficiently complete for a pattern analysis tool, though it could mention the output format briefly.

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

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

Schema description coverage is 100%, with both 'generator' and 'starting_grade' already documented. The description reinforces these by explaining they are used to find enhancement pairs and patterns. While the description doesn't add much beyond the schema, it provides context that ties parameters to the tool's purpose.

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: 'Show the most reliable path from a bad grade to an A on this generator.' It specifies the action (mine and surface patterns) and the resource (Dali graph). It differentiates from siblings like 'enhance_prompt' by focusing on analysis rather than direct enhancement.

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 lists three use cases under 'Use this when:' (e.g., low score and unsure what to fix, know which improvements matter most). This provides clear guidance on when to use. It does not explicitly mention when not to use, but the positive guidance is strong and implicitly contrasts with other tools.

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

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

The annotation indicates readOnlyHint: true, which is consistent with the tool being read-only (it returns a brief). The description adds behavioral context by detailing the return structure (score_before, rewrite_brief, llm_instructions) and explaining how the category parameter upgrades the brief with conversion data. This adds value beyond the annotation.

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 concise and front-loaded, starting with the core purpose and return value. The second paragraph covers the optional parameter and a critical instruction. It could be slightly more concise but effectively communicates all necessary 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?

Given the presence of an output schema (not shown but implied), the description explains the return fields and the effect of the category parameter. It also includes the important post-call requirement. For a tool with 3 parameters and a clear output, this is sufficiently complete.

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

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

Schema coverage is 0%, so the description needs to explain parameters. It does explain the category parameter's purpose and optionality, but does not elaborate on prompt or generator beyond their names. Since these are self-explanatory, the description adds moderate value.

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: 'Get a rewrite brief for this prompt + generator. YOU write the enhanced prompt from the brief.' It uses a specific verb ('get a rewrite brief') and resource ('prompt + generator'), and distinguishes itself from sibling tools like track_enhancement.

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 when-to-use context: to obtain a rewrite brief. It also includes critical usage instructions, such as the mandatory call to track_enhancement after writing the enhanced prompt, and explains the optional category parameter's effect. It does not explicitly state when not to use it but gives sufficient 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?

Descriptions adds specific content beyond annotation: it lists generators with 'medium and core strength'. Annotation already indicates readOnlyHint=true, which is consistent. 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?

Single sentence, no wasted words. Front-loaded with action and object.

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 parameterless listing tool with output schema present, description is complete. It explains what is listed and adds specificity about 'medium and core strength'.

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?

No parameters in schema, so description cannot add parameter-specific meaning. Baseline 4 for 0 parameters; description appropriately focuses on tool purpose.

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 'list' verb and specific resource 'supported generation targets (providers + models)' with attributes 'medium and core strength'. Distinguishes from sibling 'suggest_generator' which suggests rather than lists.

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?

Implies listing all available options, but no explicit guidance on when to use vs alternatives like 'suggest_generator'. Context suggests use for getting all supported generators.

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 specific behavioral details beyond the readOnlyHint annotation, such as including scoring history, generator stats, recent scorers, and creative DNA. This helps the agent understand what data to expect.

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, concise sentence that immediately conveys the tool's purpose and contents. No extraneous information is present.

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

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

Given the tool has no parameters and an output schema exists, the description sufficiently covers the report's scope. It could be more explicit about scope (e.g., 'for the current user'), but overall it is complete for a simple read-only report.

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 the description does not need to explain parameter semantics. It adds value by outlining the report's contents, which compensates for the lack of parameters.

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

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

The description clearly identifies the tool as a 'creative report' and lists its contents (scoring history, generator stats, recent scorers, creative DNA), making the purpose understandable. However, it lacks an explicit verb like 'get' or 'retrieve' to indicate the action performed.

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

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

No guidance is provided on when to use this tool versus alternatives. Siblings like score_creative, community_benchmark, or creative_patterns could overlap, but the description does not differentiate or state when to choose 'my_story'.

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 annotation indicates readOnlyHint=true, and the description does not contradict this. It discloses the method (graph traversal, pattern matching), the scoring threshold (A or B), and what it returns (what those prompts did right). This adds meaningful behavioral context beyond the annotation.

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 highly concise and well-structured. It starts with a clear one-line summary, then a paragraph explaining the method, followed by a bullet-point list of use cases. Every sentence provides valuable information without redundancy or unnecessary detail.

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 that an output schema exists, the description does not need to detail return values. It covers purpose, method, and usage guidelines thoroughly. The tool has only two parameters, and the description provides sufficient context for an agent to decide when to invoke it. Minor improvement could be a brief note about the output format if not covered by the schema.

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

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

Both parameters are documented in the schema (100% coverage). The description adds context by explaining that it looks for prompts scored A or B on the same generator, which reinforces the importance of the 'generator' parameter. It adds value by tying the parameters to the tool's purpose.

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 finds community A/B-grade prompts structurally similar to the input, using graph traversal (Memgraph). It distinguishes from siblings like 'creative_patterns' and 'community_benchmark' by focusing on finding similar high-scoring prompts with concrete examples, but could explicitly contrast with these siblings for higher 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 includes a 'Use this when:' list with three specific scenarios (prompt scored C or below, want community solutions, need concrete A-grade examples). This provides clear context for when to use the tool, but does not mention when not to use it or suggest alternative tools for different scenarios.

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 details the internal mechanics (Vertex embedding vs winner corpus, Gemini vision vs category priors, defect gate) and explains the meaning of scores and other outputs. This goes beyond the readOnlyHint annotation, which is consistent with the descriptive analysis.

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 well-structured with a clear header, bullet points for return fields, and usage examples. It is relatively lengthy but every sentence adds value, and the structure aids readability.

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 all return fields mentioned, including edge cases (empty category), and provides context on how the tool works. Given the complexity and the presence of an output schema, the description is sufficiently 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 description explains the category parameter with examples and the effect of leaving it empty, adding significant value beyond the schema. The image_url parameter is self-explanatory, and overall the description compensates for the 0% schema description 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 scores an ad image for conversion, using visual similarity to proven winners. It specifies the resource (ad image) and the action (score), and distinguishes from sibling tools like score_prompt which scores text prompts.

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 guidance on when to use the tool ('before you spend', on generated images, mockups, or any ad about to run) and offers concrete examples for the category parameter. It lacks explicit comparison with all siblings, but the context 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 declare readOnlyHint=true, so the tool is known to be read-only. The description adds behavioral context: the model must visually inspect the image and fill parameters, and Dali scores against winners. It also describes the output. No contradictions, but no mention of rate limits or prerequisites, so a 4 is appropriate.

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 well-structured: first paragraph for purpose, second for parameters, third for output. However, it is somewhat lengthy; each sentence is justified given the complexity, but it could be slightly more concise. Still, it's front-loaded with key information.

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

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

Given the tool has 10 parameters and the description explains all of them plus the output, it is fairly complete. However, there is a slight inconsistency: the description says defects should be '[] if clean' but schema default is null. Also, it doesn't specify if all parameters must be filled or what happens with defaults. Still, it provides enough for an agent to 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?

The input schema has 0% coverage (no descriptions in schema), but the description provides detailed meanings and allowed values for each parameter (e.g., category: 'vertical: beauty, wellness, supplements, fitness, food, apparel, tech, pets'). This fully compensates for the lack of 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's purpose: 'Score an ad creative YOU are looking at... against the winning corpus'. It specifies the action (score), resource (ad creative), and method (by filling in visual attributes). It also distinguishes itself from the sibling tool 'score_creative' by noting that the sibling is for fetchable 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?

Explicit usage guidance is provided: 'Use this when the user shares an image in the conversation' and 'For a fetchable image URL, prefer score_creative'. This clearly indicates 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 already mark readOnlyHint=true, and the description adds valuable behavioral context: it uses a 'fast heuristic keyword analyzer', returns different outputs based on score thresholds, and upgrades the brief when conversion priors exist. No contradictions with annotations.

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

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

The description is well-structured: first line states core action, then details two paths, then describes return values, and finally explains optional parameter. It is slightly verbose but each sentence adds value. Could be trimmed by condensing the ScoreCard description.

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

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

Given the tool's complexity (scoring, conditional enhancement, optional category), the description covers the main workflow and return types (ScoreCard, enhancement_brief). With no output schema, it provides a good outline of the response. However, it lacks error handling details and doesn't specify what happens if an invalid generator is provided.

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 3 parameters with 0% description coverage, but the description fully explains each parameter: 'prompt' is the text to score, 'generator' is the target (with examples like veo3, midjourney), and 'category' is the ad vertical that upgrades the brief. This compensates completely for the missing schema descriptions.

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

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

The description opens with a clear verb+resource: 'Score a prompt for a generation target (0–100) and, if it's weak, return the rewrite brief — in ONE call.' It differentiates from siblings like 'enhance_prompt' by explaining its unique one-call workflow and conditional return of a rewrite brief. Also mentions optional category parameter for conversion-justified upgrades.

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 one-call advantage over multiple calls and instructs the agent: if score < 70, 'Write the enhanced prompt from the brief, then call track_enhancement'. Also explains when to use the optional 'category' parameter. However, it does not explicitly state when NOT to use this tool versus alternatives like 'enhance_prompt' or 'score_creative'.

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, so description isn't needed for safety. Description adds that output is a ranked list with per-dimension comparison, which is useful behavioral 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?

Three sentences with no wasted words. Front-loaded with action, then use case, then output. Efficient 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?

Given output schema exists, description covers purpose, use case, and output type completely. No gaps for a 2-param comparison 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%, baseline 3. Description adds meaning: prompts require 'same creative intent, different wording', generator is 'target generator'. This adds clarity beyond 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?

Description clearly states 'Score 2–8 prompt variations' and 'rank them best-to-worst', providing specific verb and resource. Distinguishes from sibling tools like score_prompt (single prompt) and analyze_intent (intent analysis).

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 when to use ('drafted multiple versions...want to pick the winner') and hints at when not to use (single prompts) by mentioning 2–8 variants. Lacks explicit alternatives to other tools but provides strong context.

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

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

The description adds behavioral context beyond the readOnlyHint annotation: it 'analyzes the concept's creative signals... and matches them to generators within your budget', confirming a read-only analysis. 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 concise paragraphs with a clear front-loaded purpose statement and supporting details. Every sentence adds value with 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?

Given the tool has an output schema (indicated by context signals), the description sufficiently covers inputs and behavior. It could mention what happens if no generator fits the budget, but overall it's fairly complete for a recommendation tool.

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

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

Schema description coverage is 100%, so the parameters are already well-documented. The description reinforces that 'concept' includes subject, style, mood, format, use case and that 'budget_usd_max' is per generation, but adds no new semantics 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 'recommend[s] the best generator for your creative concept and per-generation budget', with a specific verb (recommend) and resource (generator) that distinguishes it from sibling tools like 'list_generators' or 'score_prompt'.

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 that the tool analyzes creative signals and matches to generators within budget, returning a ranked list for informed choice before scoring. While it provides clear context for when to use, it lacks explicit guidance on when not to use or direct 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?

The description says 'Record an enhancement pair' implying a write operation, but annotations declare readOnlyHint=true, which indicates read-only. This is a direct contradiction, warranting a score of 1. The description fails to disclose additional behavioral traits beyond the contradictory 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 three sentences, front-loaded with the core action, then timing, then return info. It is concise with no wasted words. However, the contradiction slightly mars its effectiveness.

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

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

With an output schema present, return values are documented. However, the description omits explanation of the 'generator' parameter and contradicts annotations, leaving a gap in behavioral expectations. The tool has 3 required params but the description does not fully contextualize them.

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

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

Schema description coverage is 0%, so the description must fully explain the parameters. It mentions 'original_prompt' and 'enhanced_prompt' implicitly but does not define them or the required 'generator' parameter. It adds minimal meaning beyond the parameter names, failing to compensate for the lack of schema documentation.

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

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

The description clearly states the tool's verb 'Record an enhancement pair' and the resource 'in the Dali graph brain'. It specifies the purpose (learning from improvements to enrich creative_patterns and community_benchmark) and distinguishes from sibling tools like score_prompt and enhance_prompt by indicating it should be called after them.

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 says 'Call this AFTER you write an enhanced prompt from score_prompt's brief or enhance_prompt.' This provides clear timing context. It does not list exclusions or alternatives, but the when-to-use guidance is strong.

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