LEOR AI展台设计 Agent

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

Discloses that if already connected, the tool returns connected=true and no authorizationUrl, and that this is not a failure. Also explains behavior when forceReconnect=true. Since no annotations are provided, the description carries full burden and does 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?

The description is concise with no wasted words. It front-loads the main purpose and then provides key behavioral details and usage instructions in a compact, organized manner.

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 2 parameters, no output schema, and no annotations, the description covers the essential aspects: purpose, return value variations, and parameter usage. It lacks explicit output format but is otherwise complete for the tool's simplicity.

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 state is 'opaque' and usually left empty, and that forceReconnect should only be set in specific circumstances, going 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 'Connect or check the local LEOR account connection', specifying the action and resource. It distinguishes from the sibling tool 'get_leor_account_status' by covering both connect and check behaviors.

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 guidance on when to set forceReconnect (only after authRequired=true or explicit user request) and when not to (leave false for status checks). It also advises against inspecting local files, but does not explicitly compare with sibling tools like get_leor_account_status.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool modifies an image (mutation), but does not state whether the operation is destructive, reversible, requires authentication, or has rate limits. Missing transparency on side effects and safety profile.

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) and front-loaded with the main purpose. Every sentence contributes information. It is appropriately sized, though it could be slightly more structured with explicit sections.

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 basic purpose and usage context, but it is incomplete given the absence of annotations and output schema. It lacks behavioral details and does not explain return values or error cases. More information about side effects and output would make it more 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 input schema already describes all 4 parameters with 100% coverage. The description reinforces the meaning of 'prompt' with examples (e.g., '更科技感'), adding slight value. However, it does not explain how 'projectId', 'exhibitItemId', or 'sourceImageUrl' are used beyond their 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 action ('Refine an existing booth image') and the resource ('booth image'), and provides concrete examples of instructions like '更科技' and '加洽谈区'. It distinguishes from siblings by specifying it is for refining after selection, but does not explicitly contrast with 'evolve_booth_image_with_image'.

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 ('Use after the user selects a generated/reference image'), which is helpful. However, it does not specify when not to use this tool, nor does it mention alternative tools or prerequisites. More explicit guidance on when to use a sibling like 'evolve_booth_image_with_image' would improve clarity.

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 credit consumption, storage in project, output node creation, and polling requirement. No annotations exist, so description carries full burden and does well, though could detail polling mechanics or error 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?

Concise 4-sentence paragraph, front-loaded with purpose, no superfluous information. Each 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?

Covers purpose, constraints, and process adequately. Lacks mention of account prerequisites (e.g., connected LEOR account) and detailed return value explanation, but sibling tools fill polling 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 100%, so baseline is 3. Description adds minor context (image 'consumed immediately', prompt as 'clear change instruction') but doesn't significantly enhance beyond 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?

Clearly states it is a 'credit-consuming one-step image task' for modifying booth images. Differentiates from generic uploads and bulk hosting, and contrasts with sibling tools via the name and description.

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 when to use: when user sends an existing booth image and asks to modify. Specifies constraints (image type, size, clear instruction) and what it is not (generic upload). Lacks explicit comparison to similar sibling tools like 'evolve_booth_image'.

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?

With no annotations, the description fully discloses behavioral traits: it is credit-consuming, generates exactly one image per call, does not expose prompts, handles image assets via transport fields, and returns needsMoreBrief instead of spending credits when required fields are missing. 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 well-structured, starting with the core purpose and then providing detailed usage guidelines. However, it is quite long and contains multiple instructions that could be more streamlined. It is informative but not exceptionally concise.

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

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

Given the complexity of the tool (39 parameters, no output schema), the description covers the workflow thoroughly, including pre-generation checklist, handling of images and multiple images, and conditional returns. It lacks details about the success return format, which is a minor gap, but overall it provides sufficient context for correct invocation.

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

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

Schema description coverage is 100%, giving a baseline of 3. The description adds value by explaining the purpose of the 'prompt' parameter, clarifying transport fields (logoImageBase64, referenceImageBase64) are for local images, and specifying that boolean flags like logoAsked should be set after explicit user interaction. This goes 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?

