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

No annotations provided; description does not disclose side effects (e.g., overwriting), idempotency, required data state, or error conditions. For a mutation tool, 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?

The description is concise (one sentence) but lacks any structured detail such as sections or parameter clarification. It is efficient but incomplete.

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 a simple schema (1 param) and no annotations, the description should explain the scope parameter and output. It does not, leaving the tool under-specified for an agent to use correctly.

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

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

The sole parameter 'scope' has 0% schema description coverage, and the tool description does not explain its meaning, valid values, or effect on operation. 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 clearly states the verb 'assign' and resource 'claims', and lists example features (primary_topic, outcome/treatment family), making the tool's function unambiguous and distinguishable from 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?

No guidance on when to use this tool versus alternatives, nor any prerequisites or scenario descriptions. The agent is left without context for tool selection.

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, and the description lacks behavioral details such as idempotency, side effects, or required permissions. The dry_run parameter hints at preview capability, but overall transparency is low.

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 short and front-loads the purpose. Parameter explanations are inline and clear. No redundant text, though could be slightly better organized.

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?

Despite having an output schema, the description does not explain what the grouping output looks like or any behavioral traits. With no annotations and only basic parameter info, the description is incomplete for a complex operation.

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

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

Schema coverage is 0%, so the description carries the burden. It explains all three parameters (scope, max_claims_per_doc, dry_run) with enough context about expected values (e.g., 'all', 'comm_id:...', 'doc_ids:id1,id2'). This adds meaningful guidance beyond the raw 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 '对结论进行分组/聚类' (group/cluster claims), which clearly indicates the tool's purpose. However, it does not differentiate from sibling tools like 'build_claim_groups_v1_2', which likely performs a similar function.

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. The description only lists parameters without context on use cases, prerequisites, or exclusions.

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 should disclose behavioral traits. It only mentions 'based on claim_features' but does not address side effects, idempotency, state changes, or requirements (e.g., claim_features must be computed first).

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 short sentence, which is concise but lacks essential details. It is under-specified and does not effectively convey the tool's purpose or usage.

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 has an output schema (unseen), but the description does not explain outputs. It provides minimal context for usage, parameter, or behavior, making it inadequate for an agent to select and 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?

The sole parameter 'scope' has no description in the schema (0% coverage) and the tool description does not explain its meaning. This adds no value beyond the parameter 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 clearly states it builds v1.2 claim groups based on claim_features, indicating the verb and resource. However, it does not differentiate from the sibling tool build_claim_groups_v1, missing explicit version differences.

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 provided on when to use this tool versus alternatives like build_claim_groups_v1 or split_large_claim_groups_v1_2. There is no mention of prerequisites or exclusions.

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 must disclose behavior. It explains the algorithm (Leiden), the rebuild parameter (clears old results for same level), and parameters affecting the process. However, it does not mention potential side effects, time costs, or data persistence beyond the rebuild parameter.

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 well-structured: a header sentence, a brief algorithmic overview, a parameter list with explanations, and a return description. Every sentence is informative and earns its place, with key information front-loaded.

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 covers purpose, algorithm, parameters, and return format (with output schema also present). However, it lacks guidance on prerequisites (e.g., graph must be built first) or integration with sibling tools like rebuild_communities, leaving some context incomplete.

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 fully explains all 5 parameters: level (macro/micro), min_df, resolution, max_nodes, and rebuild, including defaults. This adds significant meaning beyond the bare 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 purpose: constructing topic communities from Paper->Entity relationships using the Leiden algorithm. This is specific and distinct from sibling tools like summarize_community_v1 which operate on existing communities.

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

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

The description implies usage through parameter descriptions (e.g., rebuild option suggests managing multiple levels) but does not explicitly state when to use this tool versus alternatives. No exclusions or direct comparisons to siblings are provided.

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 must carry full burden. It states 'write to evidence pack' indicating mutation, but does not specify whether it appends or overwrites, how top entities are selected, or what happens if no mentions exist. The return information is partially redundant given the output schema.

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 front-loaded with the purpose, followed by a structured Args section. It is reasonably concise, though the Args block could be slightly more compact. Overall, it is well-organized and easy to parse.

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

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

The description covers the main input parameters, the sampling process, and the returned information. However, it omits details on how 'top entities' are determined and does not clarify the chunking or writing behavior. Given the output schema exists, the return section is less critical.

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 Args section adds meaningful descriptions for all three parameters (comm_id, max_chunks, per_doc_limit) beyond the bare schema, compensating for the 0% schema description coverage. It explains what each parameter does in the context of the 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 clearly states the action (build), the resource (community evidence pack), and the source (sampling chunks from mentions of community top entities). It distinguishes itself from sibling tools like build_evidence_pack and build_section_evidence_pack_v1 by specifying 'community'.

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 on when to use this tool versus its alternatives (e.g., build_evidence_pack, build_section_evidence_pack_v1). There is no mention of prerequisites, limitations, or cases where the tool should not 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 provided, so description must fully disclose behavior. It mentions searching and saving with tunable parameters, but does not clarify whether it creates new packs or appends, any destructive side effects, or authorization requirements.

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?

Description is concise with an introductory paragraph and a clear Args section. Every sentence adds value, no unnecessary words, and front-loaded with the main action.

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 presence of an output schema and detailed parameter descriptions, the description is fairly complete. It explains the return value (pack_id and entries) and the purpose. Minor gaps like whether it creates new packs or modifies existing ones, but overall sufficient.

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

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

Schema descriptions are absent (0% coverage), but the Args section in the description provides clear explanations for each parameter: query (search topic), k (retrieval count), per_doc_limit (max chunks per doc), alpha (vector search weight), adding significant value beyond the schema.

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

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

Description clearly states the tool builds evidence packs by searching for relevant literature fragments and saving them for reuse. It distinguishes from siblings like build_section_evidence_pack_v1 and build_community_evidence_pack by focusing on general evidence packs.

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?

Description explains the tool can be used for iterative review writing to avoid result drift, but does not explicitly state when not to use it or mention alternative tools for specific purposes.

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?

Discloses that the output is reproducible and that rebuild option exists, but no mention of side effects, permissions, or whether it overwrites existing packs. Annotations are absent, so description carries burden but leaves gaps.

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?

Concise: a title, one-line purpose, followed by a clear list of arguments and return values. No unnecessary sentences.

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?

Covers the main purpose, parameters, and returns. Lacks examples, error cases, or prerequisites. Output schema exists but is not shown; description compensates with return fields.

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?

