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

No annotations are provided, so the description must carry the full burden. It conveys a create/insert side effect and lists required fields, but does not disclose persistence, validation, duplicate behavior, permissions, or failure behavior. For a mutation tool with zero annotation coverage, this is insufficient.

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: purpose first, parameter map second. No fluff, front-loaded, and easy to scan.

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?

Output schema exists so return-value documentation is not needed, but the description ignores the schema-required case_id, gives no relationship to existing volumes/cases, and provides no usage conditions or error expectations. With no annotations and an opaque args schema, this leaves too much to inference.

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 description partially compensates by enumerating the six required args fields and translating volume_name/file_name into Chinese. However, page_range, doc_type, record_time, and note lack format or allowed-value semantics, and the schema-required case_id is omitted entirely.

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 '登记' (register/add) and resource '阅卷目录（卷宗目录）一条', listing the key attributes needed. This clearly distinguishes it from sibling record_* tools by focusing on the volume catalog entry specifically.

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 guidance on when to use this tool versus alternatives. It does not mention prerequisites such as an existing case_id or volume, nor does it contrast with related tools like list_volumes/get_volume_outline. Usage context is only implied by the verb.

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 no annotations, the description carries the behavioral burden. '登记' conveys that this is a write/add operation and the parameter list conveys input expectations. However, it does not disclose side effects, validation, idempotency, prerequisites such as an existing case, or update/replace semantics, so behavior remains partly implied.

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 purpose is front-loaded and the inline args documentation is compact. It is dense but not bloated; a clearer visual separation between the purpose and the parameter spec would polish it, but no words are wasted.

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 data-entry tool with a generic args schema, the description provides enough detail to construct a valid call: it names all required fields and their meanings. It omits explicit guidance on how args relates to case_id and any validation expectations, so it is not fully 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?

The schema coverage for args is effectively 0%, so the description is the main source of parameter meaning. It compensates by enumerating index, description, volume, page_start, page_end, amount, and time_period with requiredness and brief semantics. A few fields like amount and time_period are left to inference, and the formal schema still treats args as an arbitrary object, so it is not a 5.

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

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

The description states a specific verb and resource: 登记起诉书指控的单笔事实 (record a single fact charged in the indictment). It also adds the organizational context 第三/四部分的整理依据, which helps distinguish it from sibling tools like record_indictment or add_transaction.

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: this tool is for entering individual charged facts as the basis for Parts 3/4, and it lists the expected source fields. It does not explicitly name alternative sibling tools or state when not to use it, so it stops short of a full 5.

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

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

没有 annotations，描述需承担行为披露责任。它揭示了严格一致性要求（evidence_name 完全一致）、金额需保留原文表述，以及逐笔而非汇总的登记方式。但未说明证据不存在时的错误行为、是否允许重复登记或追加、以及写入后的副作用，行为透明性仍有限。

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?

第一句直接点明用途，第二句强调核心业务规则，随后以紧凑的参数结构列出字段及必填要求。每句话都有实际价值，没有冗余内容，信息层级清晰，适合 agent 快速解析。

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?

在 0% 覆盖率且无 annotations 的情况下，描述覆盖了所有业务字段、必填性、与既有书证的关联，以及金额格式要求，整体足够支撑正确调用。不过 account、note、page 的语义仅靠字段名推测，缺少更明确解释，略微影响完整性。

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 对 args 内部字段覆盖率为 0%，描述以参数结构完整列出 evidence_name、date、payer、payee、amount、account、note、page 及必填性，并对 evidence_name 和 amount 提供额外语义约束（完全一致、保留原文表述）。这充分弥补了 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?

描述使用明确动词“逐笔登记资金流水”，限定资源为“已登记的书证”，并列举转账记录、回款、返利、工资提成等具体类型。这与 record_documentary_evidence、record_funds_summary 等兄弟工具形成清晰区分，用途明确且具体。

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?

