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

Annotations already declare the safety profile (not read-only, not idempotent, not destructive, open-world). The description adds genuinely non-obvious behavioral context: it auto-finds empty space and lays nodes out in a column, and it rejects non-certified assets. It stops short of noting duplicate handling or interaction with the existing canvas, but it earns credit beyond the structured fields.

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 tight sentences with no filler; the action and the auto-layout behavior are front-loaded, and the input constraint is stated last as a clear boundary.

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

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

With an output schema present, return values need no explanation, and annotations plus a fully-covered schema carry the rest. The description covers purpose and constraint adequately, though it omits how this fits the broader certified-asset workflow (groups, uploads).

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 project, asset_ids, display_names and allow_duplicate, including defaults and pairing behavior. The description adds only the 'certified' constraint, so the 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?

The description gives a concrete verb and resource: placing certified assets (images/videos) onto the canvas with auto-positioning in a column. It also scopes the input to 'certified' assets, which helps separate it from generic node creation. However, it does not explicitly distinguish itself from siblings like create_video_node, which also add nodes.

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 line '只接受「已认证」的素材' acts as a constraint implying when this tool is (and isn't) appropriate, but there is no explicit routing to alternatives such as upload_certified_image/video for uncertified assets. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is fully covered by structured data. The description's contribution is the workflow cue to call it once upfront before mutating operations; it adds no further behavioral detail (no cost, latency, or failure-mode context), so a baseline 3 is appropriate.

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

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

A single dense sentence that front-loads the capability list and ends with the actionable timing instruction. Every clause carries information; there is no filler or repetition of the tool name.

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

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

With an output schema present, return fields need not be explained, and the description still previews them; annotations cover safety. The only minor gap is what to do with the port value on a follow-up call, which is deferred to the parameter description rather than the tool description.

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 port parameter's own description already explains its disambiguation role ('同时开着多个画布时...' referencing 可选画布 from a prior return). The tool description merely lists 端口 as something reported and adds no syntax or selection semantics beyond the schema, so the baseline 3 stands.

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?

States a specific verb+resource (查看画布状态) and enumerates exactly what is inspected: running state, which program variant (无限画布/内部版), port, version compatibility, project count. No sibling tool does anything similar, so the agent can distinguish it immediately from the project/node-creation 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?

Gives explicit timing guidance: '开始操作前先调一次' (call once before starting operations), which tells the agent precisely when this belongs in a workflow. It does not state when NOT to use it or name an alternative, but for a single status tool there is no real alternative to route against.

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 only give generic hints (readOnlyHint=false, openWorldHint=true). The description adds crucial behavior the annotations cannot convey: creation is irreversible because 玄上 exposes no delete API, duplicate names are rejected, and a remote side is created in tandem. This is exactly the extra context the annotations fail to carry.

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 tight sentences: purpose and workflow first, then the irreversible-deletion warning, then the collision rule. Nothing is redundant and the most consequential constraint (cannot be undone) is surfaced early.

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?

An output schema exists, so return values need no explanation. For a non-idempotent, open-world creation tool the description covers the hazards an agent must know: irreversibility, external-side effects, and duplicate rejection. Nothing essential 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%, so the schema already documents name, project, and description in detail. The description adds only a soft note that the name should be confirmed with the user, not new syntactic or semantic detail — 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?

States a specific verb (新建/create) and resource (认证分组/certified group) scoped to a project, and adds a distinguishing detail — the group is mirrored on the external 玄上 side. An agent can tell this apart from list_certified_groups and the upload_* 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?

Gives clear context for use: the created group is what you select later when uploading certified assets, and the name should be confirmed with the user first. It does not explicitly name or exclude a sibling alternative, so it stops 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 flag destructive/non-idempotent/openWorld, and the description adds material context beyond them: the operation costs credits (花积分), demands per-call user confirmation, and creates a new canvas node. It stops short of describing reversibility of the resulting node.

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 tight sentences; the cost and confirmation requirement are front-loaded before the canvas side effect. 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?

An output schema exists, so return values need not be explained. The description covers cost, confirmation flow, and the canvas side effect—enough for a correct call, though it could clarify the confirm_code round-trip more explicitly.

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 node/project/task_id/confirm_code are all documented in the schema itself. The description adds no syntax or format detail beyond that, so the 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?

States a specific verb+resource: converting a Seedance 2.5 sample (样片) into a 1080p final video (成片), plus the side effect of creating a 成片生成 node. The purpose is clear, but it doesn't explicitly differentiate itself from siblings like create_video_node or submit_generation.

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

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

Implies the precondition (a successful sample must exist) and discloses that each call requires separate user confirmation, which is a usage constraint. However, it never states when to prefer this over sibling tools such as submit_generation or create_video_node, leaving the selection logic implicit.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds genuinely new behavior: the tool enforces name uniqueness and refuses duplicate names, and the created project starts empty. It does not mention error/response shape or any permission requirements, so it stops short of a 5.

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 short clauses, front-loaded with the action, then the rejection condition, then the remedy. The parenthetical rationale ('避免以后选错项目') explains the constraint rather than padding, and nothing is redundant.

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?

An output schema exists, so return values need not be described here, and the description covers purpose, the uniqueness failure mode, and the workaround for a simple 2-parameter tool. It leaves out only secondary details such as whether the new project becomes active or what error signal the rejection produces.

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

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

Schema description coverage is 100%, with both 'name' and 'description' fully documented including an example name format. The description adds the same uniqueness constraint already stated on the 'name' parameter, so it contributes no semantic detail beyond the schema — 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?

Names a specific verb and resource (新建一个空项目 / create an empty project) scoped to the canvas, and states what the object is (empty project) rather than a vague 'create' action. No sibling tool competes for this operation (the others are list/get/upload/add-node variants), so the agent can select it unambiguously.

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

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

Explicitly states the when-not condition (a same-named project already exists → the call is rejected) and gives two named alternatives: pick a different name, or reuse the existing project. This is exactly the when/when-not/alternative guidance the rubric rewards.

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 (which only cover mutation/idempotency/open-world traits), the description discloses concrete runtime behavior: reference-format normalization, numbering-to-material matching, certified/generated asset validation, parameter compliance checks, and an immediate read-back verification after creation. It also declares the critical non-action that it will not submit generation.

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?

Front-loaded with the action, then the validation checklist, then the scope boundary — a logical, dense ordering with little filler. The single semicolon-chained sentence is information-rich but slightly heavy to parse.

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 13-parameter creation tool with annotations and an output schema, the description covers the validation behavior and the key boundary of not triggering generation, so return values need not be explained. It could be more explicit about workflow ordering with submit_generation, but nothing essential 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%, so all 13 parameters including defaults and accepted values are already documented in the schema. The description restates reference-format normalization that the prompt parameter already documents, adding little beyond the structured fields; 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?

States a specific verb and resource ('新建 Seedance 视频生成节点并连好素材'), and explicitly scopes itself apart from the generation-submitting sibling with '不会提交生成'. An agent can distinguish this from submit_generation or create_final_video without opening any schema.

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 closing '不会提交生成' makes the boundary with the generation-submission step clear, and the enumerated checks imply this is the setup step that precedes generation. It stops short of explicitly naming the alternative tool or stating ordering requirements, so it is clear context rather than full when/when-not guidance.

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

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

Annotations already declare the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the safety burden is lifted. The description adds useful scope detail — it aggregates across all video nodes plus certified image/video nodes and surfaces task status and existing outputs — but since an output schema is present, much of this restates return contents rather than adding new 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 front-loaded sentence that opens with the summary subject and then enumerates contents. It is a long run-on list, but every clause 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?

With an output schema documenting the return shape and annotations covering the safety profile, the description only needs to convey scope and content, which it does. The one gap is the absence of any routing guidance among the many sibling status/listing tools.

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?

Only one parameter (project), and the schema already documents it at 100% coverage, including the pointer to list_projects. The description adds no format or syntax detail beyond the schema, so the 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?

The description names the resource (项目节点摘要) and enumerates the concrete contents it returns: per-video-node name, parameters, ordered input materials, latest task status, whether a generated video exists, plus certified image/video node names and IDs. This is specific and distinguishing in substance, though it never explicitly contrasts itself with look-alike siblings such as canvas_status or get_task.

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 statement of when to call this tool versus alternatives — notably canvas_status, which appears to be a closely related status-listing sibling. The description describes what comes back but gives no selection criteria, prerequisites, or exclusions, leaving usage entirely 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the useful constraints that it should not be polled repeatedly and that it returns output files, but says nothing about freshness, caching, or behavior when a task does not exist.

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, front-loading the scope statement before the usage restriction. Every clause earns its place with no 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?

With an output schema covering return values and annotations covering safety, the description only needs to convey scope and usage, which it does. The one gap is the interaction/precedence between task_id and node when both are provided.

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

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

Schema description coverage is 100% and the node parameter already documents the 'latest task for this node' behavior, so the schema carries the semantics. The description adds no syntax, format, or precedence rules (e.g., what happens if both task_id and node are supplied).

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?

States a specific verb and resource ('查某个任务/某个节点最近一次任务'), and clarifies that it returns status, progress, and output files. It covers both the task_id and node invocation modes. It does not explicitly name a sibling like canvas_status to disambiguate, so it stops short of a 5.

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?

Gives a clear trigger condition ('只在用户问进度时调用') plus an explicit anti-pattern ('不要反复轮询'), which is a genuinely useful usage constraint. It does not name an alternative tool for cases where progress polling is needed, so it is not a full 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description does add one genuine behavioral detail beyond annotations: the certification status is fetched live ('向玄上实时查'), telling the agent the data is not stale/cached. It stops short of describing cost, latency, or batching 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?

A single dense sentence that front-loads the resource and packs the three returned fields without filler. It is efficient, though the run-on parenthetical structure makes it slightly harder to parse than a clearly punctuated list of returned fields.

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?

An output schema exists, so return values need no further explanation, and annotations cover the safety profile. What is missing is the usage context: when an agent should call this versus canvas_status, and whether project is required (schema covers that). Adequate but with a clear routing 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?

There is a single required parameter (project) and schema description coverage is 100%, with the schema itself pointing the agent to list_projects for lookup. The description adds no further parameter meaning, which is the expected baseline when the schema does the work.

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 the resource (认证分组) and enumerates the content it surfaces: per-asset certification status and whether each asset is on the canvas. However, it is a noun phrase fragment with no explicit verb, and it does not differentiate itself from the sibling canvas_status, which plausibly reports overlapping canvas state. An agent can guess the data returned but not cleanly why this tool exists beside canvas_status.

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 when-to-use statement, no prerequisites, and no mention of any alternative sibling (e.g. canvas_status or list_projects). The only routing hint comes from the schema parameter description ('用 list_projects 查'), not the tool description itself.

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

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

Annotations already declare this a safe, idempotent, read-only, closed-world operation, so the safety profile is fully covered. The description adds the returned field set, which is modest value given an output schema exists and it says nothing about pagination, ordering, or scope 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 single short sentence that front-loads the action and immediately parenthesizes the payload. Every element earns its place with 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?

With an output schema present, rich read-only annotations, and zero parameters, the description needs only to establish purpose and scope, which it does. It is not fully complete because it never clarifies how listing projects relates to sibling tools that also report canvas state.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter-related gaps exist.

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?

States a specific verb and resource (list projects in the canvas) and even names the returned fields (name, ID, node count), so the agent knows exactly what it gets. It does not explicitly differentiate itself from siblings like canvas_status or get_graph_summary, which also expose canvas-level information.

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

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

There is no when-to-use guidance, no conditions, and no mention of alternatives such as canvas_status or get_graph_summary. The intended use is only implied by the name and description.

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

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

Annotations already declare write/destructive/non-idempotent/openWorld, and the description adds genuinely new behavior: it consumes credits, requires an explicit user confirmation step, hard-rejects concurrent tasks on the same node, and returns only a task ID without tracking progress. That last point is important because it tells the agent to poll elsewhere rather than wait.

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 short, front-loaded sentences covering cost, confirmation requirement, concurrency rejection, and return behavior. Zero filler; the most decision-relevant information (costs credits, needs confirmation) comes first.

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 destructive, non-idempotent submission tool, the description covers cost, the mandatory confirmation gate, the rejection rule, and the fact that progress is not tracked (implying the agent must poll get_task). An output schema exists, so return-value detail is not required of the description.

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, but the description supplies the two-step confirmation narrative that gives confirm_code its meaning (a code returned by a prior call that the user must approve). It does not add syntax or format detail beyond the schema, so it is not a full 5.

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+resource (提交生成任务 = submit generation task) and adds the cost signal (花积分), so an agent knows at a glance this initiates a paid render. It does not explicitly distinguish itself from sibling creation tools like create_video_node or create_final_video, so it stops short of a 5.

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?

Gives clear operating conditions: every submission requires per-user confirmation through a dialog, and submission is rejected outright if a task is already running on the node. It stops short of naming an alternative tool for any scenario, so 4 rather than 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 declare a non-read-only, non-idempotent, open-world mutation. The description adds real behavioral context beyond that: the +6000px canvas compression fallback, the plugin-driven user confirmation, and the two-step confirmation it later mentions. It stops short of stating idempotency or auth requirements, so it is not fully exhaustive.

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 carrying distinct load: capability, return summary, and the compression/confirmation caveat plus next-step. Return values are front-loaded and nothing is redundant, though it is slightly dense.

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 100% covered schema and an existing output schema, the description does not need to explain return values, yet it still names them helpfully. Combined with the format list and the follow-up tool reference, an agent has what it needs; only permission/auth expectations are unaddressed.

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 five parameters including the conditional confirm_code semantics. The description reinforces the confirm_code two-step flow implicitly but adds no syntax or format detail beyond the schema, so the 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?

The description states a specific verb and resource (本地图片按原质量上传并认证) and enumerates supported formats, immediately distinguishing it from the sibling upload_certified_video. An agent can tell exactly what this does without opening the schema.

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?

It gives clear sequencing guidance, telling the agent that after upload it must use add_certified_asset_node to place the asset on the canvas, and describes the confirm-first flow for large images. It does not explicitly state exclusions versus siblings, but the image-vs-video split is self-evident.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false; the description is consistent and adds real value: a no-transcode/no-edit guarantee, the return payload (asset ID, storage destination, size verification, certification status), and the prerequisite-certification step. It stops short of covering failure modes or re-upload/idempotency implications, so 4 rather than 5.

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?

Front-loads the operation and its guarantees in the first sentence, then uses the second for prerequisites and the hand-off to add_certified_asset_node. No redundant or filler text; every sentence carries routing or constraint 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?

With an output schema present and annotations covering the safety profile, the description need not detail return values, yet it still summarizes them. Workflow prerequisites, exclusion of already-generated videos, and the required follow-up tool make this fully sufficient 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%, so all four parameters (project, file_path, group, display_name) are already documented in the schema, including the pointer to list_certified_groups and list_projects. The description adds no syntax or format detail beyond the schema, 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?

States a specific verb+resource ('upload and certify a local reference video') and pins down scope with '按原文件上传（不转码、不剪辑）', distinguishing it from upload_certified_image (video vs image) and from create_video_node. An agent knows exactly what operation this is without opening the schema.

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

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

Explicitly states the condition ('本地参考视频必须先认证才能接到视频节点上') and the exclusion ('画布上已生成的视频不用这一步'), and names the follow-up sibling ('认证完再用 add_certified_asset_node 放到画布上'). Both when-to-use and the alternative path are spelled out.

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