Despite 0% schema coverage, the description briefly explains each parameter (e.g., outline_id is outline ID, max_chunks is maximum chunk count), adding meaning beyond the schema's type and default values.

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 it generates a fixed and reproducible evidence pack for a specified section, distinguishing it from siblings like build_evidence_pack and build_community_evidence_pack by explicitly mentioning section.

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 such as build_community_evidence_pack or build_evidence_pack. The description only states what it does without contextual usage advice.

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 burden. It discloses that merging can be skipped via suggest_only and returns statistics, but does not state potential destructiveness, permissions needed, or side effects. Basic behavioral context is present 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 concise and well-structured with separate sections for Args and Returns. It covers necessary information without excessive verbosity, though the first line could be slightly more compact.

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 (3 parameters, no annotations), the description provides adequate purpose and parameter details but lacks information on prerequisites, error conditions, or limitations. It is sufficient for basic use but could be more thorough.

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 has zero description coverage, so the description adds crucial meaning: it explains each parameter's purpose (types, suggest_only, max_groups) and provides defaults that are not evident from the schema alone. This fully compensates for the schema 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 clearly states the tool normalizes and merges duplicate entities based on canonical_key for specified types. It distinguishes itself from siblings like canonicalize_relations_v1 and merge_entities by focusing on entity deduplication via canonical keys.

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

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

The description implies usage for deduplication but does not provide explicit guidance on when to use this tool versus alternatives like merge_entities or canonicalize_relations_v1. No 'when not to use' or exclusions are mentioned.

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 full burden. It discloses the dry_run mode (no writes) implying normal mode writes to the database, and states that duplicates are merged with evidence preserved. However, it does not detail the normalization process or potential side effects beyond writing.

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 extremely concise: a single sentence stating purpose followed by 4 parameter lines. No redundant information, and the purpose is front-loaded.

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 description covers key parameters and basic behavior, it lacks usage guidance compared to siblings (e.g., no mention of relation normalization vs entity normalization). It does not explain the output schema or what 'normalize' entails, though an output schema exists. Given the presence of a sibling tool with similar purpose, completeness could be improved.

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%, and the description provides concise yet meaningful explanations for all 4 parameters: scope (all/doc/comm), predicate_whitelist (filter by predicates), qualifier_keys_keep (retain qualifiers), and dry_run (simulate only). This adds necessary context beyond the schema's type and default values.

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 normalizes relations and merges duplicates, preserving evidence. The verb 'canonicalize' and resource 'relations' are explicit, differentiating it from sibling tool canonicalize_entities_v1.

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 explains the scope and filter parameters, which guide when to use (e.g., for a specific document or community). However, it does not explicitly state when to use this tool versus alternatives like canonicalize_entities_v1 or merge_entities.

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 must carry the burden. It notes clear_all as a 'dangerous operation', adding behavioral context. However, it does not disclose other traits like irreversibility, permission requirements, or side effects beyond deletion.

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 concise, using a structured Args/Returns format. Every sentence serves a purpose, though the Chinese language may be less concise for English readers. 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 presence of an output schema (not shown but indicated), the return info is covered. However, without annotations, the description lacks details on permissions, irreversibility, or effects on related data, leaving gaps for a mutation 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 input schema has 0% description coverage, so the description compensates by explaining doc_id and clear_all with meaningful Chinese descriptions, including 'dangerous' for clear_all. This adds value beyond the schema.

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

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

The description clearly states it clears GraphRAG data for a specific document or all data, using specific verbs and parameters. It distinguishes between single and batch operations, but does not explicitly differentiate from sibling tools like delete_document or extract_graph_v1.

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 on when to use this tool versus alternatives, such as delete_document for deleting documents instead of graph data. It lacks context for selecting this tool over 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?

With no annotations, the description should disclose behavioral traits. It implies a read-only search operation but does not explicitly state safety or side effects. It also omits details like authentication or rate limits.

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 concise and structured with clear sections (title, args, returns). It avoids unnecessary details, though the args section largely mirrors 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?

With an output schema present, the description need not detail return values. It mentions aggregated evidence by document but lacks information on pagination, error handling, or result ordering.

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?

Despite 0% schema description coverage, the description adds meaning to all three parameters: topic (search topic), section_focus (with example), and k (result count). It provides functional context beyond the schema types.

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 purpose: collecting literature evidence for a specific topic, with optional section focus. The verb 'collect' and resource 'evidence' are specific, but it does not explicitly differentiate from sibling tools like build_evidence_pack or search tools.

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 (e.g., search_hybrid or build_evidence_pack). The description lacks any when-to-use or when-not-to-use information.

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 present, and description only mentions return values. Fails to disclose side effects, error conditions, or read-only nature.

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?

Concise with purpose front-loaded. Args/Returns block adds structure, though somewhat redundant with 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?

Adequate for a simple tool with output schema, but lacks error handling and integration context with sibling 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?

Schema description coverage is 0%, and the description adds minimal meaning ('outline ID') for the only parameter. Insufficient compensation for missing schema descriptions.

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 it generates a full-text structure template with ordered sections and markdown, but does not differentiate from sibling tools like draft_section or generate_review_outline_data_v1.

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. No prerequisites or exclusions provided, only parameter 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?

With no annotations, the description carries the full burden. It only says 'compute' but does not disclose whether the operation is read-only, mutates state, requires authorization, or has side effects. This is minimal behavioral information.

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 short sentence, indicating conciseness. However, it could be more structured with additional context, but it is not overly verbose.

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 has no parameters and an output schema exists, the description should explain the purpose and context of the cache computation. While it provides the basic function, it lacks completeness in explaining when this cache is needed or its role in the larger system.

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 are no parameters in the input schema, and schema description coverage is 100%. Per guidelines, 0 parameters results in a baseline of 4. The description adds no param info, which is acceptable here.

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 it computes a document frequency cache for Topic entities, providing a verb and resource. However, it lacks specificity about what 'Topic entity' refers to and what the cache is used for, making it somewhat vague.

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 usage guidelines are provided. The description does not indicate when to use this tool versus its siblings, nor are there any prerequisites or context of use.

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 fully carries the burden of behavioral disclosure. It clearly states that the tool deletes the document and all associated data (chunks, embeddings, etc.) and notes the optional deletion of the PDF file in MinIO. This effectively conveys the irreversible and broad impact.

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 relatively concise, mixing Chinese and English. It includes a clear heading ('删除指定文档') followed by bullet-like paragraphs. However, it could be slightly more structured with explicit sections for parameters and returns, though the current format is functional.

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 (delete with cascading effects) and the presence of an output schema (implied from 'Has output schema: true'), the description adequately covers the deletion behavior, optional PDF removal, and return information. It omits details like error handling or authorization requirements, but remains complete for a typical delete operation.

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 no descriptions for its parameters (coverage 0%). The description adds significant value by explaining each parameter in the Args section, including the doc_id as the document identifier and also_delete_object as an optional boolean to control PDF deletion. This fully compensates for the schema's lack of descriptions.

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 purpose: deleting a document and all associated data. It specifies the resource ('document') and the action ('delete'), and distinguishes from siblings like get_document or list_documents by emphasizing the destructive nature.

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. While the description implies it's for deleting documents, it does not mention conditions, prerequisites, or refer to sibling tools (e.g., when to use update_document 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 provided, but description discloses search behavior (fuzzy vs exact match), download source (MinIO), and output details (local directory). Return value is documented. Adequate for a file download 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?