描述明确说明银行流水类书证必须逐笔登记、不得只写汇总，划定了与汇总登记工具的使用边界；同时要求 evidence_name 与 record_documentary_evidence 登记的 name 完全一致，给出了前置条件。但未直接点名替代工具或明确“何时不要使用本工具”，因此未达满分。

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 no annotations, the description carries the full burden. It discloses the discovery/registration behavior and return shape, but omits side effects (e.g., directory creation, persistence), prerequisites, idempotency, and what the optional hint/vision parameters do. It is more informative than a bare mutation note, but incomplete.

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 two concise sentences with purpose front-loaded. The second sentence adds useful workflow context without unnecessary detail. Every part 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?

Given 5 parameters, no annotations, and no schema-level descriptions, the description leaves major gaps: optional parameter semantics and behavioral side effects are missing. It is sufficient for a default call with case_dir only, but not complete enough for reliable invocation in varied scenarios.

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 only clarifies case_dir ('发现 case_dir 下卷宗 PDF'); the other four parameters (output_dir, charge_hint, defendant_hint, vision_available) are entirely 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 description clearly states the specific action—'创建案件会话' (create case session)—and explains the core behavior: discover PDFs in case_dir, register page counts, and return a case_id with the volume list. This differentiates it from sibling tools like list_cases and start_review.

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 clearly positions create_case as the entry point for a new case session and explicitly names follow-up options ('随后可 start_review ... 或直接调用读卷/登记工具'). It does not explicitly state when not to use it (e.g., for existing cases), so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the fallback rendering behavior when the file is not yet generated and lists the supported formats. However, it does not reveal side effects, permissions, or whether the fallback rendering may be expensive or trigger writes.

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 terse, purposeful sentences. The main purpose and the fallback trait are front-loaded, followed immediately by the format specification. 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 tool's simplicity, the core purpose and formats are covered. Yet there is no explanation of the return payload, the meaning of case_id, or relationship to the generation workflow, so the definition is workable but not fully 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%. The description documents the fmt parameter with its two allowed values, but says nothing about case_id, which is the only required parameter. This leaves a key argument semantically underdefined.

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?

Diplies a clear action — download generated outputs — and specifies the two formats (docx/xlsx) plus a fallback rendering behavior. It clearly distinguishes the resource from siblings like write_outputs, though it does not explicitly name an alternative.

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 guidance on when to use this tool versus siblings such as write_outputs or get_workspace_summary. The use case is implied by the verb 'download' but alternatives and exclusion conditions are 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?

With no annotations, the description carries the full burden. The verb '查询' signals a read-only operation, and '含工作区登记计数' discloses part of what the status includes. It does not cover auth needs, failure behavior, or side effects, but for a simple status-query tool the core behavior is communicated.

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. Every word contributes either the operation, the target resource, or the included count, and nothing needs restructuring.

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 an output schema present, the description plus schema is nearly sufficient to invoke correctly. It only lacks explicit guidance on when to choose this over list_cases and any safety or permission caveats, which are minor for a query-style 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 must compensate. The phrase '案件会话' gives semantic context that case_id identifies the case session whose status is read, but the description does not explicitly define the parameter format or its relation to the workspace count. With one self-descriptive required parameter, this is adequate but not rich.

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 names a specific operation (query) and resource (current status of a case session), and adds a concrete included data point: workspace registration count. It does not explicitly differentiate from siblings like list_cases, but the status-of-a-session wording makes the tool's target clear.

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 gives no guidance about when to use this tool instead of list_cases or other case-related siblings, and mentions no exclusions or alternatives. An agent must infer the usage boundary from the tool name and the one-line description.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool renders a page to an image and is intended for visual extraction, but it does not describe response format, size limits, or whether any persistent state changes. The read-only nature is implied rather than explicit.

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 compact sentences: one for purpose, one for downstream workflow, and one for parameter structure. It is front-loaded and contains minimal fluff, though the parameter block could be more tightly integrated with the 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?

