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

Annotations already declare readOnly=false, idempotent=true, destructive=false, so the safety profile is covered. The description adds meaningful behavioral context beyond this: cancellation is limited to subsequent steps and will not revoke an accepted power request, auto power off, or restore prior state — exactly the non-obvious semantics an agent needs.

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

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

A single compact sentence that front-loads the primary action and then lists the three things the tool does not do. No filler; every clause earns its place.

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

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

An output schema exists so return values need not be explained, and annotations cover the safety profile, leaving scope as the main descriptive burden — which is handled well. However, for a mutation tool with no annotation on permissions and a completely undocumented required parameter, the definition stops short of being fully self-sufficient.

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

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

Schema description coverage is 0% and the single parameter job_id is left entirely undocumented in both the schema and the description; the description says nothing about what a job_id is or where to obtain it (e.g., from job_status). Only the obviousness of the parameter name keeps this above a 1.

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 (取消 / cancel) and the precise scope of the operation: the remaining steps of a power-on or switch job. This distinguishes it reasonably well from siblings like power_off or job_status, though it never names an alternative tool directly.

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 the negative scoping ('does not revoke the accepted power request'), which tells the agent when cancel_job is the wrong tool for undoing a power request, but there is no explicit when-to-use guidance or reference to alternatives such as wait_for_job or job_status.

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 safety is covered. The description goes beyond that with genuinely useful behavioral context: the caveat that no-GPU mode does not mean the GPU is mounted, and the explicit scope statement that passwords/SSH credentials are not returned. It does not cover permission or rate-limit behavior, but adds real value over 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?

Compact and front-loaded: the core action and returned fields come first, followed by two short caveats. Every clause carries information, though the parenthetical byte-unit aside ('1024³ 字节') is more detail than an agent needs for invocation.

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, the description need not explain return values, and annotations cover the read-only safety profile. The remaining gap is usage context (when this beats list_instances), but for a single-parameter read tool with a documented output schema, what is provided is nearly complete.

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% for the single instance_uuid parameter, so the description must compensate. It only implies that the UUID identifies the target instance ('指定 UUID 的实例状态'), with no format, source, or lookup guidance (e.g., where to obtain the UUID), so compensation is partial.

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 specific verb (查询/query) and resource (instance status and configuration specs) and enumerates exactly which fields are returned: GPU model, per-card VRAM in GB, and allocated CPU cores. This is specific enough that an agent can tell it apart from job_status and list_instances without opening a schema, though it never names those siblings explicitly.

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

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

There is no when-to-use guidance: no statement of when to call instance_status versus list_instances (which also surfaces instance information) or job_status. The description only says what it returns, leaving the selection decision entirely to inference from the UUID parameter.

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 safety is covered. The description adds useful semantic detail about return fields, especially next_retry_in_seconds rounding and null behavior, which goes beyond the structured 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?

Two sentences are front-loaded with the primary purpose and then add targeted semantics for next_retry_in_seconds. No filler or redundancy.

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

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

The tool is simple, read-only, and has an output schema, so full return documentation is unnecessary. However, the missing job_id guidance and lack of differentiation from wait_for_job leave gaps for correct agent selection and invocation.

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

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

Schema description coverage is 0% and the single required parameter (job_id) is not explained in the description. The name job_id implies an identifier, but the definition does not state where it comes from, what format it has, or whether it refers to a power-on/switch job specifically.

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

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

The description uses a specific verb (查询) and names the resource (当前进程中的开机/切换任务) along with the fields returned. It distinguishes this status-query operation from write-oriented siblings like power_on and cancel_job, though it does not explicitly contrast with wait_for_job.

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 explicit guidance on when to use job_status versus wait_for_job or cancel_job. The implied context is checking a job's current state, but no when/when-not or alternative routing is given.

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 safe read (readOnlyHint=true, destructiveHint=false), and the description adds real value on top: batch size limit, shared pagination, per-item error reporting, the price=null caveat, and an explicit statement that credentials are never returned. The price-null and credential notes are non-obvious behaviors not derivable 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?

Purpose is front-loaded, and the four short clauses (scope, return shape, price caveat, security note) are each informative and free of filler. Dense but well-structured.

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, the description need not enumerate return fields, and it still flags the notable ones (instances, errors, price=null) plus a security exclusion. For a one-parameter read tool this is essentially complete; only the sibling-routing hint is absent.

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 single parameter is named only in the schema (0% description coverage), and the description's '1–100 个实例 UUID' restates the minItems/maxItems constraints already present in the schema. It does confirm these are UUIDs, adding slight meaning, but does not go beyond the schema.

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

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

States a specific verb (批量查询/batch query) plus resource (实例 UUID) and the fields returned (状态和硬件规格), which is more than a restatement of the name. It does not, however, explicitly distinguish itself from the sibling instance_status, so the batch-vs-single distinction must be inferred from '1–100 个'.

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 '批量查询 1–100 个实例 UUID' framing implies the batch use case, but there is no explicit when-to-use/when-not guidance and no mention of the alternative instance_status for single lookups. Usage is inferable but not 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 flag destructive=true and idempotent=true, but the description adds real value beyond them: it discloses that running tasks are interrupted (what is destroyed), that pending power-on retries are cancelled first, and critically that the call returns an acceptance result rather than the final state (async semantics). That async note is exactly the kind of behavior the annotations cannot express.

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 led by the verb, with no filler. The two parenthetical clauses are dense but each carries distinct information (task interruption and the retry-cancellation side effect).

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 detailed, yet the description usefully clarifies the async acceptance semantics. For a destructive one-parameter mutation it covers the important behavioral edges, with the only gap being no explicit sibling routing.

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

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