Description is moderately concise with a structured docstring format (Args, Returns). It could be slightly more direct, but it's well-organized and free of fluff.

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 (download from MinIO, fuzzy matching), no annotations, and presence of output schema, the description is complete. It covers purpose, parameters, behavior, and return values.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter: title (fuzzy match), output_dir (default), exact_match (boolean). Adds meaning beyond the bare 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?

Description clearly states the tool downloads PDF files from a database based on title, using specific verbs and resources. It distinguishes from siblings like import_pdf (upload) and get_document (metadata retrieval).

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

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

Description implies usage when needing to download a PDF by title, but lacks explicit guidance on when not to use or comparison to alternatives like search tools. Context from sibling names provides some differentiation.

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 describes the generation process but does not disclose if the tool is read-only, any side effects, authentication needs, or rate limits. For a generation tool, more transparency on mutability would be useful.

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 well-structured with a clear purpose statement, parameter list, and return schema. It is concise with no extraneous information. However, mixing Chinese and English could be slightly confusing.

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 description covers parameters and output, it lacks information on error handling, missing behavior when both topic and pack_id are provided, and system prerequisites (e.g., need for pre-existing evidence packs). Given the complexity and lack of annotations, 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?

Schema description coverage is 0%, so the description compensates well. It explains each parameter's purpose, defaults, and conditional usage (e.g., k only relevant when no pack_id, outline_style options). This adds significant value beyond the raw 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 it generates a literature review draft based on a topic or existing evidence pack, following academic standards. However, it does not explicitly differentiate from sibling tools like draft_section or generate_review_outline_data_v1.

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 guidance on when to use parameters (e.g., k only when no pack_id, topic optional if pack_id provided), but does not include when to use this tool versus alternatives or explicit 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?

No annotations are provided, so the description carries full burden. It discloses that the tool generates section content and a reference list ('返回章节内容和引用列表'), but does not specify whether the operation is read-only or has side effects (e.g., saving state). The lack of safety or permission context is a gap, but the description accurately outlines core behavior without 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?

The description is concise (few lines) and well-structured: a one-sentence summary, followed by Args and Returns sections. It is front-loaded with the main purpose, and every sentence adds value without redundancy. The format is efficient for quick parsing.

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 moderate complexity (3 parameters, output schema exists), the description covers the main workflow, parameters, and return type. It lacks explicit mention of preconditions (e.g., evidence pack must exist) or behavior beyond generation, but overall it is sufficiently complete for an AI agent to use correctly. The presence of an output schema reduces the need to detail return values.

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

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

Schema description coverage is 0%, but the description includes an Args section that adds meaning: 'pack_id' is identified as evidence pack ID, 'section' as a chapter type with examples like 'methodology', and 'outline_style' with a default value and example 'econ_finance_canonical'. This significantly compensates for the bare schema, though not all possible values for 'section' are enumerated.

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 generates a specific section of a literature review based on an evidence pack, using the phrase '只生成指定章节的内容' (only generate the specified section). It explicitly distinguishes from siblings like 'draft_lit_review_v1' by focusing on iterative section writing. The verb '生成' (generate) and resource '综述特定章节' (specific section) are specific and actionable.

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

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

The description implies usage for iterative writing of a specific section with '适合迭代写作某个特定部分' (suitable for iterative writing of a specific part), but does not explicitly state when not to use or provide alternatives. Context from sibling tools (e.g., 'draft_lit_review_v1') suggests differentiation, but the description lacks direct comparative guidance.

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 provided, so description carries full burden. It explains the hybrid search behavior and the detailed return structure, including hit types and stats. Does not mention side effects but for a read-only tool this is sufficient.

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?

Well-structured with introduction, argument list, and return structure. Slightly verbose due to repeating parameter info that is in the schema, but still clear and concise overall.

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 presence of an output schema, the description sufficiently covers purpose, parameters, and output. Lacks error handling notes, but for a search tool this is 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?

Description provides detailed explanations for all 6 parameters (query, k, alpha, per_doc_limit, fts_topn, vec_topn), including defaults and ranges. This compensates for the 0% schema description coverage 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 states it explains search results by performing hybrid search and returning detailed breakdowns (FTS-only, vector-only, intersections). It distinguishes from siblings like search_hybrid by focusing on debugging and optimization.

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 states usage for debugging and optimizing search parameters. While it doesn't list when not to use, the context of sibling tools (e.g., search_hybrid) implies that for standard search without explanation, the sibling is appropriate.

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 and only a one-sentence description, the tool offers no behavioral details such as permissions, side effects, rate limits, or output characteristics. The agent cannot infer whether this is a read-only operation or has any destructive 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 a single sentence, which is concise, but it lacks structure and essential information. It does not earn its place as it fails to provide context beyond the tool's 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?

Given the existence of a sibling version (v1_2) and the presence of an output schema, the description is incomplete. It does not explain the grouping logic, the role of parameters, or the output format, leaving significant gaps for a tool with optional parameters.

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 has two optional parameters (comm_id, pack_id) with 0% description coverage, yet the description adds no meaning or explanation for these parameters. The agent cannot understand how 'comm_id' or 'pack_id' relate to the grouping or export process.

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 'Export the conclusion matrix aggregated by groups,' clearly specifying the verb (export) and resource (conclusion matrix aggregated by groups). However, it does not differentiate from the sibling tool export_claim_matrix_grouped_v1_2, leaving ambiguity about version differences.

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 provided on when to use this tool versus alternatives like export_claim_matrix_grouped_v1_2. There is no mention of prerequisites, context, or exclusions, making it difficult for an agent to select the correct tool.

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 description carries full burden. It discloses sorting and stratification behavior, but omits whether the tool is read-only, permissions needed, or any side effects. Partial transparency.

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?