For its intended visual-recognition purpose, the description covers the core information: what the tool does, when to use it, and how to follow up. It falls short by not mentioning case_id, not explicitly contrasting with read_pages, and leaving the exact output image format to the output schema rather than giving any guidance here.

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 description adds meaningful parameter semantics by defining volume and page with required flags and specifying page is 1-based, which the input schema does not document. However, it omits case_id, the only top-level required parameter in the schema, and the schema's args object is unconstrained, creating a mismatch that could cause incorrect invocation.

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: render a specified page as an image and return it for visual recognition when scanned documents lack a text layer. It clearly distinguishes its purpose from text-based reading tools by emphasizing the 'see the image' workflow and subsequent record_* registration.

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 use case: scanned documents without a text layer, and instructs the model to visually extract information then register it via record_* tools. It does not name an alternative like read_pages or state when not to use this tool, but the context is clear enough.

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 no annotations provided, the description carries the full burden. It usefully discloses a key behavioral trait: there is no background job. However, it does not describe whether the call is read-only, how progress is represented, or what the response contains beyond what the output schema already provides. The disclosure is helpful 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?

The description is compact, front-loaded with the primary purpose, and every clause carries useful information: what the tool queries, that there is no background job, and how to relate it to get_case_status. There is no filler or repetition.

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 simple one-parameter query tool with an output schema, the description is mostly sufficient. It identifies the purpose, the key behavior, and the relevant sibling. The main gap is that it does not clearly define what get_review_progress itself returns versus what get_case_status provides, but the output schema and explicit pointer to get_case_status mitigate this.

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 schema has one required parameter, case_id, but schema description coverage is 0% and the description adds no explanation of the parameter. The name is somewhat self-explanatory in context, but the description does not compensate for the low schema coverage by explaining how case_id is used or any constraints on it.

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 clear verb ('查询' / query) and resource ('阅卷进度' / review progress), and explicitly distinguishes itself from the sibling get_case_status by stating that there is no background job and that host execution progress should be judged via get_case_status's section_counts. This gives an agent a precise idea of what the tool does and what it does not do.

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 explicitly mentions an alternative, get_case_status, and explains that its section_counts field should be used to determine host execution progress. It also warns that there is no background job. It could be stronger by stating exact conditions for when to prefer get_review_progress over get_case_status, but the guidance is clear and actionable.

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?

No annotations are present, so the description must disclose behavior itself. It does so by describing the read-only nature ('获取', '概览') and the exact return content (word count and first line per page). It does not discuss rate limits or error cases, but those are secondary for a simple read-only outline tool.

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 compact and front-loaded with the purpose; the parameter-structure note is necessary given the empty schema. It earns its place, though embedding the param block in prose makes it slightly dense.

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

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

Although an output schema exists and need not be described, the input contract is incomplete: the required case_id top-level parameter is never mentioned, and max_pages semantics are underspecified. An agent would need to reconcile the description with the schema and still guess at max_pages behavior.

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 schema provides no descriptions for case_id or args, so the description's definition of the args object ({volume, max_pages}) adds real value. However, it omits case_id, which is required by the schema, and does not explain the meaning of max_pages beyond its name.

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 action and output: '获取某卷的逐页概览（每页字数 + 首行内容）'. It clearly distinguishes this from siblings by naming read_pages as the subsequent detailed-reading step, so an agent can tell which tool to pick.

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 gives explicit workflow context: use it in large volumes to locate document boundaries, then decide which pages to read with read_pages. It lacks explicit conditions for when not to use alternatives, but the intended use case is clear.

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 no annotations provided, the description carries the behavioral burden. The verb '查看' (view) clearly indicates a read-only operation, and it specifies the returned content: counts of registered records and basic case information. It does not mention auth requirements or rate limits, but for a low-risk summary query this is reasonably transparent.

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 terse and front-loaded, but the second sentence contains misleading parameter information that does not earn its place. The content is not verbose, but the inaccurate structural note detracts from the usefulness.

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?

