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

Annotations establish the safety profile (not read-only, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral detail: it persists stop reasons and explicitly issues no financial requests and performs no re-query/budget restoration. That complements rather than repeats the annotations, and there is no contradiction.

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 clauses, front-loaded with the action and its effect, then the invocation timing, then the exclusions – no filler. The density of jargon ('自然余额', '旧核实预算') costs some immediate legibility but 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?

With an output schema present, return values need no explanation, and the description covers what the tool does, when to invoke it, and where its side effects stop. For a zero-parameter but mutating tool, this is adequate; only the missing explicit sibling routing keeps it from a 5.

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 baseline there is no parameter semantics to document and the description cannot add value here. A 4 reflects the neutral baseline for an argument-less 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 concrete verb (复核) plus the resources reviewed (natural balance/bill/structure) and the side effect (persisting stop reasons), which is more than a restatement of the name. The negative clauses ('does not re-query old numbers or restore old verification budgets') implicitly separate it from the qianji_recovery_* siblings, though no sibling is named 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 explicit call timing – at start, at batch end, and at shift handover – which is real usage context. It also sketches the boundary of non-use (no financial requests, no re-querying old numbers), but it never names an alternative tool such as qianji_recovery_ack or qianji_query, so routing still requires 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, destructiveHint=false and openWorldHint, so the safety profile needs no restating. The description adds genuinely useful context beyond them: the capability list reflects only what the current code exposes, and presence of an operation does not mean all its parameter combinations have been validated. It stops short of saying anything about how large or fresh the list is.

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 the scope stated first and the interpretive caveat second. Every clause earns its place 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?

An output schema exists, so return values need no explanation, and with zero parameters the description only has to establish purpose and the caveat about unvalidated combinations, which it does. A brief pointer that this should precede invoking other qianji tools would have closed the remaining 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?

The tool takes zero parameters, so the description carries no parameter burden. Baseline of 4 applies; nothing in the description contradicts or misrepresents the empty 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+resource: lists the operations exposed by the current code plus their limitations. That is clearly distinct from action-oriented siblings like qianji_execute or qianji_query. It does not, however, explicitly name those siblings to sharpen the contrast.

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 statement of when to call this versus qianji_connection, qianji_query, or the other siblings. The second clause is a caveat about interpreting results rather than routing guidance, so the agent must infer that this is a pre-flight discovery step.

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, and openWorld behavior. The description adds one useful constraint—no account/login information is returned—but does not cover auth needs, latency, rate limits, or result interpretation. With annotations covering safety, this is a modest addition.

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 a semicolon separating purpose from output constraint. No wasted words.

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

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

Given the simple no-parameter operation, rich annotations, and an output schema, the description is complete enough: it states what is checked and what is not returned. No additional behavioral or return details are required from 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none 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?

The description states a specific check: verifying whether the official App login state can be read in the background, and clarifies that no account or login data is returned. It is clear but does not name a sibling tool, so sibling differentiation is only implicit via the privacy note.

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 explicit guidance on when to use this tool versus alternatives like qianji_account_review or qianji_query. The diagnostic purpose is implied but there is no instruction about prerequisites or when-not-to-call.

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?

With annotations already declaring destructiveHint=true, idempotentHint=true, and readOnlyHint=false, the description still adds valuable behavioral context: user authorization is required, idempotency is achieved through a stable request ID, and post-success native read-back verification is mandatory. It does not detail what side effects occur or how failures are surfaced.

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 separated by semicolons. Every clause carries operational meaning: authorization, idempotency, and verification. 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?

For a complex destructive execution tool with a 50+ action command schema, the description covers key workflow constraints (authorization, idempotency, read-back verification) and the output schema handles return values. However, it omits sibling routing guidance such as using preview before execution or operation_status afterward, which matters for safe 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 reported as 0%, so the description must compensate, but it only explains request_id semantics ('稳定请求编号防重复'). The command parameter and its large action enum are not described at all, leaving the agent to rely entirely on the nested 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?

The description states a specific verb and resource: '执行...记账指令' (execute bookkeeping commands). It is clearly a mutation/execution tool rather than a query or preview, but it never names or distinguishes itself from siblings like qianji_preview or qianji_query.

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 usage context: commands must already be user-authorized, a stable request_id prevents duplicates, and success must be verified via native read-back. It does not state when not to use this tool or explicitly route agents to qianji_preview/qianji_operation_status before or after execution.

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, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuinely useful context beyond them: it will not resend the write request, directly addressing the duplicate-write risk an agent would worry about. It does not mention pagination or latency, hence not 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?

A single tight sentence split by a semicolon: capability first, then the key reassurance. Nothing redundant, nothing 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?

An output schema exists, so return values need not be described, and the read-only/no-resend behavior is well covered. However, the undocumented 'automatic' input parameter and the 0% schema coverage leave a real gap 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 0% for both parameters, so the description carries the full burden and fails it: neither 'request_id' nor the 'automatic' flag is mentioned or explained. An agent gets no guidance on where request_id comes from or what 'automatic' changes.

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: query and verify the native result of a pending ('待核实') operation. The clause '此调用不会重发写请求' implicitly distinguishes it from write-oriented siblings like qianji_execute, but no sibling is named 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 phrase '待核实操作' implies the usage context (there is a pending operation to confirm), which is adequate but implicit. It does not state when to prefer this over siblings such as qianji_recovery_list or qianji_query, nor any prerequisites.

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 不发写请求 largely restates structured data and earns no credit. The genuinely additive piece is that preview is not a mandatory manual-approval step, which is one real workflow disclosure but nothing about validation failure modes or what a preview returns.

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 (two clauses joined by a semicolon), with the core purpose front-loaded and the optionality caveat appended. Nothing is padded or repeated.

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, and annotations cover the safety profile. But for a tool whose command spans dozens of actions and a large nested schema, the description is thin: it omits how validation errors surface, what 'balance impact' means concretely, and any link to the execute sibling.

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 top-level command parameter with 0% schema description coverage at that level, though the nested Command object carries its own field descriptions (fee, time, amount, object_id, etc.). The description only hints at 'commands and references' and adds no meaning about the command structure or the 50+ action enum, 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 gives a specific verb pair (校验/预览 = validate/preview) plus resources (指令与引用, 余额影响), and rules itself out of the write path with 不发写请求, which implicitly distinguishes it from qianji_execute. It is clear but never names the write 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?

The note 预览不是强制人工审批 clarifies that using preview is optional and not a mandatory approval gate, which is useful workflow context. However it never states the positive when-to-use case (e.g. run before qianji_execute) nor any exclusions, leaving usage 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 establish readOnly/idempotent/non-destructive/openWorld, so the bar is lower, and the description still adds genuinely useful behavior: IDs and monetary amounts are strings, returned objects carry a version used for later modify/delete, and the date upper bound (until) is exclusive. The exclusive-bound gotcha in particular is not derivable from the schema and prevents off-by-one range errors.

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 semicolon-separated clauses, purpose front-loaded, no filler. It is efficient and well-ordered, though the terseness edges into under-specification rather than optimal density.

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-value explanation is not owed, but the tool's surface is large (nine kinds, eleven filter fields, zero schema descriptions) and the description covers almost none of the selection logic an agent needs. For a tool this broad, a query-language overview of kinds and filter applicability 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%, and the tool is not parameter-light: one required enum with nine kind values plus a Filters object with eleven undocumented fields (limit, offset, since, until, status, keyword, book_id, object_id, account_id, category_id). The description clarifies only that IDs/amounts are strings and that dates are upper-exclusive; it never explains which filters apply to which kind, pagination semantics, or the status enum.

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 opens with a clear verb (查询/query) and names resources (原生对象、账目与任务), so the operation is identifiable. However, the resource naming is loose and does not map to the nine concrete kinds in the enum (books, accounts, categories, bills, installments, etc.), and no sibling is named, so an agent cannot tell it apart from qianji_preview or qianji_execute from the text 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?

There is no statement of when to use this tool versus the read-oriented siblings (qianji_preview) or the mutating one (qianji_execute). The only oblique guidance is 'version供修改/删除使用', which hints that returned version values feed modify/delete calls, but it never says which tool consumes them or under what conditions.

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 idempotent=true, destructive=false, readOnly=false. The description adds useful scope context that mutation only touches recovery metadata and that unknown-state cases cannot be closed, but it does not explain expected_version semantics (optimistic concurrency), permission requirements, or failure 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?

Short and front-loaded: the precondition leads and the scope constraint closes. Every clause carries meaning, though the terse, semicolon-chained phrasing is somewhat cryptic for a reader unfamiliar with the domain.

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, and the preconditions are covered. However, for a 4-parameter mutation with 0% schema coverage, the absence of any parameter-level explanation leaves the definition only minimally adequate.

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% across 4 required parameters (request_id, expected_version, disposition, completion_reference) with no schema descriptions. The description loosely gestures at '处置' (disposition) but does not explain any parameter's meaning, format, or the enum values, 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 conveys a specific action ('确认收尾' – confirm closure of the recovery case) conditioned on the original result being verified, and scopes the effect ('只改恢复元数据'). It is more than a restatement of the name, though the verb is implied rather than stated outright, so a 4 rather than 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?

It gives explicit preconditions for use (result already investigated, caller has continued the ledger/disposition) and an explicit exclusion ('未知不能关闭' – unknown state cannot be closed). It stops short of naming sibling alternatives such as qianji_recovery_list or qianji_recovery_scheduler, so it does not reach 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, openWorldHint=true and destructiveHint=false, covering the safety profile. The description adds the useful guarantee '无金融发送' (no financial sending), but says nothing about pagination behavior despite limit/offset parameters existing.

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 tight sentence with the purpose front-loaded ahead of the call-cadence note. No filler, though it is compressed to the point of omitting parameter detail.

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, and annotations cover safety, so the description only needs to cover purpose, usage and params. Purpose and cadence are covered, but pagination and the include_closed toggle are absent, which is a real gap for a listing 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% and none of the three parameters (limit, offset, include_closed) is mentioned anywhere in the description. Low coverage requires the description to compensate, and it does nothing here, leaving include_closed's effect on results entirely unstated.

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: it lists persistent items pending verification and pending closure (列出持久待核实及待收尾事项). This is clear and distinguishable from recovery_ack (which acknowledges) and recovery_scheduler, though it does not explicitly name those 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?

It gives concrete when-to-use triggers: at the start of checks, at the end of each batch, and for scheduled follow-ups (检查开始、每批结束和定时跟进均调用). No when-not-to-use or named alternative is offered, but the invocation cadence is explicit.

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 idempotentHint=true and destructiveHint=false, and the description adds real scope context by clarifying it never creates/cancels host tasks or sends financial requests. It still leaves unexplained what the 'record' mutation actually does or what authorization/side effects it carries, which matters since readOnlyHint=false.

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 two capabilities front-loaded and the negative scope trailing, with no filler. It is compact, though its abstract vocabulary makes it slightly harder to parse than plain wording would be.

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 and annotations cover the safety profile, so return values and safety need not be restated. But for a tool whose 'record' path writes an observation object, the description omits the semantics of both the action and the observation payload, leaving a meaningful 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 parameter meaning. It loosely gestures at the two actions but never explains the 'action' enum values, and it says nothing about the nested observation fields (expected_generation, mode, observed_state, observation_reference), leaving the write path opaque.

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 two concrete capabilities (read the scheduling intent, register host readback) that map onto the action enum, and it delineates the tool from task-mutating siblings by stating it does not create/cancel host tasks. The resource labels are somewhat abstract ('唯一调度意图', '宿主正规回读'), but an agent can tell it is a read/registration tool and not the create/cancel 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 a useful 'when-not' boundary (does not create/cancel host tasks, does not send financial requests), which steers the agent away from misuse. However, it never names which sibling to use instead (e.g. qianji_recovery_list vs qianji_recovery_ack) or states the condition that selects status vs record.

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