Single sentence is concise but under-specified. Lacks parameter and usage details, making it too brief for practical use.

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 4 parameters, no annotations, and output schema present, the description is insufficient. Does not define 'grouped claim matrix' or explain parameters, leaving agents underinformed.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only hints at top_k_per_group, but leaves comm_id, pack_id, and include_subgroups unexplained. Fails to compensate for schema gaps.

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 action (export grouped claim matrix) and specifics (top-k, confidence sorting, sign stratification). It distinguishes from sibling export_claim_matrix_grouped_v1 by adding version-specific details.

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 usage guidelines provided. Does not mention when to use this tool vs alternatives like export_claim_matrix_grouped_v1 or other grouping tools, nor any prerequisites or context.

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 bears full responsibility. It mentions '导出' (export), which suggests a read operation, but does not explicitly state that it is non-destructive, or disclose any side effects, auth requirements, or rate limits. This lack of behavioral disclosure leaves the agent with insufficient information to assess operational impact.

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 concise with a brief Chinese sentence followed by a structured list of args and returns. No redundant information. However, it could be more front-loaded with an English summary for non-Chinese users. The structure is efficient, and every part contributes 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?

Given the presence of an output schema (though not shown), the description's absence of detailed return value documentation is acceptable. It covers the core functionality and parameter semantics. However, it lacks usage context like when to choose this over similar export tools, and does not explain the relationship between the two output matrices. Still, it provides the minimum viable information for a simple export operation.

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 has 0% description coverage, but the description compensates well by explaining each parameter: comm_id/topic mutual exclusivity, format options ('json' or 'csv'), and limit_docs as a document limit. This adds significant meaning beyond the schema. However, limit_docs could be more precise (e.g., whether it limits per matrix or total). Nonetheless, it substantially aids parameter understanding.

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 exports PaperMatrix and ClaimMatrix, which is specific and uses a verb+resource structure. However, it does not differentiate from sibling tools like export_claim_matrix_grouped_v1, which also exports claim matrices but grouped. Thus, the purpose is clear but lacks sibling 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?

No explicit guidance on when to use this tool versus alternatives. The parameter descriptions imply mutual exclusivity between comm_id and topic, but the description does not provide use cases, prerequisites, or conditions for choosing this export over others. The agent receives no direct usage direction.

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 should clarify behavioral traits like read-only, idempotency, or side effects. It only states what it does, not how it behaves (e.g., whether it modifies data, requires permissions, or has rate limits).

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 that is front-loaded and concise, but it sacrifices necessary detail. It could be expanded without losing brevity.

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 presence of an output schema and two optional parameters, the description should at least indicate how the parameters filter the export. It does not, leaving a significant gap for an agent to use 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%, and the description provides no explanation of the parameters comm_id and pack_id. Their roles (likely community ID and pack ID) are only inferred from the name, which is insufficient for correct 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 the tool exports a compact relations view aggregated by canonical relations, which is specific about the verb and resource. The name and description together distinguish it from similar export tools like export_claim_matrix_grouped_v1.

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 provided on when to use this tool versus its siblings. The description implies a compact view but does not mention scenarios or alternatives, leaving the agent without context for selection.

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 provided, and the description does not disclose side effects, access needs, or read-only status. Minimal behavioral info.

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 fairly concise but mixes Chinese and English. It could be more structured with a clear first-line purpose.

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?

Lists return types, but lacks context on prerequisites (e.g., pack_id must exist) and output schema details given no annotations.

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

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

Only one parameter with 0% schema description coverage. The description adds '证据包 ID' (evidence pack ID), providing some context, but not enough to fully compensate for the lack of schema documentation.

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 it exports a packet for section writing as JSON, but does not differentiate from sibling tools like build_section_evidence_pack_v1.

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 vs alternatives or prerequisites. The description merely states what it does.

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 provided; the description lacks behavioral details such as whether the operation is destructive, idempotent, or has rate limits. Concurrency parameters are present but unexplained.

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 concise and includes an Args and Returns section, but some text is dense and could be better organized.

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 no annotations and incomplete parameter coverage, the description provides adequate context for basic usage but lacks depth on behavior and edge cases.

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 explains three of six parameters (limit_docs, llm_model, min_confidence) but omits concurrency, doc_concurrency, and max_chunks, leaving gaps in understanding.

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 purpose: batch rerun extraction on documents missing mentions, distinguishing it from sibling extract_graph_v1 by focusing on missing documents.

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

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

The description implies usage when documents lack mentions but does not provide explicit conditions for use or alternatives, relying on context from sibling tool.

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 full burden. It discloses parallel processing, real-time progress, and the dry_run parameter for preview. However, it does not mention potential side effects (e.g., overwriting data), permissions required, or error behavior. The description provides moderate transparency but has gaps.

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 relatively concise, with a two-sentence summary followed by a structured Args list. However, the Args list repeats defaults already present in the schema, slightly reducing conciseness. The front-loading of the purpose is effective.

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 presence of an output schema (not shown), the description does not need to detail return values. It covers key aspects: action, target, parameters, concurrency, and dry-run mode. Missing details like idempotency or error handling are acceptable for a tool of this complexity.

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 Args list explains each parameter (e.g., doc_id: 文档 ID, mode: 模式). While brief, it adds meaning beyond the schema, especially for parameters like dry_run and concurrency. This compensates well for the lack of schema descriptions.

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 purpose: extracting entities, relations, and conclusions from document chunks and writing to the GraphRAG table. It mentions async parallel processing and real-time progress reporting, which distinguishes it from related tools like extract_graph_missing.

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 (e.g., extract_graph_missing). The description does not provide when-not conditions or context for selecting this tool over siblings, leaving the agent to infer usage from the purpose.

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 full burden. It discloses deterministic behavior ('无 LLM'), database write, rebuild flag for overwriting, and a clear return structure. This provides good transparency beyond the schema.

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: a brief purpose sentence, then Args and Returns sections. No wasted words, well-structured, and front-loaded with the core purpose.

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 has an output schema, the description does not need to detail return values, but it does. It covers all aspects: input choices, behavior, output. Complete for a straightforward tool.

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

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

Schema coverage is 0%, so description must compensate. It adds meaning for all four parameters: topic and comm_ids are mutually exclusive, outline_style has a default, rebuild is a boolean. The return value is also described.

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 it generates a reproducible review outline ('生成综述大纲（确定性，无 LLM）') from a topic or comm_ids, distinguishing it from potential LLM-based alternatives. The verb 'generate' and resource 'review outline' are specific.

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 explains the two mutually exclusive inputs (topic or comm_ids) and optional parameters (outline_style, rebuild). It does not explicitly state when not to use or compare to siblings, but the context is clear enough for an agent to decide.

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 provided. Description indicates a read operation (retrieving data) but does not explicitly state it is non-destructive. Output schema covers return format, but lack of annotation and explicit safety statement leaves 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?

