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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the behavioral role of being a prerequisite lookup that enforces real field names, but says nothing about failure behavior for an unknown action or about the shape of what comes back.

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, both earning their place, with the purpose stated first and the operational instruction second. No filler or repetition of the title.

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 one-parameter read tool with annotations covering safety, the main missing pieces are how to discover valid action names (likely a sibling such as capabilities) and what happens on an unknown action. No output schema exists, so it could also say a bit more about what the returned schema contains.

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

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

Schema coverage is 0%, so the description must carry the load, and it does clarify that the single parameter is an action identifier rather than free text. It adds no format, casing or example values for that identifier, leaving the key semantic partly undocumented.

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

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

States a specific verb+resource: look up the complete parameter schema for a single fixed action, keyed by action name. It is clearly distinct from write siblings like submit_job, though it never names them 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?

Gives an explicit usage trigger — call this before submitting and fill fields strictly per the returned schema — which tells the agent where in the workflow it belongs. It does not state exclusions or point to the sibling that lists valid action names.

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=false, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description adds real context beyond that: it writes to a local private directory, it verifies before exporting, it returns localPath/size/SHA256, and it needs no HTTP/Bearer credentials — a useful auth disclosure. It stops short of saying what happens on re-export/overwrite or where the private directory lives.

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 sentences, purpose first, then input restriction, then auth note. No filler; each sentence carries distinct information an agent needs.

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 exists, and the description compensates by enumerating the return fields. For a tool that writes a file to disk, it covers safety, auth, and return shape adequately; the unmentioned `kind` enum is the main residual 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 description coverage is 0%, so the description must carry the burden. It does clarify that projectId/artifactId must be IDs rather than paths, but the third parameter `kind` (enum: resource/director) is never mentioned, leaving a meaningful gap in a 3-parameter tool.

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 compound verb (核验 + 导出) against a specific resource (已有受管成品) and names the outputs (localPath、大小、SHA256). No sibling tool in the set handles artifacts, so the distinction is inherent rather than stated explicitly, which keeps it just below 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?

The description implies usage (need a local copy of a managed artifact) and adds two hard constraints — only project/artifact IDs, no arbitrary paths — plus a credentials note. It never says when to use this versus alternatives or states preconditions (e.g., artifact must already be verified/ready).

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?

Adds substantive behavior beyond the annotations: atomicity, a conflict result for started jobs, and the crucial fact that no upstream cancel or retry is dispatched. These are non-obvious side-effect guarantees that annotations (idempotentHint/destructiveHint) cannot convey, and the idempotency claim is consistent with idempotentHint=true.

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 sentences, front-loaded with the scoping constraint, then failure behavior, then idempotency. No wasted text.

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

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

For a one-parameter mutation tool with no output schema, it covers the important semantics (scope, conflict case, no upstream effects). It leaves the success response shape unstated, which an agent may want before calling.

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?

One parameter with 0% schema description coverage; the description only implies the job identity via '原任务' and adds no format details, while the schema supplies just a hex pattern. Adequate but does not compensate meaningfully for the missing description.

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 (cancel) and a tightly scoped resource ('只原子取消QUEUED任务'), so an agent can distinguish it from list_jobs/get_job/submit_job by scope alone. It does not name a sibling alternative explicitly, which keeps it just below the top mark.

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 conditions: works on QUEUED jobs, returns conflict for already-started jobs, and is safe to repeat. No explicit 'check with get_job first' guidance or naming of alternatives, so it stops short of full when/when-not/alternatives coverage.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds value by stating the payload contents and the important caveat that being callable does not mean real generation has been validated. That caveat about data trustworthiness goes meaningfully beyond structured fields; only the exact response shape is left implicit.

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 dense clauses: the first front-loads what is returned, the second gives the ordering instruction and the reliability caveat. Every clause earns its place, though the telegraphic phrasing is compressed enough to require careful reading.

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 discovery tool with no output schema, the description should convey enough about the returned structure to act on, and it only lists categories without shape. The missing piece is a disambiguation line against action_schema and studio_catalog, which also expose implementation metadata.

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 are no semantics to explain and the baseline is 4. Nothing in the description contradicts or wastes space on parameter framing.

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 concrete resources: implemented operations, a read-only switch, and a credit cap, so an agent can tell this is a capability-introspection tool rather than a job runner. It does not, however, distinguish itself from sibling discovery tools such as action_schema or studio_catalog, leaving overlap unresolved.

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 an explicit call-ordering rule: query this before invoking anything else, which is real usage guidance. It stops short of exclusions or naming which sibling to use when, so the agent must infer boundaries versus action_schema.

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 readOnly/idempotent/non-destructive, but the description adds non-obvious semantics annotations cannot carry: the distinction between status (invocation state) and operationOutcome (business result), and the warning that COMPLETED does not mean the media is finished. The 'partial/unknown → recovery, do not resubmit' directive is exactly the kind of behavioral guidance an agent needs, though not-found/error behavior is unstated.

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 dense clauses, front-loaded with the scoping constraint followed by the return-value warnings. Every phrase contributes information; 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?