The description clearly states the tool generates exactly one booth design image from a user brief. It distinguishes between generating new images versus searching/browsing inspiration, and explicitly says not to call for color-only phrases. This differentiates it from sibling tools like search_inspiration_gallery or other generate tools.

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

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

The description provides explicit guidance on when to use (user wants a new generated booth image) and when not to use (inspiration search, color-only phrases). It provides a detailed checklist of required and optional fields before first generation, instructions for handling multiple images, and explains the needsMoreBrief return for missing fields.

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?

No annotations are provided, so the description carries the burden. It mentions the tool returns 'needsMoreBrief' if sourceImageUrl is missing, which is a behavioral trait. However, it does not disclose what the tool returns on success, whether it modifies any state, or if it requires specific permissions. The behavior is partially transparent but lacks completeness.

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 that is front-loaded with the key purpose and includes both English and Chinese text. It is concise but the inclusion of Chinese '万物成展' may confuse some agents. It efficiently conveys the essential 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 there is no output schema and no annotations, the description provides adequate context by explaining the tool's purpose, usage, and key parameter behavior. It covers when to use, sources, and the needsMoreBrief condition. It lacks detail on return format and error handling beyond the missing URL case, but overall is fairly complete for a generation 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 the description adds context beyond the schema. For sourceImageUrl, it explains that for this tool it is typically an arbitrary non-booth visual and that it is required before spending credits. The prompt parameter is given a user-facing example. This adds meaningful guidance beyond the field 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: 'turn an arbitrary visual source... into an exhibition booth concept'. It gives concrete examples of good sources and explicitly distinguishes from sibling tools by stating when not to use this 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?

The description explicitly advises when to use (early-stage creative ideation) and when not to use (evolving existing booths: use evolve_booth_image; referencing LEOR gallery booths: use generate_booth_directions). It also specifies the exact nodeToolMode value, leaving no ambiguity.

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?

No annotations provided, so description carries full burden. It discloses credit consumption, one-step nature, file format/size limits, workflow (stores source, creates output node, returns task id), and that it's not generic upload. Slightly missing error handling or credit cost specifics, but overall transparent.

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 front-loaded with purpose and usage, then details. Every sentence adds value without being excessively verbose. Slightly long but justified.

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 return value (task id for polling) and workflow. Covers constraints, input format, and project handling. Could be more explicit about polling process, but sufficient for agent 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?

100% schema coverage ensures every parameter is described. Description adds value by explaining that imageBase64 is consumed immediately and not generic upload, and that projectName defaults to user agent project. Provides extra context 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?