Description includes both Chinese and English, with structured Args/Returns sections. Minor redundancy from bilingual duplication, but overall well-organized and front-loaded.

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 one parameter and an output schema, the description adequately explains purpose, parameter, and return structure. Could note that it is for a single chunk, not multiple.

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

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

With 0% schema description coverage, the description explains 'chunk_id' as the unique identifier for the chunk, adding meaningful context beyond the schema's type and required flag.

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 it retrieves full content of a chunk by ID, distinguishing from sibling tools like get_document (whole document) and get_document_chunks (list chunks). However, it does not explicitly differentiate from all 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?

No guidance on when to use this tool versus alternatives like get_document or get_document_chunks. No prerequisites or exclusions mentioned.

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 clearly indicates a read operation ('get') and enumerates return fields. It does not mention side effects or permissions, but the operation is simple and non-destructive.

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 well-structured with bullet points and a clear purpose upfront. It includes necessary details without being overly verbose.

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 get tool with one parameter and no annotations, the description covers the functionality and return structure adequately. It could mention error handling for non-existent documents, but overall sufficient.

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

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

The description explains the 'doc_id' parameter as a SHA256 hash, which adds meaning beyond the schema's type-only definition. It also details return fields, though these are not parameters.

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 it retrieves metadata and statistics for a document, using specific verb 'get' and specifying the resource. It distinguishes from siblings like 'get_document_chunks' and 'delete_document'.

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 does not explicitly state when to use this tool vs alternatives. It implicitly indicates it's for metadata retrieval, but no direct comparison or exclusion of other 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 bears full burden. It discloses that the tool returns a list of chunks with chunk_id, page number, and text summary. However, it does not mention potential performance implications, pagination, or behavior for invalid doc_ids.

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 concise, with a clear purpose statement followed by Args and Returns sections. Every sentence adds value, and the structure is well-organized.

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 (single parameter, straightforward return), the description covers essential aspects. However, it could mention whether results are paginated or if errors occur for missing doc_ids, but it is still reasonably 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 has 0% description coverage, but the description explicitly defines the doc_id parameter as '文档的唯一标识符' (unique identifier of the document), adding semantic clarity beyond the schema's raw type declaration.

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 '获取' (get) and the resource '指定文档的所有 chunks' (all chunks of a specific document), distinguishing it from sibling tools like get_chunk (single chunk) and get_document (document metadata).

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 explains that the tool is used with a doc_id to retrieve all text chunk summaries for a document. It does not explicitly mention when not to use it or compare with alternatives, but the context from sibling names implicitly clarifies usage boundaries.

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 indicates a read-only operation ('查看' meaning view) and states it returns content and statistics, which helps set expectations. However, it does not disclose potential side effects, authentication needs, rate limits, or error behavior (e.g., what happens if pack_id is invalid). The output schema likely covers return structure, but behavior beyond that is vague.

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 concise, with a title line, a brief use sentence, and a structured Args/Returns section. It avoids unnecessary words. The bilingual nature (Chinese/English) may add minor overhead but is not wasteful. It earns its place without 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?

Given the tool's simplicity (single required integer parameter, no nested objects) and the presence of an output schema, the description adequately explains the tool's purpose and what it returns. It mentions 'content and statistics,' which is sufficient context for an agent to understand the tool's function. However, it could be improved by hinting at what the output schema contains (e.g., list of documents, counts).

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, pack_id, has 0% schema description coverage. The description adds '证据包 ID' (evidence pack ID) in the Args section, clarifying its purpose as an identifier. While this adds some meaning, it does not explain how to obtain the ID (e.g., from list_evidence_packs) or specify constraints (e.g., required integer). Baseline is 3 as schema coverage is low but the description partially compensates.

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 '获取证据包详情' (get evidence pack details) and '查看已保存的证据包内容和统计信息' (view saved evidence pack content and statistics), specifying the verb and resource. It implicitly distinguishes from siblings like list_evidence_packs (lists all) and build_evidence_pack (creates) by focusing on viewing a single pack's details, but could be more explicit about the 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?

No guidance is provided on when to use this tool versus alternatives such as list_evidence_packs or build_evidence_pack. There is no mention of prerequisites, typical scenarios, or when not to use this tool, leaving the agent to infer usage from the name alone.

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 full burden for behavioral disclosure. It only states it returns a list of templates, but does not mention idempotency, whether it requires authentication, or any caching behavior. Given no parameters, the tool is straightforward, but transparency is minimal.

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 concise with three sentences, front-loading the purpose in both languages. The 'Returns:' line adds structure but is redundant given the output schema. Overall, it earns its place without being verbose.

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 zero parameters and the existence of an output schema, the description is fairly complete for a simple list tool. It could mention ordering or that no filtering is available, but it adequately conveys the function.

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 has zero parameters and 100% schema description coverage, so the description does not need to add parameter meaning. The baseline for 0 parameters is 4, as the description does not detract from but also does not enhance parameter understanding.

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 (get/list) and resource (outline templates) in both Chinese and English, specifying it returns all supported review outline templates. It distinguishes from sibling tools like compose_full_template_v1 which uses templates to compose, not list.

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 a simple read-only listing tool with no parameters, suggesting it is for exploring available templates. However, it does not explicitly state when to use it versus alternatives like generate_review_outline_data_v1 or compose_full_template_v1. No exclusions or prerequisites are mentioned.

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, and the description does not disclose whether the tool is read-only, requires permissions, or has side effects. As a health check it likely is safe, but this is not stated.

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 moderately concise but includes docstring formatting with Args/Returns sections. It is front-loaded with purpose but could be trimmed without losing clarity.

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

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

With an output schema present, the description's detailed return structure is sufficient. However, missing behavioral guidance and usage context reduce completeness for a health-check 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%, but the description explains the 'include_counts' parameter's meaning and default behavior, adding value beyond the schema's type and default fields.

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 checks GraphRAG layer health, verifying tables and indexes exist and returns statistics. This specific verb-resource combination distinguishes it from siblings like 'graph_status' and 'health_check'.

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

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

The description implies usage for health verification but does not provide explicit when-to-use guidance or differentiate from similar tools. No exclusions or alternatives are mentioned.

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 full burden. It discloses that the tool returns coverage statistics and has no side effects (read-only). However, it does not detail auth needs, rate limits, or performance characteristics.

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 concise with a clear title line and structured Args/Returns sections. It front-loads the purpose and provides necessary details without verbosity. Minor improvement could be more brevity in the Chinese phrasing.

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 (one optional param, output schema exists), the description covers purpose and parameter adequately. It mentions return type ('覆盖率统计信息') but doesn't detail exact fields; output schema likely fills that gap. Complete for a status 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 description adds meaning beyond the schema by explaining doc_id is optional ('若无则返回全局统计'). Schema coverage is 0% (no parameter descriptions in schema), so this explanation is valuable. Only one parameter, so limited but helpful.

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 it provides coverage statistics for entities, mentions, and claims per document or globally. It uses a specific verb ('查看' = view) and resource ('GraphRAG 覆盖状态'), but does not explicitly differentiate from siblings like graph_health_check or ingest_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?