Even though an output schema exists, the description omits the required case_id parameter and provides no usage guidance relative to get_review_progress. An agent could still invoke the tool correctly by inspecting the schema, but the description alone is incomplete and partially misleading.

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 only parameter-related text, '参数结构（args 字段）: {}', is misleading or inaccurate because the input schema requires a top-level case_id string and schema description coverage is 0%. The description fails to compensate for the schema gap and actually obscures the single required parameter.

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 the tool's verb and resource: it views progress for the current grading workspace, including registered record counts per section and basic case information. It is specific enough to be understood, but it does not differentiate itself from the sibling get_review_progress, whose name suggests overlapping functionality.

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 gives no guidance on when to use this tool versus alternatives such as get_review_progress or get_case_status. There is no mention of preferred conditions, exclusions, or which sibling to choose instead.

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?

No annotations are present, so the description carries the full burden. '列出全部案件会话及状态' conveys that this is a read-only listing action and that the scope is all sessions with their statuses, but it does not disclose pagination, auth requirements, rate limits, or performance implications of returning all cases.

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 sentence with no filler. The verb and resource are front-loaded, so an agent can grasp the tool's function at a glance.

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 simple zero-parameter list tool with an output schema available, the description is sufficiently complete: it states what is returned (all case sessions and their statuses) without needing to document parameters. The only notable gap is usage guidance, which is minor for a low-risk read-only 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?

The tool has zero parameters and schema description coverage is 100%, so there is no parameter meaning for the description to clarify. The phrase '全部' reinforces the no-filter/no-parameter behavior, meeting the baseline for a 0-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?

The description uses a specific verb (列出/list) and a specific resource (全部案件会话及状态/all case sessions and status). It clearly distinguishes list_cases from siblings like list_volumes and get_case_status by naming case sessions and their statuses rather than volumes or individual case status.

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

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

No when-to-use or when-not-to-use information is provided. There is no mention of alternatives such as list_volumes, get_case_status, or search_volumes, and no condition under which the agent should prefer another sibling.

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 no annotations, the description carries the full burden. It clarifies that the tool is a read-only listing operation and the kind of data returned, but it does not mention potential size limits, ordering, empty-case behavior, or whether it simply summarizes all volumes. Basic transparency is present, but behavioral depth is limited.

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 core description is concise and front-loaded. However, the third sentence about arg structure adds no value, obscures the real required parameter, and could mislead an agent. Overall length is appropriate but the structure is weakened by that misleading parameter note.

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 description explains the purpose well but is incomplete for invocation: it omits the required case_id parameter entirely. While an output schema exists and the tool is conceptually simple, lacking mention of the one required input means the agent cannot reliably call 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 schema requires a case_id, but the description does not mention it at all. The only parameter-related text says '参数结构（args 字段）: {}', which is misleading because args is optional and can be any object or null, while case_id is the actual required input. With 0% schema description coverage, this is a critical 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 action and resource: listing all volumes in the case, with the exact fields returned (volume name, file name, total pages). It does not explicitly differentiate from siblings like get_volume_outline, but the scope '全部卷宗' and the listed output fields make the purpose clear.

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 explicitly says this should be called first when reviewing a case, which is clear usage guidance. However, it does not mention when not to use it or how to choose between it and related tools like search_volumes or get_volume_outline.

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?

No annotations are provided, so the description carries the behavioral burden. It discloses automatic OCR handling for scans/garbled pages, the needs_ocr sentinel, and the fallback options. It stops short of confirming read-only/no-side-effects behavior or error handling for invalid volumes/ranges, but the main behavioral surprises are covered.

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?

Every sentence carries operational value: main action, OCR behavior, explicit fallback condition, citation rule, and a clear parameter block. The structure is dense but well-organized and not padded.

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 read tool with no annotations, this covers purpose, OCR behavior, fallback routing, citation requirements, and parameter constraints; the presence of an output schema covers return-format details. The missing case_id mention and lack of invalid-input/error behavior keep it from being fully 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?

The description adds rich meaning to volme, start_page, and end_page: requiredness, 1-based inclusive semantics, and where valid volume names come from. However, it omits the top-level required case_id that appears in the input schema, and the schema's args is free-form, so the exact mapping between description and invocation structure is not fully seamless.

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: read a page-range from a named volume, with each page labeled by page number. It also differentiates from get_page_image by framing that tool as the OCR-failure fallback, and from list_volumes/search_volumes as the source and search prequels.

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

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