No output schema exists, so the description usefully explains the two key result fields (status, operationOutcome) and how to interpret the terminal-looking COMPLETED state. It stops short of describing what happens on an invalid or missing jobId, which is the one gap for a read-only lookup 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%, so the description carries the parameter burden. It does add a real constraint — the ID must be the original jobId, not one from a resubmission — but it provides no format, validation, or not-found semantics for the single required string parameter, which the schema only partially covers via its hex pattern.

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 clause '只查询原jobId' identifies the verb (query) and the resource (job by ID), and the title '查询已有即梦任务' reinforces it. It implicitly distinguishes itself from submit_job/cancel_job by scoping to an existing original jobId, though it never names a sibling 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?

It gives one concrete usage rule — for partial/unknown outcomes, inspect the original node/resource/submitId and do not resubmit — which meaningfully steers agent behavior. However it never states when to prefer get_job over list_jobs or when a job must be polled vs. abandoned, so the selection guidance against siblings is only implied.

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 and destructiveHint=false, so the description's added value is the disclosure that responses are summaries only (no prompts or media) and that cursor continuation is filter-bound. Useful context beyond the annotations, though ordering and default page size remain undisclosed.

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 compact clauses, front-loaded with the query scope, then the exclusion, then the pagination rule. 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 five fully undocumented parameters and no output schema, the description leaves the limit parameter, default value, and result ordering unexplained, and the cursor naming is inconsistent with the schema. It is adequate but falls short of what a 0%-coverage, five-parameter tool needs.

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 carry parameter meaning. It names the status/action/project filters but never explains the limit parameter, and it refers to the cursor as 'nextCursor' while the schema property is 'cursor' — a naming mismatch that could mislead the agent.

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 (分页查询持久化任务摘要) plus the three filter axes, and adds a scope boundary (不返回提示词或媒体内容) that distinguishes it from content-returning siblings like get_job. The distinction from queue_summary is only implied, not stated.

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 pagination rule ('继续翻页须复用相同筛选和nextCursor') gives a clear procedure for continuation, but there is no guidance on when to prefer this list over queue_summary or get_job, and no stated prerequisites for the cursor.

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 readOnly, idempotent, non-destructive, open-world. The description adds that counts come from persisted state rather than a live upstream call, which hints at possible staleness, but it does not state how fresh that snapshot is or what the response looks like. Useful context beyond annotations, but thin.

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 semicolon-delimited sentence that front-loads what is returned and ends with the boundary condition. Every clause carries information; 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?

For a zero-parameter, non-destructive read with no output schema, the description covers enough: the three categories of data returned. It does not describe the shape of the counts or queue lists, which is the only remaining gap, and with no output schema the agent might want that.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly gives no parameter guidance, which 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 names a specific verb (查询) and the exact data returned: persisted state counts, read/write queues, and earliest queue time. An agent can form a clear picture of what the tool produces, though it does not distinguish itself from siblings like list_jobs or capabilities.

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?