The description implies usage when needing coverage stats via the Args/Returns, but lacks explicit guidance on when not to use this tool or alternatives among the many siblings. No exclusions or when-to-use clarifications are provided.

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 full burden. It mentions checking components but does not disclose traits like side effects (appears read-only), rate limits, or permission requirements. Minimal behavioral info.

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?

Description is concise with a brief overview and bulleted return fields. However, the first sentence is somewhat redundant with the name. Still efficient for the information conveyed.

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 no parameters and presence of output schema, description sufficiently covers what the tool does and returns. It could mention if checks trigger any side effects, but for a health check, it is reasonably 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?

No parameters in schema, schema coverage is 100%. Baseline for 0 parameters is 4. Description does not need to add param info, and it correctly omits any parameter details.

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?

Description clearly states it checks system health including database, storage, and extensions. However, it does not differentiate from sibling 'graph_health_check' which likely checks a subset, so purpose is clear but not distinct.

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 vs alternatives like graph_health_check or graph_status. The description implies it is for overall system health but does not provide explicit usage context or exclusions.

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

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

The description outlines the steps (hashing, upload, text extraction, chunking, embeddings, database commit) and mentions progress notifications, but lacks details on error handling, file size limits, or behavior when force=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?

The description is well-structured with a bullet list and an Args section, though the step list could be slightly more concise.

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 covers the basic workflow and parameters but does not explain the output schema, error conditions, or prerequisites, leaving gaps for an AI agent.

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 Args section provides meaningful explanations for each parameter beyond the schema types, such as file_path being an absolute path and title being optionally extracted from PDF metadata.

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 imports PDF files into the knowledge base and lists the multi-step process, distinguishing it from sibling tools like delete_document or download_pdf.

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

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

The description implies usage for importing PDFs but does not explicitly state when to use it versus alternatives or when not to use it.

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 must cover behavioral traits. It states the tool views status (implying read-only) and returns progress/errors, but lacks details on authentication, rate limits, 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 concise with separate sections for purpose, args, and returns. It is front-loaded with the main purpose and contains no unnecessary 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 has two optional parameters and an output schema (though not shown), the description covers purpose, parameters, and return value. It could clarify behavior when both parameters are 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?

The description adds meaning to the parameters beyond the input schema: doc_id queries the latest job, job_id queries a specific job. This clarifies their usage.

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 purpose: viewing the import status of a specified document or job, including progress and error information. This distinguishes it from other status tools like 'graph_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?

The description explains querying by doc_id or job_id but does not provide guidance on when to use each or when not to use the tool. No alternatives or exclusions are mentioned.

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

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

The description indicates the tool validates and returns results (passed, issues, stats), implying a read-only operation. However, without annotations, it does not explicitly state that it is non-destructive or requires specific permissions. The behavioral disclosure is adequate but not thorough.

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 concise with a clear structure: a one-line purpose statement followed by bullet-point argument descriptions. The mixed language (Chinese title, English args) is slightly distracting but doesn't harm clarity.

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 covers the tool's input parameters but lacks details about the output structure (e.g., what 'issues' and 'stats' contain). Given no output schema in the input, the description should elaborate on return values for full completeness.

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 explains both parameters: pack_ids as a whitelist of allowed evidence pack IDs, and markdown as the full review markdown. This adds significant meaning beyond the schema's type definitions (array of integers, string). It compensates well for the 0% schema coverage.

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 purpose: checking the full review for compliance with citation rules. The verb '验证' (verify) and resource '全文合规' (full text compliance) are specific. While it implicitly distinguishes from 'lint_section_v1' (section-level linting), it does not explicitly differentiate from 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?

The description provides no guidance on when to use this tool versus alternatives like 'lint_section_v1' or 'draft_lit_review_v1'. It does not state prerequisites, exclusions, or context for invocation.

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 bears full responsibility for disclosing behavior. It only states it checks rules and returns results, but does not mention side effects, authorization needs, or whether it is read-only. The minimal description leaves behavior largely implicit.

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

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

The description is concise, starting with a clear title-like line, then a brief explanation, followed by a structured docstring listing parameters and returns. It is front-loaded and well-organized, but the parameter explanations could be slightly more detailed.

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

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

The tool has an output schema (passed, issues[], stats) but the description only lists return names without detail. Given the complexity of a validation tool, the description could explain what 'passed' means or how issues are structured. However, the output schema mitigates the need for full 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 input schema has zero description coverage, but the description provides Chinese explanations for all parameters (e.g., 'pack_id: 证据包 ID', 'markdown: Agent 写作的 markdown 内容', 'require_citations_per_paragraph: 是否要求每段有引用，默认 False'). This adds meaning beyond the schema's type and defaults, though some details are minimal.

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 that the tool verifies citation compliance in markdown sections. It uses specific verbs ('验证', '检查') and identifies the resource ('Agent 写作的 markdown'). There is a sibling 'lint_review_v1' which may be for full reviews, but the tool name and description indicate it's section-specific.

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 on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or when not to use it. The sibling tools suggest other lint operations, but no differentiation is given.

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

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

With no annotations, the description carries full burden. It discloses that it returns a list with basic info and chunk/embedding statistics, and explains parameter behavior (e.g., has_embeddings filtering, defaults). It does not explicitly state that it is a read-only operation, but the context implies it. Additional disclosure about potential performance or rate limits would be beneficial.

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 concise and well-structured: a one-line title, a one-sentence summary, an 'Args' section for parameters, and a 'Returns' section. Every sentence adds value, and the key information is front-loaded.

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 covers the essentials for a listing tool with parameters and return type. It mentions output includes basic info and chunk/embedding statistics, which is appropriate given an output schema exists. However, it could briefly mention pagination behavior or performance considerations given the potential for large result sets.

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 has 0% description coverage, so the description must compensate. It does so excellently by providing complete parameter documentation: defaults, valid values for order_by, semantics for has_embeddings (True/False/None), and the effect of limit/offset on pagination. This adds significant value beyond the raw 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 it lists all imported documents and returns a summary list with sorting and filtering. The verb '列出' (list) and resource '所有已导入的文档' (all imported documents) are specific. It distinguishes from sibling tools like get_document (single document), delete_document, update_document, and search tools, making its purpose distinct.

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 explains the parameters and their use cases (e.g., filtering by embeddings presence) but does not explicitly state when to use this tool versus alternative search tools (search_fts_only, search_hybrid, search_vector_only) which could also retrieve documents. The context is implied but not explicitly guided, leaving ambiguity for the agent.

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 should disclose behavioral traits. It only states the tool returns a list, omitting whether it is read-only, performance implications, 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 very concise: one sentence plus args/returns. It is front-loaded and contains no superfluous information.

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

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

