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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds real value beyond that: it discloses cloud inference (data leaves the local machine, consistent with openWorldHint), the async contract (returns a task ID and requires polling status), and that output is a gap report plus PRD. It omits cost/rate implications for max_calls/max_tokens, but the async and cloud traits are useful non-obvious 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?

Three short sentences, front-loaded with the action and followed by the limitation rationale and the return/polling contract. Efficient, though the middle value-claim sentence is slightly promotional rather than strictly operational.

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?

There is no output schema, and the description does tell the agent it gets a task ID and must poll status, which is the key return behavior. But for a 4-parameter, open-world, non-read-only tool with only 25% param coverage, it leaves the parameter semantics and side effects (where artifacts are written, cost of cloud inference) underspecified.

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 only 25%: project_path has a description, but prd_path, max_calls, and max_tokens are undocumented in both schema and description. The description implies a project is scanned and a PRD is produced but never explains these parameters or their bounds, so it fails to compensate for the coverage gap.

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: launching a real reverse-engineering blueprint that scans a local project and performs cloud inference to produce a gap report and a target PRD. This clearly separates it from a passive check, but it never names or contrasts the closest siblings (e.g., blueprint_plan or blueprint_health), leaving the agent to infer the distinction.

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 '静态扫描不能证明生产可用' implies the audit is for cases where static scanning is insufficient, and '需轮询 status' hints at the async workflow via blueprint_status. However, there is no explicit when-to-use/when-not or direct routing to alternatives, so usage 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?

The annotations already declare readOnlyHint=false and destructiveHint=false, so the description need not restate mutation safety. It usefully adds that stage files are retained after cancellation, clarifying the non-destructive scope beyond the annotation. It does not cover permissions, rate limits, or final job state.

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, front-loaded sentence with no filler. Both clauses earn their place by stating the action and the key retention behavior.

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 cancellation tool with no output schema, the description covers the core action and the important side effect of retaining stage files. It is nearly complete, though it could clarify what happens to the job after cancellation or whether partial results remain accessible.

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 for job_id is 100%, and the schema already documents its format and role. The description only refers to the task generally and adds no further syntax, source, or format detail beyond the schema, so the baseline score 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 clearly states a specific verb and resource: cancel a running blueprint task and retain stage files. It is distinguishable from siblings such as blueprint_resume by implying the opposite action, but it does not explicitly name alternatives or scope beyond 'running'.

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 implied by '正在运行的' (running), so an agent can infer this applies only to active jobs. However, there is no explicit when-to-use, when-not-to-use, or routing guidance relative to siblings like blueprint_status or blueprint_resume.

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, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds real value by naming the three subsystems probed (local Python engine, ChatGPT auth, cloud model config), which hints at a composite check touching external auth state, but it says nothing about cost, latency, or how results are reported.

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?

One front-loaded sentence with no filler; every listed item (engine, login state, model config) is load-bearing information about what gets checked.

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 output schema and no parameters, the description covers the essential question of what is inspected, which is enough for an agent to pick the tool. It falls short only in not hinting at the shape of the result (per-subsystem pass/fail, error text), which would help an agent act on it.

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 per the rubric the baseline is 4; the schema is fully specified with additionalProperties=false and nothing needs compensating in prose.

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 (检查/check) and enumerates three concrete resources it inspects: the built-in blueprint Python engine, ChatGPT login state, and cloud model configuration. That is far more specific than a generic 'health check', but it never distinguishes itself from the sibling blueprint_status, which an agent could reasonably confuse it with.

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 run this versus blueprint_status or blueprint_audit, and no prerequisites or exclusions. The diagnostic intent is only implied by the word 'health'.

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 the generic readOnly=false/destructive=false/openWorld=true profile. The description adds genuinely useful behavior beyond that: the call is asynchronous and returns a task ID requiring polling, and it depends on a logged-in ChatGPT account hitting a cloud model (external auth/dependency, consistent with openWorldHint). It does not say what artifacts get committed or whether a run can be undone.

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 sentences: purpose and pipeline first, then the operational outcome (task ID + polling) and the auth condition. 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?

It covers the async lifecycle and auth context, which is the most important missing piece given no output schema. However, with zero required parameters it never clarifies that at least one of idea/prd_path must be supplied, nor how the budget parameters constrain the run — a real gap for a 4-parameter launch tool.

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

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

Schema coverage is 50% (idea and prd_path documented, max_calls and max_tokens bare). The description echoes the 点子/PRD inputs but adds no format, precedence (idea vs prd_path), or meaning for the budget parameters. Baseline 3 for partial coverage with only marginal added value.

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

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