The description clearly states it's a credit-consuming one-step image task for '万物成展' (everything to booth) when the user sends an image. It distinguishes from siblings by specifying that it accepts an image directly.

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 (user sends image wanting to use it for everything to booth) and when not to use (do not expose separate upload step, not a generic upload or bulk image hosting 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?

No annotations are provided, so the description carries the full burden. It fails to disclose behavioral traits like credit usage, prerequisites, or whether the operation is destructive. The mention of 'one-click' implies simplicity, but critical details are missing.

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 sentences, no wasted words. It could be slightly more structured (e.g., bullet points) but effectively communicates the core purpose and usage hint.

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 parameters and no output schema, the description is too brief. It omits return format, result handling, and integration details with LEOR. The schema partially compensates, but overall completeness is low for a generation 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 baseline is 3. The main description adds context about sourceImageUrl being the current booth image, which enhances understanding. However, it does not elaborate on other parameters beyond what the schema already 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 the tool generates an embossed/frosted-glass portfolio-style cover from the current booth image. It specifies the style and resource, distinguishing it from siblings like generate_minimal_poster or generate_glass_poster_with_image.

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 some guidance: 'one-click LEOR node tool', use with current booth image, and use nodeToolMode glass_poster for specific styles. However, it does not explicitly state when not to use or mention alternatives, such as generate_glass_poster_with_image for custom images.

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?

With no annotations, the description carries full burden. It discloses credit consumption, one-step nature, image size limit (25MB), format restrictions (JPG/PNG/WEBP), and that it returns a task id for polling. However, it doesn't specify error handling or rate limits.

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 (5 sentences), front-loaded with purpose, and structured logically: use case, process, constraints. 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 adequately explains the output is a task id for polling. It could be more explicit about how to use the task id, but it's sufficient for a tool that is part of a sequence (likely paired with get_generation_result).

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 value by explaining that imageBase64 is consumed immediately, projectName defaults to user agent project, and giving an example prompt. This enriches understanding 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 is a credit-consuming one-step image task for generating glass texture posters from booth images, with specific use cases (玻璃质感, premium archive cover, restrained brand atmosphere poster). It distinguishes from siblings by emphasizing it takes an image as input and returns a task 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?

Explicitly states when to use (user sends booth image and asks for glass texture etc.) and when not to use (not a generic upload or bulk image hosting tool). While it doesn't name specific alternative tools, the context is 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?

No annotations are provided, so the description must convey behavioral traits. It mentions 'One-click' implying simplicity, but does not disclose important details: that it consumes credits, requires a current booth image (as implied by 'from the current booth image'), or what happens on success/failure (e.g., needsMoreBrief if sourceImageUrl missing). The description lacks necessary transparency for an agent to fully understand the tool's behavior and side effects.

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

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

The description is very concise at two short sentences. It immediately states the tool type and primary function, then gives usage contexts. There is no redundant information. However, the first sentence ('One-click LEOR node tool') could be more informative. Overall, it is efficient and front-loaded.

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

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

Given the tool has 5 optional parameters, no output schema, and no annotations, the description is incomplete. It does not mention return value format, prerequisites (e.g., must have a current booth image), error conditions, or credit consumption. The tool integrates with LEOR but the description does not explain how projectId or exhibitItemId affect behavior. The short description leaves significant gaps in 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 coverage is 100%, so the baseline is 3. However, the description adds little beyond what the schema already provides. It introduces an undefined 'nodeToolMode' parameter that is not in the schema, which could confuse the agent. The description does not explain how parameters like prompt or sourceImageUrl interact or provide examples that clarify usage. Given the high schema coverage, the description fails to add meaningful value, and even introduces ambiguity.

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 generates a color/material board from the current booth image. The verb 'generate' and resource 'booth color/material board' are specific. It mentions 'One-click LEOR node tool' and 'from the current booth image', which helps differentiate from sibling 'generate_material_board_with_image' that likely accepts custom images. However, it does not explicitly contrast with siblings.

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

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

The description provides usage context by listing relevant Chinese terms (e.g., 材质看板, 色彩材质方案) and instructs to use exact nodeToolMode material_board. However, it does not explicitly state when to use this tool versus alternatives like generate_material_board_with_image, nor does it mention any prerequisites or limitations. Guidance is implied but not comprehensive.

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?

Given no annotations, the description discloses key behaviors: credit-consuming, one-step task, LEOR stores source image, creates output node, runs material_board, returns task id for polling. It also specifies image type/size limits (JPG/PNG/WEBP, 25MB) and indicates immediate consumption. Does not cover error states or auth requirements, but adequate.

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 plus a short note. It front-loads the main purpose and core constraints. Every sentence adds value with zero redundancy or filler.

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 image constraints, task nature, and returns task id for polling (no output schema exists). It mentions credit consumption and integration with LEOR. Could benefit from explaining the polling process (e.g., how to use get_generation_result), but is sufficient for agent 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 description coverage is 100%, so baseline is 3. The description reinforces image format/size constraints already present in schema. It adds context about how parameters are used (e.g., LEOR stores source image, returns task id), but does not provide additional meaning beyond what schema already conveys.

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 ('generate material board'), resource ('from a booth image'), and scope ('one-step image task'). It distinguishes from the sibling 'generate_material_board' by explicitly mentioning image input and specifying 'not a generic upload or bulk image hosting 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?

The description explicitly states when to use this tool: 'when the user sends a booth image and asks for 材质看板, color/material board, or proposal material direction.' It also clarifies what it is not ('not a generic upload'), but does not directly compare with alternatives like 'generate_material_board' (without image). Clear context for usage is 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?

No annotations provided, so description carries full burden. It discloses that missing sourceImageUrl returns 'needsMoreBrief', implying credit check, and notes it's a one-click node tool. 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 concise, front-loaded with the tool's essence, and 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?

The description explains core behavior and the 'needsMoreBrief' case, but lacks details on return format or output nature. Still adequate given the tool's simplicity and 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 covers 100% of parameters with descriptions. The description adds minimal extra context (e.g., sample prompt text) but does not substantially improve understanding beyond what the schema already 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 the tool generates a minimal poster from the current booth image, and differentiates from siblings like glass_poster and trend_poster by specifying 'minimal' and referencing exact nodeToolMode.

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 examples (简约海报, PPT cover, etc.) and implies it uses the current booth image, but does not explicitly contrast with sibling "with_image" variants or state when not 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool consumes credit, stores the source image in the user agent project, creates an output node, runs minimal_poster, and returns a task id. It also specifies input constraints (one image, JPG/PNG/WEBP, max 25MB). It does not mention authorization or destructive behavior, but it is sufficiently transparent.

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 at two sentences. The first sentence states purpose and triggers, the second describes the process and constraints. No unnecessary 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 complexity of 5 parameters and no output schema, the description covers the essential context: purpose, when to use, process, constraints, and differentiators. It mentions the return of a task id for polling, which is adequate; more detail on the return format would be beneficial 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 description coverage is 100%, so the baseline is 3. The description adds value by explaining that imageBase64 is immediately consumed and that projectName defaults to the user agent project. It also clarifies the purpose of prompt and fileName in the context of poster generation.

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 is a 'one-step image task' that generates a poster from a booth image, and it explicitly lists the use cases: 简约海报, PPT cover, or restrained proposal cover. It also distinguishes from generic upload or bulk hosting tools.

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

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

The description explicitly states when to use it: 'when the user sends a booth image and asks for 简约海报, PPT cover, or restrained proposal cover.' It also clarifies what it is not: 'Not a generic upload or bulk image hosting 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?

No annotations provided; description states it is a 'one-click' tool but fails to disclose behavior beyond generation, such as output format, side effects, or what happens if sourceImageUrl is missing (schema notes needsMoreBrief but description omits it).

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

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

Two sentences plus a phrase, entirely front-loaded with key action and purpose. No redundant 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?

No output schema and no annotations; description does not explain what a 3x3 storyboard is, the expected output format, or how to handle results. Insufficient for a 5-parameter tool.

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

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

Schema covers all 5 parameters with descriptions; description adds value by specifying 'Use exact nodeToolMode storyboard' and giving an example for prompt, and clarifying sourceImageUrl usage. Exceeds baseline 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?

Specifies verb 'generate', resource 'storyboard', and context 'from the current booth image'. Mentions 3x3 grid and use cases, clearly distinguishing it from siblings like generate_view_angle or generate_material_board.

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?

Suggests using this for storyboard purposes like 游览动线, but does not explicitly exclude alternatives or mention the sibling generate_storyboard_with_image. Usage context is implied but not fully delineated.

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?

No annotations provided, so description carries full burden. It discloses credit consumption, one-step nature, internal process (stores in project, creates output node), return of task id for polling, and file format/size limits. Lacks mention of whether it is destructive, but generation context implies non-destructive.

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 front-loading purpose and usage, with no wasted words. Every 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?

Given no output schema, description adequately covers return value (task id for polling), input constraints, internal steps, and use cases. Could mention if multiple calls allowed or concurrency limits.

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 value beyond schema: imageBase64 is 'consumed immediately and not a generic upload', prompt and fileName get example values, projectId and projectName get context about LEOR project defaults.

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?

Specifically states it is a 'credit-consuming one-step image task' for booth images and storyboard use cases. Clearly distinguishes from sibling tools like generate_storyboard (without image) and bulk upload tools.

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

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

Explicitly tells when to use: 'when the user sends a booth image and asks for 展位分镜, 游览动线, multi-angle storyboard, or proposal walkthrough.' Also clearly states what it is not: 'Not a generic upload or bulk image hosting 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?

No annotations are provided, so the description must bear full behavioral disclosure. It only mentions 'one-click' and generating a poster. It does not disclose whether the tool modifies existing data, requires authentication, has rate limits, or returns output details. The schema hint about returning needsMoreBrief is useful but insufficient for a complete behavioral picture.

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 long, front-loaded with 'One-click LEOR node tool.' It is reasonably concise but could be tightened by removing redundant phrasing like 'Use exact nodeToolMode trend_poster for...' which repeats the tool name implicitly. Overall, it wastes minimal 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?

Given the 5-parameter complexity, lack of output schema, and no annotations, the description provides adequate but incomplete context. It does not explain the generation process, what the result looks like, or how to use the output. The schema parameter descriptions compensate somewhat, but overall completeness is average.

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 each parameter has a detailed description (e.g., sourceImageUrl explains its required context and error behavior). The tool description adds little extra semantic value beyond the schema, only mentioning the use of nodeToolMode which is not a parameter in the schema, causing potential confusion.

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 generates a high-impact commercial proposal poster from the current booth image. It specifies the use case for trend_poster mode. However, it does not differentiate from sibling poster tools like generate_glass_poster or generate_minimal_poster, which share similar purposes.

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 exact nodeToolMode trend_poster for specific styles like KV-like booth promotion or social sharing. It implies one-click usage but does not explicitly state when not to use this tool or compare with alternatives like the _with_image variant. No prerequisites or exclusions 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?

With no annotations provided, the description carries full burden. It discloses that the task consumes credits, is one-step, stores the source image in the user agent project, creates an output node, runs trend_poster, and returns a task id for polling. It also specifies input format (JPG/PNG/WEBP) and size limit (25MB). Missing details about failure behavior or permissions, but adequate for the use case.

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 (~150 words), front-loads the purpose and usage context, and provides essential workflow steps without redundancies. Every sentence adds value, and the structure is 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 5 parameters, no output schema, and no annotations, the description covers the tool's purpose, input constraints, and output (task id). It omits details like error handling or timeout, but for a return-task-id polling pattern, this is sufficient. The workflow is adequately explained.

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% (all 5 parameters described). The description adds context: imageBase64 is 'consumed immediately,' fileName is optional, and prompt includes an example instruction. It reinforces that this is not a generic upload. However, the schema already provides basic descriptions; the extra context is useful but not extensive. Baseline is 3, plus 1 for added 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 is a 'credit-consuming one-step image task' for generating trend posters from booth images. It lists specific use cases ('潮流海报, KV-like booth promotion, or energetic proposal poster') and explains the workflow (stores image, creates output node, runs trend_poster, returns task id). This distinguishes it from generic upload tools and other sibling tools.

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

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

The description explicitly says 'Use when the user sends a booth image and asks for...' and warns 'Not a generic upload or bulk image hosting tool.' This provides clear when-to-use guidance, but it does not compare to sibling tools like generate_trend_poster (without image) or differentiate among similar poster-generating siblings.

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?

Without annotations, the description covers credit consumption, required source image, default angle handling, legacy parameter snapping, and polling step. This is sufficient for basic behavioral disclosure, though it doesn't detail exact side effects or resource creation.

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

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

The description is reasonably concise given the complexity, packing useful details about synonyms, defaults, and fallbacks into a few sentences. Slightly verbose with legacy parameter explanations, but still 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 no output schema, the description explains polling with get_generation_result and covers parameter usage well. It lacks explicit info on generation time or exact output format, but the polling hint compensates. Overall adequate for the tool's 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?

Although schema coverage is 100%, the description adds value by listing valid anglePreset values, specifying the default, clarifying legacy fallback snapping, and flagging sourceImageUrl as functionally required despite schema marking it optional. This goes 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 generates one of 14 preset camera angles from an existing booth image, with a user-facing name and synonym handling. The title 'Rotate Booth Viewpoint' aligns well, and the tool is distinct from siblings like evolve_booth_image.

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 credit consumption, required source image, and default angle selection, but lacks explicit comparison to sibling tools or when-not-to-use scenarios. It does provide implicit guidance via polling instructions.

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?

No annotations exist, so the description carries full burden. It reveals that the progress number is approximate and may jump, and to prefer message/status stage over exact percentages. This exceeds basic expectations for a fetch 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 four sentences, front-loaded with the main action. It efficiently conveys polling behavior and return values. Minor redundancy could be trimmed, but overall concise.

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 return values (fullResUrl, image URLs, ids) and polling behavior. It covers the progress quirk and user-facing recommendations. Lacks detail on error responses, but sufficient for agent invocation.

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

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

Schema coverage is 100% with a single 'taskId' parameter described as 'LEOR task id.' The description adds no further meaning to the parameter itself, only context about the result. 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 the tool fetches task status and final result from LEOR by task id, with specific outcomes like fullResUrl and ids. This verb+resource combination distinguishes it from sibling tools that are generation or connection tools.

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

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

The description explicitly says to poll after generation until done or error, and advises preferring message/status stage in user-facing replies. While it doesn't explicitly state when not to use it, the context 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?

Discloses that URLs are watermarked and that downloadUrl is for specific scenarios; no annotations exist, so the description carries the full burden and covers key behavioral traits adequately.

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 moderately sized with each sentence adding value; front-loaded with purpose. Could be slightly more concise but not wasteful.

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 and high schema coverage, the description sufficiently explains the returned URLs and appropriate usage flows, though could briefly mention other potential return fields.

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

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

Schema coverage is 100% and the description adds value by explaining the alias relationship and preference for galleryItemId over itemId, exceeding 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?

The description clearly states the tool retrieves one LEOR inspiration gallery item with safe preview metadata after a user selects a reference, distinguishing it from the sibling search tool and generation tools.

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

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

Provides explicit guidance on when to use previewUrl vs downloadUrl and how to use galleryItemId for generation, but does not explicitly state when not to use this tool (e.g., when raw originals are 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?

No annotations provided, so description fully covers behavior: free read-only, no credits spent, no tokens/credentials exposed. Adequate for a simple status 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?

Three sentences, front-loaded with 'Free read-only tool'. No wasted words, clear structure.

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 zero-parameter tool with no output schema, description sufficiently explains purpose and behavior. Lack of exact output format is acceptable for a simple status check.

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?

Zero parameters, so baseline is 4. Description adds meaning beyond empty schema by explaining what the tool retrieves.

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 checks LEOR account status and credit balance, with verb 'Check'. It distinguishes from sibling tools like connect_leor_account and preparation/generation tools.

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

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

Explicitly mentions use cases: user asks about credits, account status, or checking enough credits before generation. Does not explicitly state when not to use, but context is 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?

No annotations provided, so description fully carries behavioral disclosure. It explains that the gateway suppresses repeated reminders for the same noticeId, giving important context about idempotency.

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, each with distinct purpose. Front-loaded with tool's action and scope. No unnecessary 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?

Missing output schema, and description does not explain what the tool returns. For a status check, the return format or example 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 covers 100% of parameters. Description adds value by explaining forceShow is for diagnostics or when user asks what changed, and that the other two optional parameters suppress reminders.

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 checks LEOR Agent Gateway version, playbook version, and latest update notice. This distinguishes it from sibling tools like connect_leor_account or generate_ tools.

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

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

Explicitly specifies when to use: once at session start, after reconnecting, or when behavior seems stale. Also warns not to manually repeat the same update notice.

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?

No annotations provided, so description carries full burden. It clearly states it never spends credits, returns specific fields (readyToGenerate, etc.), and requires explicit user confirmation before credits are spent. Lacks some details on expected behavior edge cases but 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?

Concise, front-loaded with purpose, and includes key guidance. Could be slightly more structured but 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 40 parameters, no output schema, and no annotations, the description adequately explains tool role, usage, and return values. Some depth on output format missing but not critical.

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 detailed descriptions. Description does not add parameter-specific info beyond what schema provides. 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?

Clearly states it is a free preflight checker for LEOR generation tools, distinguishes from paid siblings by saying it never spends credits and returns readiness indicators.

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 when to use (user wants AI generation but brief may be incomplete), gives detailed workflow for first-round booth generation, and links to paid tool via 'intendedTool'.

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?

No annotations provided, but description discloses search behavior and empty result logic. Could explicitly state read-only nature, but context implies it. 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?

Description is well-structured with core action first, then conditions and guidance. Minor redundancy but overall efficient for the 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?

Covers triggers, parameter nuances, and error recovery. Lacks output format description, but acceptable given search nature. Adequately complete for a search tool with 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%, but description adds significant value: explains query vs industry usage with examples (e.g., 建材展, 瓷砖). Provides decision rules for parameter selection.

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

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

Clearly states it searches 'public approved LEOR inspiration gallery images'. Provides specific verbs and resource. Distinguishes from siblings (generation tools) by 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?

Explicitly lists triggers (vague user, references, Chinese terms) and clarifies follow-up colors still mean gallery search. Advises handling empty searches with related words. No ambiguity.

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