Given the presence of an output schema, return details are not needed. However, no annotations are provided, and the description lacks contextual information about workflow or read-only nature. Adequate but could be better.

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

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

Schema coverage is 0%, so the description adds minimal meaning via 'limit' and 'offset' descriptions. It explains defaults and purpose but could be more detailed about pagination.

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 it lists all evidence packs, using a specific verb and resource. However, it does not differentiate from sibling tools like 'get_evidence_pack_info' or build-related tools.

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; no when-not-to-use or context provided.

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 must disclose behavior. It reveals that locking entities prevents auto-normalization and merging, which is key. However, it does not mention reversibility, idempotency, or any side effects beyond the lock/unlock action.

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 primary effect. It clearly separates the purpose, arguments, and returns. However, the returns section is very brief ('操作结果') and could be improved.

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 and the presence of an output schema, the description covers the main purpose and a key behavioral consequence. However, it lacks details on error conditions, required permissions, or what happens when unlocking an entity that isn't locked.

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 has 0% description coverage, so the description carries the full burden. It explains that entity_id is the entity ID and is_locked is whether to lock (default True). This adds meaningful context beyond the schema types.

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 locks or unlocks an entity and explains the consequence (prevents automatic normalization and merging). This distinguishes it from sibling tools like merge_entities and canonicalize_entities_v1, which do related but different operations.

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 (to prevent normalization) but does not explicitly state when not to use or provide alternatives. It gives no guidance on prerequisites or typical use cases.

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?

Discloses that references are migrated and the source entity is deleted, which is critical behavioral information. However, it lacks details on potential side effects (e.g., downstream updates, error handling) and does not clarify if the operation is reversible or requires special permissions. No annotations are present to augment this.

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 concise, using 3 lines plus structured Args and Returns. Every sentence serves a purpose: stating the action, explaining the process, and detailing parameters. No extraneous text.

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

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