Explicitly says when to use read_pages (whenever text from a volume page range is needed) and when not to: only switch to get_page_image when a page still shows needs_ocr. It also references list_volumes for valid volume names and gives a required citation format.

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?

注释中没有任何行为提示，描述本身只列出了要登记的内容字段，未说明该操作是新增、覆盖还是更新，也未说明是否依赖 case_id、是否校验数据或产生副作用。对于无注释的写入类工具，行为透明度明显不足。

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?

描述仅用两句话完成：第一句说明用途和内容，第二句说明参数结构，没有任何冗余信息，信息密度高且结构清晰。

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?

工具位于包含多个 record_* 工具的大兄弟集合中，且无注释辅助；描述未说明 case_id 的必填性、调用时机、写入行为或与现有案件的关联方式。对于这类有多个相似工具的记录类操作，描述不够完整。

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 描述覆盖率为 0%，描述虽然补充了 args 字段结构及必填标记，但忽略了 schema 中必填的 case_id，并且描述声称 args 内字段“必填”而 schema 将 args 本身设为可选，造成理解上的不一致。参数语义部分补偿不足且存在误导风险。

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?

描述以明确的动词“登记”和对象“阅卷结论”开头，并列出核心事实、证据链条、矛盾点、待核查疑点四项具体内容，使工具用途清晰可辨。虽然没有明确与同组 record_* 工具作区分，但内容本身足以让代理识别其用途。

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?

“供后续辩护意见参考”暗示了该工具用于阅卷后整理结论，但并未说明何时应使用它而不是其他 record_* 工具，也没有给出替代工具或排除条件。使用场景属于隐含而非明确说明。

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?

There are no annotations, so the description must carry the behavioral burden. It does disclose required fields, fact_group grouping, and the add_transaction follow-up. However, it does not state whether this creates a new record or updates an existing one, what permissions are needed, or how fact_group is validated.

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 compact and front-loaded: purpose first, workflow condition second, parameter list last. The param list is dense but readable enough; a bullet structure would be slightly better for scanning.

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 details need not be repeated. The description covers the main arguments and the most relevant sibling interaction. The missing case_id mention and the ambiguity around args being optional/nullable are the main gaps.

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 schema's args is an open object with 0% schema coverage, and the description compensates well by listing every expected args field and marking them as required. It still omits the top-level case_id parameter and does not clarify that args is nullable with a default in 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?

The description clearly states the action and object: “登记书证（第七部分，客观证据）”, so an agent knows this tool registers documentary evidence. It also differentiates its scope from add_transaction for financial-flow details, though it does not explicitly contrast with every sibling record_* tool.

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 rule: register documentary evidence first, then use add_transaction for each transfer/流水 item when present. That is a concrete routing condition to an alternative tool, though it does not discuss when to avoid this tool in favor of other record_* siblings.

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?

No annotations are present, so the description carries the full burden. It adds useful behavioral detail about who computes the numbers and the mandatory note for discrepancies, but it does not disclose whether repeated calls overwrite existing summaries, what side effects occur, or any permission requirements for this write operation.

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 two concises paragraphs: purpose and context first, then the args structure. Every sentence contributes useful information, and there is no filler or redundant repetition of the 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?

An output schema exists, so return-value description is unnecessary. The description provides the missing inner args structure and the procedural context around evidence synthesis. The main gap is a slight mismatch with the formal schema, which allows args to be null while the description implies all inner fields are mandatory, plus no idempotency guidance.

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 schema provides 0% description coverage and defines args only as an open object, so the description compensates strongly by listing the exact keys and marking each as required. It also maps the keys to their business meanings (报案合计, 合同合计, etc.). It stops short of a 5 by not giving explicit types or edge-case handling for these amounts.

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 action — recording the funds reconciliation summary — and lists the six key monetary figures it captures, so the resource is unambiguous. It distinguishes itself from sibling record_* tools by focusing uniquely on this summary, though it does not explicitly name an alternative.

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 clear precondition: the conclusionist must call it after synthesizing all documentary evidence and transcripts, and must explain any inconsistency across figures in the note. This is solid context but it does not explicitly address when not to use this tool or name alternatives.

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?