States a specific verb (启动/start) and resource (真实正向蓝图流程) and enumerates the pipeline it drives (需求拆解、五要素、组件选型、架构设计、审稿), which clearly separates it from siblings like status/result/cancel. It also names the async handoff (returns task ID, poll status), so an agent can place it in the lifecycle.

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 implied rather than stated: this is the entry point to the blueprint flow and it hints that status polling follows. There is no explicit 'use this instead of blueprint_resume when…' or any exclusion rule, so the agent must infer when to start fresh versus resume an existing task.

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 and destructiveHint=false, so the safety profile is covered without description help. The description adds a genuine behavioral requirement ('必须展示真实审稿结果' – must display real review results), signaling the output must reflect actual reviewer findings, but it omits pagination, error behavior on invalid job_id, and what happens when 'artifact' is omitted.

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 with two clauses that each carry weight — the list/read modes come first and the output expectation second. No filler or redundancy, though the second clause is more of a directive than a description of the tool.

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?

There is no output schema, so the description must carry return-value information; it only roughly sketches it ('list paths' or 'read content') without detailing structure or the review-result format it insists on. For a two-param read tool with annotations covering safety, this is adequate but leaves notable gaps about output shape and the enum values.

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 50%: job_id is documented ('任务返回的 ID') while 'artifact' has only an enum with no description. The description partially compensates by framing the two modes (listing vs reading a specified artifact), which gives 'artifact' meaning, but it does not explain the enum file types or the ID's 12-hex-character constraint.

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 specific verbs and resources: '列出成果路径' (list artifact paths) and '读取指定成果正文' (read specified artifact content). This is clear and non-tautological, but it never references any sibling (blueprint_status, blueprint_audit, blueprint_plan) to disambiguate, so an agent still has to guess which of the seven blueprint_* tools owns artifact retrieval.

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 dual phrasing implies the operating modes — omit 'artifact' to list paths, supply it to read content — which is useful implicit usage guidance. However, there is no explicit when-to-use guidance relative to siblings like blueprint_status or blueprint_audit, and no preconditions stated beyond the required job_id.

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 establish the mutation/open-world profile, and the description adds two non-obvious behaviors: stage caches are validated and reused, and cumulative call/token budgets are NOT reset. That budget detail is exactly the kind of consequence an agent cannot get from the schema. It stops short of saying what happens when validation fails or whether work is re-executed.

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 with the action front-loaded and the budget caveat trailing; no filler, no repetition of the title or schema.

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 output schema, the description could have said what comes back on resume (job id, resumed stage, status), which is a real gap for a tool an agent will chain with blueprint_status. Otherwise the key non-obvious behaviors are covered and the single parameter is fully documented elsewhere.

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 (job_id) and schema coverage is 100%, with the schema already documenting it as the ID returned by the task and constraining it to a 12-char hex pattern. The description adds nothing about job_id, so the schema 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+scope: resume a previously interrupted/failed task, validating and reusing stage cache. An agent can tell it is a continuation operation, though it does not name or contrast any sibling (e.g. blueprint_status or blueprint_result), so differentiation is left to inference.

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

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

The condition for use is explicit: tasks that were interrupted or failed (已中断/失败任务). It does not state when NOT to use it, nor point to blueprint_status/blueprint_result as the check-first or fetch-results alternatives, so routing among siblings still requires guessing.

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 (readOnly, non-destructive, closed-world), so the bar is lower, and the description clears it by disclosing a genuine semantic gotcha: 'completed_draft 表示审稿未通过，必须如实说明' tells the agent that a nominally 'completed' status actually means review failure and must be reported truthfully. It does not mention polling cadence, terminal states, or error-shape behavior, keeping it 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?

Two compact sentences with no filler; the scope is front-loaded and the important status caveat follows immediately. Every clause carries 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 no output schema, the description correctly carries the burden of describing return content (phase, run status, errors, call/token usage) and adds the completed_draft interpretation, which is the highest-value piece of context. Missing only guidance on failure/error states or whether status is terminal.

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 one parameter and schema description coverage is 100%, with the schema itself documenting the pattern and meaning of job_id, so the baseline of 3 applies. The description adds nothing about the ID beyond what the schema already states.

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 set ('查看任务阶段、运行状态、错误、调用/token 用量') so an agent immediately knows this is a job-status inspection tool. It is clear on its own, but never names or contrasts with the closely related siblings blueprint_result and blueprint_health, leaving the boundary to inference.

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

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

Usage is only implied: the enumeration of status fields suggests 'use this to poll a running job', but there is no explicit when-to-use, when-not-to-use, or routing to blueprint_result/blueprint_health. An agent can guess the context but gets no exclusions or alternatives.

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