Dali by Lulu

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

The annotation readOnlyHint: true already signals a safe read operation, and the description aligns by saying 'Parse'. The description adds that output is 'structured intent dimensions', providing some behavioral context beyond the annotation. However, it does not disclose aspects like response format, error behavior, or any side effects beyond what the annotation implies.

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 front-loads the core action and resource. Every word is meaningful with no redundancy. It is appropriately sized for the tool's simplicity.

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 tool with 2 parameters, no nested objects, and an output schema (though not shown), the description is minimally adequate. It conveys the basic purpose but lacks details on return values and the meaning of 'intent dimensions', which may be important for correct invocation. The agent would need to rely on the (unseen) output schema for 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 description coverage is 0%, and the description does not elaborate on the meaning or format of the 'prompt' parameter or the 'medium' parameter (which has a default). The agent gets no additional help on parameter values beyond the schema structure. Given the low coverage, the description should compensate but does not.

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

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

The description 'Parse a creative prompt into structured intent dimensions' clearly identifies the verb (Parse) and resource (creative prompt), and suggests a distinct analysis function compared to sibling tools like enhance_prompt or score_prompt. However, it does not explicitly distinguish itself from siblings, and the term 'intent dimensions' is vague without further context.

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. There are no statements about prerequisites, exclusions, or contextual triggers, leaving the agent to infer usage without support.

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

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

Annotations indicate readOnlyHint=true, and the description discloses that it returns score, missing patterns, and highest-ROI patterns, confirming a read-only operation. It adds useful context 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 concise with two clear, front-loaded sentences. Every sentence is informative, and there is no wasted 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?

Given the presence of an output schema, the description adequately covers the tool's behavior and returns. However, it lacks clarity on the generator format and doesn't address potential differences from sibling tools, 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 description coverage is 0%, and the description does not explain the two parameters (prompt, generator) beyond their names. It fails to compensate for the lack of schema documentation, providing no additional meaning or 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 clearly states the tool's purpose: comparing a prompt against community top scorers for a given generator. It specifies the outputs (score, missing patterns, highest-ROI patterns) and differentiates from sibling tools like 'score_prompt' by emphasizing community context.

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

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

The description implies usage for community comparison but doesn't explicitly state when not to use or mention alternatives. For instance, if only a score is needed, 'score_prompt' would be more appropriate. No exclusions or contextual advice are 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?

The description discloses that it is read-only (consistent with readOnlyHint), uses the V3 graph brain, and returns structured results (top patterns by type, enhancement unlocks, cross-model patterns). This adds value beyond annotations by explaining output contents and the community data source.

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 (two sentences) and front-loads the core question. However, the first sentence is phrased as a question rather than a direct statement, which slightly reduces clarity.

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

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

While the output schema exists to explain return values, the description lacks details on input semantics (parameters) and fails to provide enough context for an agent to correctly invoke the tool without additional information.

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 fails to explain the 'generator' and 'grade' parameters. It merely mentions 'this generator' without elaboration, leaving their meaning and constraints undocumented.

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

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

The description states it returns 'top patterns by type, enhancement unlocks, and cross-model universal patterns' for a given generator, which clearly identifies the tool's purpose. However, it doesn't define 'patterns' explicitly, which slightly reduces clarity. It distinguishes from siblings by focusing on pattern discovery rather than direct scoring or benchmarking.

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 its siblings (e.g., community_benchmark, enhance_prompt). There are no conditions, prerequisites, or exclusions mentioned, leaving the agent to infer usage 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 specific behavioral info beyond annotations: it returns version and changelog. Annotations already declare readOnlyHint=true, which aligns with the description. 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, no filler, front-loaded with purpose. Every sentence earns its place.

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

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

Given the tool's simplicity (no parameters, output schema exists), the description fully explains what it does and when to use it. No 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?

There are zero parameters, so the baseline is 4 per guidelines. The description adds no parameter information because none are needed.

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, with specific use cases. It distinguishes itself from sibling tools by focusing on version/change information.

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 says 'Check this whenever you want to know what tools are available, what changed in the latest release, or which version is running.' This provides clear usage context without explicit exclusions or alternatives, but the simple nature makes it adequate.

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; description adds behavioral context about mining graph and surfacing patterns, which is consistent and provides extra detail 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?

Very concise: three short paragraphs. First sentence states purpose, then brief method explanation, then bulleted use-cases. 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?

Tool has only 2 parameters, readOnly annotations, and output schema exists. Description covers purpose and usage thoroughly, leaving no 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%, so baseline 3. Description does not provide additional meaning beyond schema: 'generator' and 'starting_grade' are already described 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?