There are no annotations, so the description carries the full burden. It discloses the important behavioral rule that full_text_summary must copy the alleged facts verbatim and hints at a multi-part workflow. However, it does not explain whether the tool creates, appends, or overwrites records, or whether an existing case context is required, leaving some behavioral ambiguity.

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 front-loads the purpose and the key full_text_summary instruction, followed by an organized parameter list. The parameter list is long but necessary given the empty schema; there is no filler or redundancy that could be removed without losing value.

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?

While the args fields are thoroughly documented, the description omits any mention of the top-level required case_id property shown in the schema. It also does not clarify what '第二部分' refers to or which sibling tool performs the first part. An agent following the description alone might not construct a valid invocation, making the description incomplete for reliable use.

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 input schema provides essentially no parameter descriptions (0% coverage; only a generic args object and a required case_id). The description's parameter structure block fully documents every args field with requiredness and semantic meaning (doc_type, volume, page ranges, defendant, charge, etc.), completely compensating for the schema's lack of detail.

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 '登记' with a specific resource '起诉书/起诉意见书内容（第二部分）', and further clarifies a special requirement for full_text_summary. This clearly distinguishes it from sibling tools like record_party, record_statement, and add_charged_fact, which target different entity types.

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 clearly identifies the scenario: registering indictment/prosecution opinion content, specifically the second part. It does not explicitly name alternative tools or exclusions, but the resource specificity and the '第二部分' marker provide sufficient context for when this tool should be used.

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?

No annotations are present, so the description must carry the full burden of explaining behavior. '登记' signals a write operation, and the field list names what data is captured, but the description does not disclose whether this creates or updates a party record, what validation happens, whether duplicates are rejected, or what side effects occur. This is under-disclosed for a mutation tool.

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 purpose is front-loaded, and the long parameter block earns its place because the schema provides no parameter descriptions. The inline brace-list is slightly dense and repeats 必填 many times, but there is no fluff or irrelevant content.

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 description gives the data shape and one key business rule, and an output schema reportedly exists, so return-value details are not required here. But it leaves gaps: what '第一部分' means, whether all fields are truly required for non-duty-crime cases, and how this tool fits into the larger workflow with so many sibling record_* tools.

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

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

The formal input schema leaves 'args' as an untyped object with additionalProperties allowed and zero description coverage. The description fully compensates by enumerating all 14 expected fields with Chinese labels, marking each as 必填, and adding the duty-crime special requirement. This is exactly the parameter guidance the agent needs.

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 phrase '登记当事人基本情况' names a concrete action (登记/record) and a concrete resource (当事人基本情况/party basic information). This makes the tool's purpose immediately clear and naturally distinguishes it from sibling tools like record_indictment, record_statement, or set_case_basic.

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 gives a conditional usage rule for duty-crime cases ('职务犯罪须填 position 与 appointment_history'), which helps the agent know when those extra fields are needed. However, it does not explicitly say when to choose this tool over the many sibling record_* tools, leaving tool-selection guidance mostly implicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. It explains what data to include but not how the tool behaves on invocation, such as whether it appends, overwites, validates, or has side effects. As a write operation, this is a significant gap.

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 organized into purpose and parameter structure, with no wasteful filler. The long enumerations are justified because the schema does not document the nested args. It could be tighter, but it is dense and scannable.

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 tool with an opaque args schema, the description gives enough information to construct a correct call: case_id comes from the schema, args structure comes from the description, and an output schema is present. It lacks some workflow/order context, but the essential invocation details are covered.

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 input schema leaves args as an opaque free-form object with no property documentation. The description fully compensates by enumerating every expected field, marking required ones, listing doc_type options, and explaining the semantic content of the args object.

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 the verb '登记' and the resource '程序性文书', with a defined scope ('从被调查至当前'). It is specific enough to distinguish it from evidentiary or indictment tools, though it does not explicitly name any sibling for 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?