Covers the core behavior but omits important context such as return value format, error conditions (e.g., what if entities don't exist?), and operational requirements (e.g., user permissions). Given no annotations and a basic output schema ('操作结果'), more detail would benefit completeness.

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?

Despite 0% schema description coverage, the description provides clear semantic meaning for each parameter: 'from_entity_id' is the entity to be merged (source), 'to_entity_id' is the target, and 'reason' is the justification. This adds significant value beyond the schema's plain types.

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 merges two entities manually, with specific verb '合并' (merge) and resource '实体' (entity). It distinguishes itself from sibling tools like 'canonicalize_entities_v1' by specifying manual action and deletion of source.

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, such as 'canonicalize_entities_v1'. The description says '手动合并' (manual merge) but does not explain when manual vs automatic merging is appropriate, nor does it list prerequisites or exclusions.

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

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

The description discloses the key behavioral trait of being destructive ('清除...并重新构建'), which is critical. However, no annotations exist, and the description does not elaborate on other behaviors like idempotency or prerequisites. It provides basic but sufficient transparency.

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 highly concise: one line for purpose, followed by a clear Args section with parameter explanations. Every sentence adds value, and the structure is front-loaded and easy to parse.

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

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

Given no annotations and 0% schema coverage, the description covers purpose, parameters, and return value ('新社区列表'). It is nearly complete for agent usage, though lacking usage context (when to use vs siblings) which is partially addressed elsewhere.

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

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

With 0% schema description coverage, the description compensates by explaining each parameter: level ('macro' or 'micro'), min_df (minimum document frequency), and resolution (Leiden resolution). This adds significant meaning beyond the schema's type/defaults.

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 purpose: '清除指定层级的旧社区并重新构建' (clear old communities at a specified level and rebuild). This distinguishes it from siblings like 'build_communities_v1' by emphasizing the destructive rebuild aspect.

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

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

The description implies usage for rebuilding communities at a given level but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The context is clear but lacks exclusions.

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

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

The description transparently discloses all key behaviors: fetching from MinIO, re-extracting text, re-chunking, regenerating embeddings, and deleting old chunks and embeddings. This is especially important given no annotations were provided. The 'force' parameter behavior is also explained.

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 extremely concise: two sentences of high-level overview followed by a structured Args/Returns section. Every sentence provides necessary information without redundancy, making it efficient and easy to parse.

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

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

Given the tool's complexity (side effects, external storage, multi-step process) and the presence of an output schema, the description covers the main aspects: process, parameters, and return value. It could mention prerequisites (e.g., document must exist in MinIO) or error handling, but overall it is sufficiently 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?

Despite the input schema having 0% description coverage, the description adds detailed meaning for all three parameters: 'doc_id' (unique identifier), 'strategy' (currently only 'page_v1'), and 'force' (conditional execution, default False). This fully compensates for the schema's lack of descriptions.

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 action: re-chunking a PDF document by extracting text, applying a chunking strategy, generating new embeddings, and deleting old chunks and embeddings. The verb 'rechunk' and resource 'document' are specific, and the tool is distinguished from siblings like 'reembed_document' which likely only re-embeds without re-chunking.

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 explains the tool's workflow and the 'force' parameter, indicating when to re-chunk even if chunks exist. However, it does not explicitly list alternatives or say when not to use it. The context is clear enough for an agent to understand the tool's role among sibling 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 full burden. It details default behavior (only missing embeddings) and the effect of force=True, and notes the return type. However, it does not disclose potential side effects or idempotency.

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 well-structured with an overview and an Args section. It is concise but could be slightly more streamlined. Every sentence adds 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?

Given the tool's simplicity (3 params, no annotations, has output schema), the description covers purpose, parameters, and return value adequately. It could mention edge cases or prerequisites but is sufficient.

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

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

The description provides clear explanations for all three parameters (doc_id, batch_size, force) beyond what the schema offers, including their purposes and defaults, compensating for the 0% schema description coverage.

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 purpose: to regenerate embeddings for document chunks. It specifies the default behavior (only missing embeddings) and the force option, distinguishing it from sibling tools like rechunk_document.

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 explains when to use the force parameter but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. It implies usage for embedding regeneration but lacks exclusions.

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 reveals the tool uses PostgreSQL full-text search and supports boolean operators, providing concrete behavioral insight. It does not disclose side effects or auth needs, but as a search tool, these are less critical; the technical detail is sufficient.

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, using a clear structure with headings. Every sentence adds value: purpose, method, parameters, and return. 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 presence of sibling search tools, the description successfully positions this as 'pure full-text search' with 'exact keyword matching'. However, it could explicitly contrast with 'search_hybrid' and 'search_vector_only'. The output schema exists, so the brief return description is acceptable.

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

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

Schema coverage is 0%, so the description must add meaning. It explains 'query' supports boolean operators (not in schema) and provides default for 'k'. This adds valuable semantic context beyond the raw 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 '纯全文搜索' (pure full-text search) and specifies it uses PostgreSQL full-text search for exact keyword matching. This distinctively separates it from sibling tools like search_hybrid and search_vector_only.

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 explicitly says '适合精确关键词匹配的场景' (suitable for exact keyword matching scenarios), giving clear usage context. However, it does not explicitly state when not to use it or mention alternatives, which would elevate the score.

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 provided, so description carries full burden. It details the hybrid approach, per-document chunk limit to avoid spamming, and alpha weighting. However, it does not disclose performance considerations or error conditions.

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 structured with numbered Args and Returns sections. It is clear but slightly verbose; some parameter explanations could be shorter. However, it is well-organized and front-loaded with the purpose.

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 has 6 parameters, no annotations, and an output schema implied from the Returns, the description covers the core functionality, parameters, and return fields. It lacks prerequisites or edge cases but is fairly complete for a search tool.

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

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

Schema coverage is 0%, but the description fully explains all 6 parameters with their purpose, defaults, and constraints (e.g., alpha range 0-1, per_doc_limit to avoid single paper overwhelming results). This adds significant value beyond the schema.

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

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

The description clearly states it performs hybrid search combining full-text search and vector similarity, with specific verb '搜索' and resource '文献库'. It distinguishes itself from siblings like search_fts_only and search_vector_only by explicitly mentioning the combination.

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 explains what the tool does and its parameters, but does not explicitly state when to use this tool vs the separate FTS or vector search tools. However, the presence of siblings provides context, and the description implies it's for queries needing both modalities.

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 provided, so description carries full burden. It states it uses only vector similarity, implying a read-only search. But lacks details on side effects, auth, or rate limits.

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?

Description is very concise: two lines for purpose, then Args and Returns. It is front-loaded with the essential information and has no unnecessary text.

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

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

Given the tool's simplicity (2 parameters, with output schema existing), the description covers purpose, parameters, and return type adequately. No significant 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?

Schema coverage is 0%, but the description explains 'query' as search query string and 'k' as number of results with default 10, adding meaning beyond types.

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 it performs pure vector similarity search, suitable for semantic matches without keyword overlap. It explicitly contrasts with keyword-based search, distinguishing it from siblings like search_fts_only.

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 indicates when to use (semantic but not keyword matching) but does not explicitly mention when not to use or name alternatives. However, siblings are listed, allowing 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?

No annotations are provided, but the description implies a read-only operation by describing a filtering and retrieval process. It does not explicitly declare non-destructive behavior or discuss side effects, which is adequate given the tool's nature.

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 well-structured with a summary line, parameter list, and return value explanation. It is concise yet informative, though mixing Chinese and English may slightly reduce clarity for some users.

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 moderate complexity and the presence of a schema and output schema, the description adequately covers purpose, parameters, and return structure. It lacks examples or edge-case handling but is sufficient for correct usage.

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 has 0% description coverage, but the tool's docstring compensates by explaining each parameter's purpose, mutual exclusivity of doc_id and pack_id, and the keyword_mode options. This adds significant value beyond the raw 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 it selects high-value chunks containing key methods/identification/results content from a document or evidence pack. It distinguishes itself from siblings like get_chunk and get_document_chunks by emphasizing value-based filtering.

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 specifies input options (doc_id vs pack_id) and provides parameter details, but does not explicitly state when to use this tool instead of alternatives or when not to use it.

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 must disclose behavioral traits. It mentions the algorithm (TF-IDF + KMeans) but fails to explain whether the tool modifies existing data, if it is destructive, or any side effects. The agent has no information on what happens to the original claim groups.

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 concise sentence, which is efficient. However, it lacks important details needed for correct usage, so the conciseness is not entirely beneficial. It earns a middle score for brevity but insufficient 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?

Given the complexity of the tool (clustering-based splitting), the description should cover return values, side effects, and parameter details. It provides none of these, even though an output schema exists but is not described. The description is incomplete for an agent to use 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?

The input schema has 2 parameters with no descriptions (schema coverage 0%). The description does not explain split_threshold or target_size, leaving the agent to guess their meanings and valid ranges. 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 clearly states the tool splits extra-large claim groups using TF-IDF and KMeans. It distinguishes from similar sibling tools like build_claim_groups by specifying the splitting action. However, it does not define 'extra-large' or provide context on when splitting is necessary.

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 provided on when to use this tool versus alternatives, such as build_claim_groups or other claim processing tools. There is no mention of prerequisites or scenarios where splitting is appropriate.

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 full burden. It mentions 'force' for regeneration, implying idempotency, but does not disclose potential long-running behavior, resource consumption, or side effects of batch operations.

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 concise, front-loaded with purpose, and uses a structured Args list without extra fluff. Every sentence adds 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?

Given 4 parameters and an output schema, the description covers parameter usage but lacks broader context like when to choose batch over single community summarization. Output schema exists, so return values are not needed.

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

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

With 0% schema description coverage, the description adds meaning by specifying allowed values for 'level' ('macro'/'micro' or integer 1/2), 'concurrency' default 5, and 'force' boolean. However, it does not explain the difference between 'macro' and 'micro' or the format of 'comm_ids'.

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 '批量/并行生成社区摘要' (batch/parallel generate community summaries), specifying the verb (generate), resource (community summaries), and scope (batch/parallel). It distinguishes from the sibling 'summarize_community_v1' which likely handles a single community.

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 use for batch summarization via the name and parameter 'comm_ids', but does not explicitly state when to use this tool versus alternatives like 'summarize_community_v1'. No when-not or exclusion criteria are provided.

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 convey behavioral traits. It only states 'generate' without any details on prerequisites, side effects, or output structure, which is insufficient for a tool with 5 parameters and an output schema.

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, making it concise, but it lacks substantive content that would justify its brevity; it is under-specified rather than efficiently informative.

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 complexity (5 parameters, no parameter documentation, no annotation) and the presence of an output schema, the description fails to provide adequate context for correct invocation, leaving the agent with minimal 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?

Schema description coverage is 0%, and the description does not mention any parameters (comm_id, pack_id, llm_model, max_chunks, style), providing no help beyond the schema itself.