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

There are no annotations, so the description carries the full burden. It discloses key behaviors: line-by-line reading, interval between tasks, and resume via progress recorded in .bgen_progress.json. However, it does not disclose error handling, output behavior, or side effects of execution, which are relevant for a batch tool with no annotation safety hints.

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

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

The description is compact and well-structured: a one-line summary followed by a clearly formatted parameter list. Every sentence adds value, including defaults and task-specific constraints. No filler or redundancy.

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

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

For a batch engine with 6 parameters and multiple task types, the description is largely complete: it covers purpose, parameters, file formats, and resume behavior. The output schema exists, so return values need not be explained. It lacks details on failure handling and sequential execution, but nothing critical is missing for invoking the tool.

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

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

Schema description coverage is 0%, and the description fully compensates. It explains every parameter, including task types with per-line payload formats (e.g., g-pic/i-pic expect one prompt per line, p-pic expects 'prompt | reference path'), defaults for interval/size/n, and conditional applicability of size/n. This goes well beyond the bare 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 opens with a specific verb+resource: '通用批量引擎：从 .txt/.md 文件逐行读取任务并批量执行' (generic batch engine reading tasks line by line from .txt/.md files and executing them in batch). It also mentions interval and resume support, which clearly distinguishes it from the sibling single-task tools like g-pic or r-vid.

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 clearly establishes when to use this tool: when you need to batch-execute tasks listed in a file, with optional interval and resume. It does not explicitly name alternatives or state when not to use the siblings, but the batch-engine framing and the task-type parameter give clear usage context. Without explicit exclusions, a 4 is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well: it reveals automatic size adaptation when the API does not support the requested dimensions, the default provider resolution order (GEN_IMAGE_ADAPTER → sensenova), and the default instance behavior (None → main instance). Some behaviors like error handling or rate limits are omitted, but the key operational quirks are disclosed.

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

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

The description is compact and well-structured: a one-sentence purpose summary followed by a clean parameter list. Every line adds useful information with no filler. The only minor weakness is the reference to an external '3.7 命名实例机制' section, which reduces self-containedness.

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?

This is a moderate-complexity generation tool with 5 parameters and an output schema, so return-value documentation is not required from the description. The description covers all parameter semantics, defaults, provider fallback, and size-adaptation behavior. It lacks explicit usage examples or edge-case handling, but overall it is sufficient for selecting and invoking 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 description coverage is 0%, so the description must compensate, and it does: every parameter (prompt, size, n, provider, instance) is explained with defaults, valid options or behaviors, and resolution rules. This goes far beyond the bare schema types and titles, giving an agent enough to construct valid calls confidently.

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

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

The description clearly identifies a specific operation: general text-to-image generation via the GEN_IMAGE pipeline, with support for multiple images and configurable provider/instance. It is concrete and not a tautology. However, it does not explicitly contrast itself with sibling tools, so some differentiation is left to inference.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The phrase '通用文生图' implies a general purpose, and the mention of n>1, provider, and instance signals capabilities, but the description never tells an agent when to choose g-pic over siblings like r-pic or i-pic, nor what scenarios would make another tool more appropriate.

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

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

With no annotations, the description carries the transparency burden and does add useful behavioral details: default model, multi-image support, provider fallback via GEN_INFOGRAPH_ADAPTER, and instance selection semantics. However, it does not disclose authentication needs, rate limits, failure behavior, or any side effects, so coverage is only partial.

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

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

The description is compact and front-loaded: a one-line purpose statement followed by a clear parameter list. The only minor issue is the external reference '见 3.7' and the absence of the actual size constant list, but there is no filler or 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 provides enough defaults to invoke the tool correctly, and an output schema apparently exists, so return-value documentation is not required. Still, it lacks usage boundaries against sibling tools, does not enumerate the 11 size constants, and references an external section that the agent may not have access to.

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%, but the description compensates fully by explaining all five parameters: prompt is required, size has a default and a family of 2K constants, n controls count, provider selects backend with a fallback, and instance names a specific instance. This adds real meaning beyond the raw 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 infographic images ('信息图文生图') and identifies the GEN_INFOGRAPH pipeline with a default model, so the function's purpose is specific and actionable. However, it does not explicitly distinguish itself from sibling tools such as r-pic, g-pic, or p-pic, so it stops short of full differentiation.

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

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

There is no guidance about when to choose this tool over alternatives, nor any mention of sibling tools or exclusions. The description only lists capabilities and defaults, leaving the selection decision entirely to the 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?