Schema description coverage is 0% and the single instance_uuid parameter is left unexplained by the description. The parameter name is fairly self-evident, so this reaches the minimum-viable bar, but the description does nothing to compensate for the missing schema documentation (e.g. format or where the UUID comes from).

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 (关机/power off) and adds the crucial scope that it interrupts running tasks on the instance. It also contrasts behavior with the power-on path by noting it cancels boot retries, which helps against power_on/power_on_no_gpu, though it never names those siblings explicitly.

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

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

The description describes what happens on invocation but gives no guidance on when to choose power_off versus siblings like switch_mode or cancel_job, nor any prerequisite or exclusion. Usage must be inferred.

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 is a non-read-only, idempotent, non-destructive operation. The description adds genuinely new behavioral context beyond that: the call incurs billing, out-of-stock triggers continuous background retry, and the return is immediate with a task ID rather than a completed power-on.

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 compact sentence front-loads the action and UUID, then adds the two most decision-relevant facts (billing, async retry/return). 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 for the returned task ID, so return shape needn't be explained, and annotations cover the safety profile. The description supplies the billing, retry, and async traits an agent needs; only an explicit pointer to the job-tracking siblings 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?

There is a single required parameter with 0% schema description coverage, so the description carries the burden. It indicates the UUID selects the target instance but gives no format, source, or constraint details (e.g. where to obtain the UUID), so it only marginally compensates for the 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: power on the instance identified by the given UUID. It also conveys scope (billing, async task creation). It does not explicitly name the sibling power_on_no_gpu, so the agent must infer which power-on variant to pick from the name alone.

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 context is implied rather than stated: the immediate task ID return signals an async workflow whose result must be polled (job_status/wait_for_job), but those alternatives are never named. No explicit when-not or prerequisite guidance is given.

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 non-read-only, idempotent, non-destructive, but the description adds genuinely new behavioral facts: billing continues despite no GPU, the call returns a background job ID immediately (async), and the instance must be powered off first. These are exactly the side effects and timing semantics annotations cannot express.

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?

Dense and front-loaded: the mode and billing caveat come first, then eligibility, then the async-return fact, then the precondition. Every clause earns its place, though the negation clause could be tightened slightly.

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 spelled out; the description nonetheless signals the immediate background-job-ID return. With eligibility, billing, precondition, and async behavior covered, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 0% for the single instance_uuid parameter, so the description technically adds no parameter-level detail. However the parameter is a single, self-evidently named required identifier, so the practical gap is small; 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+resource+mode: power on in no-GPU mode. It explicitly distinguishes itself from the plain power_on sibling by scoping to 无卡模式 and clarifying that it will not switch an already-running GPU instance, so an agent can tell the two apart without opening schemas.

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 eligibility (仅支持按量计费实例) and an explicit when-not plus precondition (不会自动将已运行的 GPU 实例切换为无卡模式，请先关机并确认状态). This is precisely the routing/precondition information an agent needs before choosing between this and power_on/switch_mode.

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 readOnly=false, destructive=true, idempotent=true. The description adds substantial context beyond that: interrupting running tasks, billing on restart, mandatory confirmation, the pay-as-you-go constraint for non_gpu, non-rollbackable semantics, possible stuck-shutdown state with no auto-recovery, and no cross-restart task persistence.

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 action and return value, then stacks consequences and caveats. Dense and largely waste-free, though the semicolon-chained warnings make it slightly hard 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 destructive, multi-step mode-switch with an output schema present (returns a background task ID, already mentioned), it covers the operational caveats, confirmation requirement, and failure modes an agent needs before invoking. Nothing material 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 compensate. It adds the meaningful constraint that the non_gpu target only supports pay-as-you-go billing, but instance_uuid and the gpu/non_gpu syntax/behavior are otherwise left to the schema enum and default.

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 precise verb+resource (switch GPU/non-GPU mode) and spells out the composite steps it performs: shut down, confirm shutdown, reboot into target mode. An agent can distinguish it from power_on/power_off purely from the description.

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?

Clear context on when this applies (switching modes rather than a simple power toggle) plus a hard precondition ('执行前必须确认'). It implies it replaces the separate power_off/power_on siblings but never names an alternative or exclusion explicitly.

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?

Goes well beyond the readOnly/destructive annotations: a timeout or disconnect does not cancel the background power-on job, jobs do not survive service restarts, the capacity-shortage phase can be waited through, and 'active phase' means not finished. These are exactly the lifecycle/auth-adjacent caveats an agent needs and that 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?

Dense but front-loaded: the purpose leads, followed by parameter semantics, retry-reporting guidance, and lifecycle caveats, each sentence carrying distinct information. Slightly passive-clause heavy but 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?

For a wait/polling tool with an output schema, it covers the important non-return-value facts: capacity-phase behavior, retry snapshot semantics, non-cancellation, and restart non-persistence. Adequate; only the meaning of job_id relative to the instance lifecycle is unstated.

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?

With 0% schema description coverage, the description compensates well: timeout_seconds range (0–300), default (15), and the 0-means-immediate case, plus return_on_capacity=False semantics and next_retry_in_seconds rounding/null behavior. Only job_id is left unexplained.

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 states a specific verb and resource: read-only wait on the current job until it ends, hits a capacity shortage, or times out, returning a snapshot. This distinguishes it from immediate-return siblings like job_status, though it never names an alternative 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 usage behavior (report attempts/elapsed_seconds/next_retry_in_seconds after a shortage return; don't tightly repeat queries) and explains return_on_capacity, but offers no explicit when-to-use-this-vs-job_status/power_on routing for the agent.

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