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

With no annotations provided, the description carries the burden of behavioral disclosure. It communicates a read-only inspection action ('查看') and the important privacy trait that API Key is not included. It does not discuss side effects or rate limits, but for a status tool this is reasonably 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?

A single, front-loaded sentence states the resource and the key exclusion without filler. 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?

For a parameterless status/config tool with an output schema, the description is complete: it identifies the resource, the operation, and the privacy exclusion. No additional usage or output detail is 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?

The tool has zero parameters and schema description coverage is 100%, so the schema fully captures parameter semantics. Baseline for 0 params is 4; the description adds no param-specific detail, which is acceptable.

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 uses a specific verb '查看' and resource '当前模型与限制配置' to identify exactly what the tool does. It also explicitly excludes API Key, adding scope precision. This clearly distinguishes it from the media generation/recognition 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 implies the tool is a status/config inspection endpoint, but it does not state when to call it relative to recognize/generate siblings or any alternatives. No exclusions or alternate tools are named, so usage context is left to inference.

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 annotations only indicate non-read-only, open-world, and non-destructive. The description adds concrete behavioral context: the result is persisted locally and the return value is a filesystem path, and it can be previewed inline. This is useful beyond the annotations. It does not mention the cost/confirmation gating, but that is documented in the schema parameter description and does not contradict the annotations.

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

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

The description is compact and well-structured: one opening phrase states the purpose, and one sentence gives the key output side effect and preview integration. Every sentence carries information and there is no 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?

Given full schema documentation, annotations, and no output schema, the description covers the critical output behavior (local path return) and preview capability. It could be improved by explicitly noting the paid/confirm gating or when to select this vs. the video generators, but those are either in the schema or inferable from the clear text-to-image purpose.

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 applies. All four parameters (prompt, size, tier, confirm) are already fully described in the schema. The tool description itself does not add additional meaning about the parameters, aside from loosely implying the prompt is the text-to-image 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?

The description clearly states the tool's core function ('文生图' - text-to-image), and adds a distinct behavioral detail: the generated result is downloaded to a local output directory and a path is returned. This differentiates it from the sibling video-generation and recognition 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 implies the main use case (generate an image from text) and mentions inline preview via dsh-image-preview, which gives some context. However, it does not explicitly state when to prefer this tool over generate_video or the recognition tools, nor does it provide any exclusions or alternative routing.

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 one genuinely useful behavioral fact beyond the annotations: results are downloaded to a local output directory and a path is returned. It does not contradict the annotations (readOnlyHint=false agrees with a generating/writing operation). However, it omits consequential behaviors such as the confirm-gate (must be true to actually invoke the paid API) and the asynchronous wait/return-task_id behavior, which the schema documents but the description does not surface.

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 sentences with zero waste: the core purpose is front-loaded ('文生视频'), and the second sentence states the output contract. Every word earns its place, and there is no repetition of schema content.

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

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

For a cost-incurring generation tool with no output schema, the description gives only a minimal output contract ('returns path') and does not flag the confirm-gate gotcha or cost implications in the main description — though the schema parameter descriptions do cover them. It is adequate for a basic call but not rich enough to fully prepare an agent for the tool's key behavioral decisions.

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 schema already documents all six parameters (prompt, tier, wait, confirm, duration, resolution) with informative detail, including model names per tier and the 480P auto-upgrade rule. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb-resource pair ('文生视频' — generate video from text) and immediately distinguishes this tool from the sibling generate_video_from_image. It also states the concrete output behavior (downloading the result locally and returning the path), leaving no ambiguity about what the tool accomplishes.

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 '文生视频' phrase implies the use case: call this when the input is text and the desired output is video, which implicitly differentiates it from image/video/audio recognition siblings and generate_video_from_image. However, no explicit when-to-use guidance, exclusions, or alternative tool names are given, so routing decisions are left to inference.

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 no behavioral detail beyond 'generates a video'. Annotations only state readOnlyHint=false and destructiveHint=false, so the description carries the burden of disclosing the paid-generation flow, cost confirmation, and async wait behavior — none of which appear in the description. It does not contradict the annotations, but it also fails to add behavioral context.

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

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