The scope statement implies this tool is for registering procedural documents across the case timeline, but it gives no explicit when-to-use versus when-not-to-use instructions. With many record_* siblings available, explicit alternative routing would be valuable.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states mandatory extraction fields (record time, investigators, location, AV-recording flag, content) and the hard requirement that full_text be a verbatim transcript, marking summary-only registration as incomplete. This is substantial behavioral context, though it stops short of describing response behavior or side effects.

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 dense and well-structured: a one-sentence purpose, a requirements sentence, and a compact parameter block. Every sentence carries necessary information with no filler. Slightly long, but justified by the number of required fields and the verbatim rule.

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 tool's complexity (13 required parameters, no annotations, no visible output schema details), the description provides the core operational requirements, parameter list, and a critical completion criterion. It does not mention invocation mechanics (case_id/args nesting) or error conditions, but those are partly covered by the input schema, so the description is largely complete for an agent to invoke 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 coverage is 0%, but the description compensates by listing all 13 args fields with required flags, including the role enum values and explanations for person and role. It lacks explicit types or formats (e.g., date format for record_time, boolean for has_av_recording, meaning of occasion), but is far richer than the near-empty input 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 opens with '登记供述/辩解或证言' (record statements/defenses or testimony), naming a specific verb and resource. It further distinguishes itself from siblings by enumerating roles (defendant/codefendant/witness) and requiring verbatim Q&A transcription, which clearly separates it from record_party, record_indictment, and record_documentary_evidence.

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 when to use the tool (whenever a statement, defense, or testimony must be registered) and emphasizes that full_text must contain verbatim Q&A, with summary-only entries considered incomplete. However, it does not explicitly mention alternatives or exclusions, leaving the agent to infer the boundary versus sibling recording tools.

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 no annotations, the description carries the burden of explaining behavior. It does disclose that results include hit volume/page numbers and context snippets, which is helpful. Yet it does not mention matching semantics, case sensitivity, pagination, limits, or whether the search is scoped to a specific case, leaving important behavioral details unspecified.

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 short and front-loaded with the core function before the parameter structure. It wastes few words, though the parameter section is incomplete and inaccurate, which slightly reduces its effectiveness.

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 description is not complete enough for reliable invocation. It fails to mention the required case_id parameter, contradicts the actual schema regarding required fields, and does not clarify how the args object should be composed. These are significant gaps for an agent trying to call the tool 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%, so the description must compensate. It does document the intended args shape with query and volume, including examples. However, it omits the top-level required case_id field and claims volume is required even though the schema marks args as optional/nullable, creating a direct contradiction with the input schema that can mislead an 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?

The description clearly states the tool searches within case files and returns matching volumes, page numbers, and context snippets, with a concrete use case of locating all occurrences of a fact or person. It is distinguishable from siblings like list_volumes and read_pages, though it does not explicitly name them as alternatives.

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 gives a clear intended use ('用于快速定位某事实、某人的所有出现位置') and indicates it is for keyword-based searching. However, it does not state when not to use it or explicitly contrast it with related tools such as read_pages or list_volumes, so usage routing is left partly to inference.

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

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

There are no annotations, so the description must fully convey behavioral expectations. '登记' implies a write operation, but the description does not disclose whether this creates or updates a record, whether existing values are overwritten, whether the operation is idempotent, or what side effects occur.

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: first gives purpose, second gives parameter structure. No fluff, and the parameter block is justified because the schema provides no field-level documentation.

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?

Though an output schema exists, the description lacks needed invocation context: it doesn't connect to create_case, doesn't explain whether args itself is optional, and doesn't say how this relates to the record_* sibling tools. An agent would be under-supported when deciding the correct sequence of calls.

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 input schema exposes only case_id and an opaque args object, with 0% coverage of the args fields. The description usefully enumerates the five required args fields, which is essential for invocation. However, it provides no types or formats for total_amount or volume_count and omits role of case_id entirely.

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 says the tool registers the case basic information table and lists the key fields (case_name, defendant, charge, total_amount, volume_count). The '基本信息' wording helps distinguish it from more specialized record_* siblings, though it doesn't explicitly name any alternative.

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 guidance is given about when to use this tool versus siblings like create_case, record_party, or record_indictment. It does not state prerequisites such as whether a case must already exist or whether this tool should be called before the more specific record tools.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that no background Claude/LLM job is started and that there is no Claude Code CLI dependency. However, it does not describe side effects such as repeated calls, registration counters, or what happens internally after invocation, leaving some behavioral uncertainty for an orchestration tool.

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 very concise and well-structured, with the primary action stated first, followed by key behavioral notes and monitoring pointers. Every sentence earns its place, and there is no filler or redundant restatement 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?