Description clearly states it shows reliable paths from bad grade to A for a generator, using Dali graph. It distinguishes from siblings by focusing on generator-specific enhancement paths.

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 lists three use-cases when to use, but does not mention when not to use or alternatives. Still clear enough for agent decision.

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 confirms no side effects by stating it returns a structured brief. The description adds transparency by explaining the return structure and the mandatory follow-up call, without contradicting annotations.

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

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

The description is concise and front-loaded with the core purpose. The important instruction about track_enhancement is included, but the wording could be slightly tightened without losing clarity.

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

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

The description covers the tool's purpose, workflow, and mandatory follow-up. With an output schema present, the return structure is partially covered, but the lack of parameter definitions leaves some completeness gap.

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

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

Schema coverage is 0%, but the description only mentions 'prompt + generator' without explaining what generator means or providing any parameter details. With two simple string inputs, the description should at least define each parameter clearly.

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 a rewrite brief for a given prompt and generator, and that the agent must write the enhanced prompt afterwards. It distinguishes itself from siblings like 'score_and_enhance' and 'track_enhancement' by specifying the workflow.

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 instructs the agent to call track_enhancement after writing the enhanced prompt, providing clear usage guidance. It does not explicitly contrast with alternatives, but the directive is strong enough for correct usage.

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. Description adds context about listing only 'medium and core strength' targets, which is useful behavioral detail. No pagination or rate limits mentioned, but acceptable for a simple list.

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, clearly states purpose and scope.

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 core purpose and filter criteria. Could clarify what 'medium and core strength' means, but output schema likely provides structure. No missing critical info.

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, so schema coverage is 100%. Baseline is 4. Description adds meaning by specifying the content filtered by strength.

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 all supported generation targets (providers + models) with specific strength filters. Distinguishes from siblings like suggest_generator.

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?

Implied usage for discovering available generators, but no explicit when-to-use or when-not-to-use guidance. Given no parameters and simple operation, adequate.

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 readOnlyHint annotation already indicates no destructive side effects. The description adds the contents of the report but does not disclose additional behavioral traits like response format or potential delays. No contradiction with annotations.

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

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

The description is a single, front-loaded sentence that conveys all essential information without waste. Every word earns its place.

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

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

Given no parameters and an existing output schema, the description adequately lists the report's contents. It implies personalization ('Your'), which is sufficient. Minor improvement could mention that no parameters are needed.

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, the schema covers everything. The description does not need to add parameter info. Baseline 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 clearly states the tool provides a Dali creative report covering scoring history, generator stats, recent scorers, and creative DNA. It identifies the resource and action (retrieve report) and distinguishes from sibling tools like score_prompt or enhance_prompt, which are about specific actions rather than an overview.

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 such as community_benchmark or creative_patterns. There is no indication of prerequisites or situations where this tool is preferred.

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

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

The description discloses the use of Memgraph for graph traversal, the criteria (A/B grade, same generator), and the output value (what those prompts did right). This adds context beyond the readOnlyHint annotation, though rate limits or auth requirements are not mentioned, which is acceptable for a read-only tool.

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, with a clear front-loaded purpose statement followed by bullet points for usage context. Every sentence adds value, and there is no redundant or wasted 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?

Given the tool's complexity (graph traversal, community scores), the description covers the core functionality and usage scenarios. An output schema exists, so return value details are not needed. Minor improvement could be explicit mention of output format, but not necessary.

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 the schema already documents both parameters. The description does not add additional syntax or constraints for the parameters beyond the implicit context (e.g., generator values like 'veo3, midjourney, flux'). This meets the baseline for high 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 it finds community A/B-grade prompts structurally similar to the user's input using graph traversal. It distinguishes itself from siblings like 'score_prompt' by focusing on similarity and high-scoring examples, providing a specific verb ('find') and resource ('neighbors').

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 guidelines are given: when the user's prompt scored C or below, when wanting to see community solutions, and when needing concrete A-grade examples. This clearly differentiates from tools like 'score_prompt' which evaluate scores, and 'enhance_prompt' which suggests improvements.

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 conditional behavior (score ≥70 vs <70) and states that a rewrite brief is returned when needed. Annotations already declare readOnlyHint=true, which is consistent with the read-only nature of scoring and returning information. The description adds value by explaining the threshold and the follow-up action, but could be more explicit about side effects (none).

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 well-structured. It front-loads the primary function, then provides usage guidance, conditional behavior, and follow-up instructions. 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?