A single compact sentence with the core concept front-loaded ('图生视频') and zero wasted words. It is economically written, though arguably too terse for a tool with 7 parameters and a paid-generation workflow.

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 7 parameters, no output schema, and a rich behavioral workflow (confirm-before-payment, wait/task_id async mode, tier selection, resolution auto-upgrade), the one-line description is insufficient. The schema partially compensates, but the description alone leaves an agent unaware of cost confirmation and asynchronous submission dynamics.

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's phrase '以图片为首帧' aligns with the image parameter's meaning but adds no new semantic detail beyond what the schema already documents for the seven parameters. It neither compensates for gaps nor introduces 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 the verb (generate), the resource (video), and the key constraint (image as the first frame). This implicitly distinguishes it from the sibling generate_image (image generation) and generate_video (likely text-to-video), though it does not name those siblings explicitly.

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 '图生视频' (image-to-video) prefix implies the use case: generating video when an image is available as the starting frame. However, there is no explicit guidance about when to prefer this tool over the sibling generate_video, no exclusions, and no prerequisites such as the confirm=true requirement or cost check.

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

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

Beyond the annotations, the description discloses important behavioral details: short audio uses qwen3.5-omni directly, long audio switches to fun-asr and is asynchronous, and local files are uploaded to temporary OSS. This is exactly the kind of hidden behavior an agent needs to anticipate.

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, front-loads the core purpose, and presents the routing rules and return type in a scannable structure with no filler. 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 that an output schema exists and annotations cover the safety profile, the description is complete: purpose, routing thresholds, side effect (OSS upload), asynchronous behavior, and output nature are all present. No critical decision information for an agent is missing.

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 the schema already defines audio, task, and language. The description adds useful context about processing branches that affect audio selection and the language hint, but it does not substantially extend parameter-level meaning 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 names a specific action ('识别') and resource ('本地音频或音频 URL'), and the short/long routing makes the tool's job unmistakable. It is also immediately distinguishable from sibling tools like recognize_image and recognize_video by audio modality.

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 indicates this tool is for audio recognition and provides explicit condition-based routing for short vs long audio, which is strong usage context. It does not explicitly name sibling alternatives or state when not to use them, so it stops just short of a 5.

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 signal readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds that the tool calls an external Qwen multimodal model and that task determines the extraction behavior, which is useful contextual information beyond the annotations. It does not disclose latency, failure modes, or side effects, but for a recognition tool this is a reasonable level of transparency.

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 behavior: image input, URL support, task-driven processing, and the underlying model. Every part earns its place and there is no redundant wording.

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, complete parameter schema, existing output schema, and annotations that cover safety hints, the short description is mostly sufficient. It covers the essential input types and core behavior, though it could additionally mention when not to use it or any image format constraints. Overall, the available context is adequate for an agent to select and call 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 100%, so the schema already documents all three parameters: image, task, and mode. The description only reinforces that 'task' drives the model call, adding little beyond the structured schema. This aligns with the baseline of 3 for full 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 states a specific verb ('recognize'), a clear resource ('local image or image URL'), and explains that recognition is driven by a task parameter invoking a Qwen multimodal model. It distinguishes itself from sibling tools by scoping to images rather than video or audio, though it does not explicitly name an alternative.

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 image inputs by mentioning both local paths and URLs, and the sibling names make the video/audio alternatives inferable. However, it does not explicitly state when to use this tool over siblings or provide any exclusions, such as 'for videos, use recognize_video'.

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

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

Beyond the annotations, it discloses important operational behavior: automatic temporary OSS direct upload for files over 14MB (1GB cap, no quality compression), base64 for small files, support for non-browser-playable containers such as mkv/avi, and server-side decoding/frame extraction. These are genuine behavioral traits that affect invocation success, and they do not contradict the annotation.

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

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

The description is two sentences: the first states the purpose, and the second packs the key constraints into a compact list without filler. Every sentence earns its place and the most selection-relevant information is front-loaded.

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

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

With a full schema, an output schema, and annotations present, the description covers the remaining invocation-relevant facts: accepted sources, size threshold, transfer method, and container compatibility. It could have explicitly routed an agent away from sibling tools, but the verb and resource plus the default task make the use case clear enough.

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 documents all four parameters with descriptions, defaults, and valid ranges (e.g., fps 0.1-10 default 2.0, mode options, task default, video path/URL). The description adds no per-parameter meaning beyond that, so the baseline of 3 applies given 100% 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 opening phrase '识别本地视频或视频 URL' names a specific verb (recognize) and resource (local video or video URL), which distinguishes it from recognize_image/recognize_audio and from generate_video tools. The additional details about decoding and frame extraction reinforce that this is an analysis tool, not a generation 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 gives clear context for when the tool applies: it accepts local absolute paths or http(s) URLs and explains concrete file-size routing (>14MB via temporary OSS, smaller files via base64). It does not explicitly name alternatives or state when not to use it, so it stops short of full exclusions.

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