Usage is only implied: the note '不发起上游操作' signals this is the safe way to inspect queue state without triggering upstream work. It never names alternatives such as list_jobs or get_job, nor states when this should be preferred over them.

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 read-only, idempotent, non-destructive, and open-world behavior, so the safety profile is known. The description adds meaningful semantics beyond that: the output is planning evidence, and entries flagged implemented=false are not callable tools — a critical interpretation rule the annotations cannot express. It doesn't describe the shape of the evidence/gap records, but the core behavioral caveat is 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?

Two short sentences with zero filler: the first states what is read, the second states the planning-only constraint. The constraint, which is the operationally important part, is not buried.

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 no parameters and no output schema, the description carries the burden of explaining what comes back, and it does so at a high level ('证据与缺口') plus the key implemented=false field semantics. It could say slightly more about how to interpret evidence/gap records, but an agent has enough to call it and read the result 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?

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline of 4 applies; the description correctly implies a parameterless full-catalog read.

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 resource (a catalog of studio features: web character library, scripts, storyboards) and the verb (read evidence and gaps), so the agent knows it returns a planning inventory rather than live data. It does not, however, differentiate itself from the sibling 'capabilities' tool, which an agent could plausibly confuse with this one.

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 an explicit usage frame ('此目录仅供规划') and a clear prohibition ('不能把 implemented=false 的条目当可调用工具'), which tells the agent when not to act on the output. It stops short of naming an alternative (e.g. capabilities or action_schema) for when live capability data is 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?

Beyond the annotations (destructive, idempotent, open-world), it discloses critical behavior: writes default to dryRun=true and real writes must satisfy backend live policy, COMPLETED only means the call returned, and UNKNOWN must not be regenerated. These are non-obvious traits an agent could not infer from 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 prerequisite is front-loaded, and each clause (idempotency, dryRun, status semantics) carries distinct information with no padding. It is dense but appropriate for a write tool with several failure modes.

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, open-world mutation with no output schema, it covers the essentials: setup, idempotency, dry-run defaults, and result semantics. It could go further by naming get_job as the way to check job status and hinting at the payload's action field.

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 explain the two parameters; it only says idempotencyKey is required (already implied by the schema's required list) and skips the nested payload shape entirely beyond delegating to action_schema. It partially compensates for the coverage gap, but not fully.

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+resource: it submits a payload as a persistent job, after resolving fields via action_schema. It is easy to distinguish from the read-only siblings (get_job, list_jobs), but it never explains how it differs from submit_job_json, the closest sibling.

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 states an explicit prerequisite ('先用 action_schema 查询字段') and a clear precondition for retries (reuse the original idempotencyKey with the same payload on timeout). The only gap is that it does not say when to choose this tool over submit_job_json.

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=true, idempotent=true and openWorld=true, so the safety profile is known; the description adds real context beyond them – the backend still strictly validates each field, and timeouts must reuse the original idempotencyKey rather than resubmitting. That retry/idempotency guidance is the kind of behavioral detail the annotations cannot convey.

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 sentences with no filler: equivalence and input format first, then the prerequisite lookup, then the retry constraint. Every sentence carries actionable 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 only two parameters and no output schema, the description covers the call mechanics well by deflecting payload structure to action_schema and spelling out retry behavior. It is slightly incomplete on return value and payload encoding, but nothing critical for a correct invocation 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 0%, so the description must carry the burden, and it does: it explains that payloadJson is the serialized full argument object including an 'action' field, and that the shape must be discovered from action_schema first. It also gives idempotencyKey semantics (reuse the original on timeout), though it never states that payloadJson is a JSON-encoded string with size limits.

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 action (submit a job through a JSON payload entry point) and explicitly declares it is fully equivalent to the sibling submit_job, which lets an agent distinguish the two. The 'concise input entry point' framing is clear, though it never says what the tool actually returns or which action values exist.

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 concrete prerequisite ('先查 action_schema') before calling, and an explicit retry rule on timeout (reuse the original idempotencyKey, never auto-resubmit). It also frames this as equivalent to submit_job, implying the two are interchangeable, but it doesn't say when to prefer one over the other.

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