For an orchestration tool, the description covers what to do, what not to do, parameter roles, and where to check progress. It relies on the output schema for playbook steps and does not mention prerequisites or repeated-call behavior, which is a minor gap for an agent that needs 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%, but the description adds meaning for model, effort, and max_turns by stating they are compatibility hints and host-decided. It does not add semantic guidance for the required case_id parameter, such as requiring an existing case. This partially compensates for low schema coverage but not completely.

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 action: 下发标准阅卷 playbook and instructs the host agent to follow the steps. It also clearly distinguishes itself from the legacy background-job behavior by stating 不再启动后台 Claude/LLM job, which clarifies the tool's orchestration role. However, it does not explicitly differentiate from sibling tools like get_review_progress, though the orchestration purpose is fairly apparent.

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 explicitly directs progress monitoring to get_case_status / get_workspace_summary, so the agent knows start_review is not for checking progress. It also clarifies that model/effort/max_turns are host-decided and only retained as compatibility hints, preventing misuse. An explicit 'when not to use' beyond progress monitoring is absent, but the context is otherwise clear.

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?

No annotations exist, so the description carries the behavioral burden. It implies a read-only validation and explicitly says it returns non-compliant items. However, it does not clarify whether it writes results, whether any state changes occur, or what happens when everything is compliant.

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 first sentence is concise and front-loaded, but the second sentence about args adds no real information and is partially inconsistent with the schema. It is short, but not every sentence 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?

The description gives the purpose, the return type, and the required timing, which makes it minimally viable. It lacks explanation of case_id, preconditions such as records needing to be registered, and output details, especially since no output schema is provided.

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

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

Schema description coverage is 0% and the description does not explain the required case_id parameter. The '参数结构（args 字段）: {}' line is not semantically meaningful and is misleading because the schema actually requires case_id and allows args to be an object with additional properties.

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 a concrete resource/check scope: all registered records' source citations against real volume page ranges. It also states the result ('返回不合规项'), which distinguishes it from recording and writing 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 a clear workflow trigger: '阅卷结束前必跑' (must run before ending the review). It does not name alternatives or exclusions, but the mandatory-before-end context is clear enough for a validation gate.

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 no annotations provided, the description carries full responsibility for behavioral disclosure. It does state that the tool generates files and returns paths, but it does not disclose overwrite behavior, storage side effects, permission requirements, or whether the operation is long-running or dependent on prior review steps. This is a significant gap for a write-type tool.

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 compact, front-loads the main behavior and output artifacts, and includes parameter structure in a concise way. It avoids filler, though the parameter note could be more accurate and better separated.

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 tool with no annotations and a schema with essentially unconstrained args, the description leaves out critical context: case_id semantics, allowed fmt values, preconditions, postconditions, and the relationship to download_output. The output schema exists but is not shown, so the description alone is insufficient for reliable 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?

The description adds a fmt field inside args, but declares it required while the schema marks args as optional/default null. It also fails to explain case_id, even though case_id is the only schema-required parameter. With 0% schema description coverage, the description was expected to compensate, but it is partially misleading and incomplete.

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 action and resource: it generates 阅卷笔录 (Word) and 阅卷目录 (Excel), including case information and conclusions, and returns file paths. This is action-oriented and informative. However, it does not explicitly distinguish itself from sibling tools like download_output, so it stops short of full differentiation.

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 provides no guidance about when to use this tool versus alternatives, nor does it mention prerequisites such as whether a case review must be completed first. An agent gets no contextual cues about the proper calling sequence or exclusions.

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