Given the tool's conditional logic and integration with other tools, the description is complete. It explains what happens in both score ranges, says what to do after using the tool, and mentions the output schema (via the return description). No critical gaps remain for the agent to understand the tool's purpose and workflow.

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 schema description coverage at 0%, the description must compensate, but it does not describe the parameters. 'prompt' is implied by context, but 'generator' is not explained at all. The description adds minimal meaning beyond the schema, leaving the agent to guess the role of the second parameter.

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

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

The description clearly states the tool's function: 'Score a prompt and, if it needs work (score < 70), return the rewrite brief in ONE call.' It also distinguishes from siblings by mentioning it's preferred over separate calls to score_prompt and enhance_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 explicitly advises when to use this tool over alternatives: 'Preferred over calling score_prompt + enhance_prompt separately — saves a round-trip.' It also provides post-use instructions to call track_enhancement, giving clear context for the tool's role in a workflow.

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 aligns with readOnlyHint annotation (safe read). Adds value by detailing return structure (ScoreCard, dimensions, anti-patterns) and listing supported generators. 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 and output summary, followed by generator list. No redundant information; every sentence is necessary 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?

Sufficiently complete for a simple tool with 2 params and existing output schema. Covers purpose, output expectations, and generator support. Lacks details on dimension criteria, but output schema likely covers that.

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?

Despite 0% schema coverage, description explains prompt is scored for a generator, and lists supported generators (veo3, higgsfield, etc.). Adds meaning beyond bare schema, though prompt format details are omitted.

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 scores a prompt for a specific generation target, with output details including ScoreCard, letter grade, and breakdown. Distinguishes from siblings like score_and_enhance or score_variations by focusing solely on scoring.

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 usage when a prompt and target generator are available, but lacks explicit guidance on when to use versus alternatives like score_and_enhance. No mention of conditions or exclusions.

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

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

Discloses read-only behavior (consistent with readOnlyHint annotation) and explains output: 'returns a ranked list with per-dimension comparison so you can see exactly why one variant beats another.' Also mentions it doesn't consume credits, adding 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 short paragraphs, front-loaded with the core purpose. Every sentence is necessary, no redundant words. 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 the low parameter count (2), high schema coverage, and presence of an output schema, the description covers the use case, input constraints, and output value adequately. 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?

Schema coverage is 100%; the schema already describes both parameters adequately. The description reiterates the count constraint (2-8) and adds the concept of 'same creative intent' but does not provide substantial new meaning.

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

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

Description clearly states the tool's function: scoring and ranking prompt variations. It uses specific verbs ('Score', 'rank') and specifies the resource ('prompt variations for the same generator'), distinguishing it from sibling tools like score_prompt which likely handles single 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?

Explicitly tells when to use this tool: 'when you've drafted multiple versions of a prompt and want to pick the winner without burning generation credits.' Also implies not to use it for single prompts, providing clear 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?

Annotations already declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds behavioral context: it analyzes creative signals, matches within budget, and returns a ranked list. 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 concise paragraphs with front-loaded purpose. 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's moderate complexity, 2 parameters, full schema coverage, and presence of an output schema (so return values are documented elsewhere), the description is complete and provides sufficient context for an AI agent to use the tool correctly.

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

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

Schema coverage is 100% (both parameters described), so baseline is 3. The description adds extra meaning to the 'concept' parameter by listing examples (subject, style, mood, format, use case), which helps the agent provide richer input.

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 recommends the best generator based on concept and budget, analyzing creative signals and returning a ranked list. It distinguishes itself from siblings like list_generators (which likely just lists) and score_prompt (which scores 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?

Description implies usage before scoring an actual prompt ('to make an informed choice before scoring'), giving clear context. It doesn't explicitly state when not to use or list alternatives, but the purpose is well-defined enough for an AI agent.

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 claims the tool records data, implying a write operation, but annotations declare readOnlyHint=true. This is a direct contradiction, leading to severe misunderstanding about the tool's behavior.

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

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

The description is concise (three sentences), front-loaded with the main action, and well-structured. No superfluous 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?

Despite having an output schema, the description is incomplete due to the annotation contradiction and lack of parameter details. The readOnly vs write conflict undermines overall 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 description coverage is 0%, so the description must compensate. It only implies original_prompt and enhanced_prompt via 'enhancement pair' but does not explain the generator parameter. Minimal added meaning beyond parameter 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's purpose: 'Record an enhancement pair in the Dali graph brain.' It specifies the action (record) and resource, and distinguishes from siblings by indicating it is called after enhance_prompt or score_and_enhance.

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 when to use: 'Call this AFTER you write an enhanced prompt from enhance_prompt or score_and_enhance.' It also explains the benefit (graph learning, enriching creative_patterns and community_benchmark), providing clear context.

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