With no annotations provided, the description carries the full burden, and it delivers: it discloses the pipeline name, default model, default size, provider resolution order (EDIT_IMAGE_ADAPTER env → sensenova), and instance fallback behavior (None → main instance). This gives an agent a realistic picture of how invocation will behave. The only omission is output behavior, but an output schema is present, lowering that burden.

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 structure is efficient: a one-line purpose, a scannable parameter list, and a final note about the callable signature. The Python-syntax note about required-before-default parameters is unusual but earns its place by clarifying the exact tool contract. Nothing is redundant, though the signature line partially repeats schema 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?

For a 5-parameter tool with zero schema descriptions and no annotations, the description covers all parameters, defaults, and behavioral nuances, including the provider fallback and instance resolution. The reference to '见 3.7' for instance details is a minor external dependency, and the output schema covers return values. Slightly more context on when to set provider explicitly would round it out.

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

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

Schema description coverage is 0%, so the description must fully compensate, and it does. Every parameter gets a meaningful definition: prompt is the edit instruction, image_path specifies local path and accepted formats (PNG/JPG/WEBP/GIF), size has a default, provider enumerates the two backends, and instance explains the named-instance concept. This exceeds what a bare schema would convey.

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 opening line '图生图（EDIT_IMAGE 流水线，默认模型 sensenova-u1.5-lite）' identifies the tool as an image-to-image operation on the EDIT_IMAGE pipeline with a named default model. This is clear enough to distinguish it from siblings like r-pic (likely generate-from-reference) or g-pic (likely text-to-image), though it lacks an explicit action verb like 'edits' or 'generates'.

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

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

No guidance is given on when to choose this tool over its siblings. The parameter list implies you need a prompt and a local reference image, but there is no statement of when image-to-image editing is appropriate versus alternatives like r-pic or i-pic. An agent must infer selection criteria entirely from the tool name and parameter shapes.

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 disclosure burden and handles it well: it reveals that the image is sent to an external vision model (with cost/privacy implications), lists accepted formats, and documents default behavior including environment-var fallbacks (VISION_PROVIDER→dots, VISION_MODEL→dots3-note-prev). It stops short of disclosing error handling for missing/invalid paths or file-size 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?

A one-line functional summary is front-loaded, followed by a scannable line-per-parameter list with no filler. Every line earns its place given the schema's 0% description coverage.

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?

All invocation-critical information is present: path requirement, question semantics, provider/model selection with env fallbacks, and the max_tokens cap. The output is described as text and an output schema exists, so return-value detail is unnecessary; the main gap is edge-case behavior such as handling of nonexistent paths or unsupported formats.

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 fully compensates: all 5 parameters are documented with meaning, requiredness, valid values (provider: openai/dots; model: dots3-note-prev), and defaults. Notably it explains that null schema defaults resolve via environment variables, a behavior the schema itself cannot express.

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 a specific verb and resource (识别本地图片 — recognize local images), lists supported formats (PNG/JPG/WEBP/GIF), and names the outcome (text description or Q&A result). It is clear and self-contained, but it never explicitly contrasts with sibling tools like r-vid, g-pic, or b-gen, so an agent must infer the distinction from the '本地' (local) qualifier and the r- recognition prefix.

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 usage context is implied by the scoping: this is for local image files of specific formats, producing text output, so an agent can infer it fits tasks like 'describe this image file.' However, the description offers no explicit when-to-use/when-not-to-use framing and never mentions alternatives, which is a real gap given five sibling tools of ambiguous function.

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 the burden of behavioral disclosure. It discloses server-side access requirements, provider/model fallback logic, and advises max_tokens to avoid truncation—information well beyond the schema. It does not enumerate failure modes, but the key behavioral traits are covered.

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

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

The description is front-loaded with a clear one-line purpose, followed by a terse, scannable parameter list. Each line adds distinct information with no repetition 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 adequately covers purpose, all parameter semantics, defaults, and the output format, which is enough for a straightforward vision-model tool. It lacks explicit alternative routing and edge-case behavior, but these are not critical for a 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 0%, so the parameter explanations in the description are essential. It provides meaningful context for all five parameters: required direct link, default question, provider/model fallback chain, and max_tokens recommendation. This fully compensates for the empty schema property 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 states a specific verb ('解析') and resource ('视频直链'), and specifies the output type ('返回文本描述或问答结果'). The video focus clearly distinguishes it from sibling image tools like r-pic, even without an explicit comparison.

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

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

The description explains how the tool works and covers parameter behavior, but it does not explicitly state when to use r-vid versus alternatives. The video-specific wording implies the usage context, yet no exclusions or alternative routing are provided.

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