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

With no annotations, the description carries the full burden, and it discloses what each target destroys (prediction history, temp frame dir, everything) and the purpose of freeing disk. It does not address reversibility or required permissions, but for a cache-clean operation the destruction profile is reasonably clear.

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?

Structured into 入参/返回/用途/下一步 with the core action front-loaded; every section adds actionable information and nothing is padding.

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?

A single-optional-param tool whose parameter meanings, effects, and follow-up steps are all documented, and return values need not be explained since an output schema exists. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 0% and the schema does not even declare the enum, so the description's documentation of all (default) / predict / frames with meanings is the only source of parameter semantics. It 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?

States a specific verb+resource ('清理运行期缓存') and enumerates exactly what each mode clears, so an agent knows the scope. It does not explicitly differentiate from the sibling reset_predictor, which sounds related to the 'predict' target, leaving mild ambiguity about which tool to reach for.

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

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

Gives concrete when-to-use conditions: free disk after long runs, keep prediction data clean before switching rounds, and clear frames before long sessions. It does not state when NOT to use it or compare directly to reset_predictor, so it stops short of full routing 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 exist, so the description carries the full burden, and it delivers: it discloses the dry-run default (UGF_DRY_RUN=1) that only validates parameters, that real input control requires an authorized environment, and that move actions apply anthropomorphic path perturbation and occasional pauses. These are unique behavioral traits not available elsewhere.

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

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

Front-loaded with purpose, then structured as 用途 / 入参 / 返回 / 下一步. Every sentence adds value, though the repeated formatting labels are slightly verbose; it remains compact for the amount of 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 annotations and 0% schema coverage, the description is nearly complete: purpose, parameters, return format, and workflow context are all present. It could be improved by listing the return fields or error cases, but it already provides a full picture for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate. It does: action_type is said to be required with allowed values 'move / attack / defend / synthesize / idle', and x/y are described as target coordinates required when action_type is move. This fully covers the parameter semantics that the bare schema omits.

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

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

States a specific verb+resource ('执行一个游戏动作') and clarifies the intent: turning a decision into an actual operation. It explicitly distinguishes itself from the sibling switch_set ('切换套装请用 switch_set，不要用本工具').

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

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

Gives explicit when-to-use in the workflow loop ('回到 perceive_game → predict_all_entities 的循环'), names a direct alternative (switch_set), and describes a specific escalation path ('遇到 AFK 弹窗用 handle_afk'). It even states the dry-run condition under which the tool 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 the full burden. It discloses that it returns operation guidance text and that the actual click is done via game_action(move), implying this tool does not click itself, but it omits permissions, side effects, and failure behavior.

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

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

Four short lines, front-loaded with purpose, then usage, parameters, return, and next step. Every sentence earns its place and nothing is redundant.

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

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

For a simple zero-parameter tool with an output schema, the description covers purpose, usage, parameters, return type, and the next-step workflow. It is complete enough for an agent to call 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?

Zero parameters, so the baseline is 4. The description explicitly states '入参：无', matching the empty input schema.

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

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

States a specific verb '处理' and resource '游戏内的 AFK 人机验证弹窗', plus the long-idle trigger context. It is clear, but it does not explicitly contrast with sibling tools beyond mentioning perceive_game and game_action as next steps.

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

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

Explicitly says when to call it: when long idle triggers verification. It also provides a clear next-step workflow with perceive_game and game_action(move), but gives no when-not guidance or alternatives.

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

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

With no annotations, the description carries the burden and does disclose meaningful behavior: content is appended (additive), and a missing document is auto-created. It also names the success/failure return strings. It does not cover permissions, concurrency, or what happens on duplicate filenames.

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

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

Front-loads the core action, then uses labeled sections (用途/入参/返回/下一步) for scannability with no filler. The 返回 line is arguably redundant given an output schema exists, but overall it is tight and well-structured.

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

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

An output schema exists, so return values need not be re-explained, and the description still adds role guidance for game_name plus usage scenarios. The main gap is lack of differentiation from the sibling kb_write, which an agent may otherwise confuse with this tool.

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

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

Schema description coverage is 0%, so the description must compensate. It names all three parameters and clarifies that game_name is an optional categorization folder, which is genuinely useful. It does not explain the expected filename format or markdown_content conventions, so the compensation is only partial.

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

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

States a specific verb+resource (append content to an existing knowledge-base document) and adds the fallback behavior of auto-creating the file. It does not distinguish itself from the sibling kb_write, which is the most obvious alternative for writing 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?

Gives concrete usage scenarios (add a conclusion line after a match, add a new observation to a BOSS habit), which clearly frames when this tool is appropriate. However it offers no exclusions or explicit routing versus kb_write/kb_search, leaving the append-vs-write choice to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful traits: what is included in the archive, that the operation is non-destructive (produces a separate artifact), and that the result is a file path or status text. It omits where the artifact is written, whether it requires permissions/disk space, and how long a full export takes.

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

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

Front-loaded with the action and scope, then broken into short labeled lines for purpose, inputs, return, and next step. Nothing is padded; the 'no inputs' line is the only mildly redundant element and costs a few characters.

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

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

An output schema exists, so return values need no elaboration, and the description covers scope, use cases, and the follow-up workflow. What remains unaddressed is operational context the agent may need, such as permissions, artifact location, and failure modes, which matters given the absence of 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?

Zero parameters, so the baseline is 4. The description explicitly confirms '入参：无' (no inputs), which matches the empty schema and removes any doubt that the agent must supply something.

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

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

States a specific verb and resource (package the entire knowledge base, active + archived, into a tar.gz backup), which is far more precise than a bare name restatement. The scope note ('active + archived') distinguishes it cleanly from siblings like kb_list, kb_search, and kb_write, none of which export.

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

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

Gives two concrete use cases (machine migration, periodic backup) and names the complementary next tool, kb_import, for restoration on the new machine. It stops short of stating exclusions or when another tool would be preferable, so it is clear context without full when/when-not routing.

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 load and does disclose the key destructive trait — same-name files are overwritten — plus the expected return (restore result text with file count). It omits error/partial-restore behavior and any auth or path-existence 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?

Front-loaded statement of purpose followed by clearly labeled sections (入参/返回/下一步). Every line earns its place and nothing is padded.

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

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

Given a single required parameter, an output schema that covers the return shape, and no annotations, the description supplies purpose, overwrite semantics, path semantics, and next steps — nothing essential is missing for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate, and it does: backup_path is explained as an absolute path or a path relative to the project root. That exceeds the bare 'Backup Path' title, though no format/validation detail is added.

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

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

States a specific verb+resource (从备份恢复知识库) and names kb_export as the counterpart that produces the input, so an agent can immediately tell this is the inverse of export rather than a sibling like kb_write.

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?

Clearly frames the use case as restoring from a kb_export tar.gz and names follow-up tools (kb_list to verify, kb_search to spot-check). It does not state explicit exclusions (e.g. when to prefer kb_write instead), so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the return type (JSON string array of document names) and the scoping behavior when game_name is supplied. It does not state access/permission requirements or that it is a read-only, non-destructive operation, which is implied by 'list' but not declared.

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

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

Front-loaded one-line purpose followed by labeled sections (用途/入参/返回/下一步). Every line earns its place; the labeled structure is slightly formulaic but no content is wasted.

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

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

For a one-parameter list tool with an output schema, the description covers purpose, parameter meaning, return shape, and workflow handoff. Nothing an agent needs to invoke it is missing; the only gap is the absence of any read-only/permission statement.

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

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

Schema description coverage is 0% and the single parameter has only a type and default, so the description must compensate. It does: 'game_name 可选；给了就只列该游戏文件夹下的文档' explains optionality and the filtering semantics the schema does not.

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

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

States a specific verb and resource: list existing Markdown document names in the knowledge base. It is clearly distinguishable from kb_search (retrieves content) and kb_write (creates docs), which it explicitly routes to in the '下一步' 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?

Explicitly gives the situation for use ('动手前先看本地有没有这个游戏的资料，避免重复研究') and names the follow-up alternatives kb_search and kb_write. No explicit when-not condition, but the workflow context is strong enough to guide 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?

With no annotations, the description carries the behavioral burden and usefully discloses the retrieval mode order: semantic search first, falling back to full-text matching if unavailable. It also describes what is returned on success and on no hit, though it does not explicitly state that the operation is read-only or mention permission/auth constraints.

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

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

The description is organized into clear semantic sections (purpose, inputs, returns, next step) and is front-loaded with the core operation. Every part earns its place by covering purpose, required inputs, output behavior, and follow-up actions.

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, absent annotations, 0% schema description coverage, and the presence of an output schema, the description is complete enough to invoke the tool correctly. It compensates for schema gaps and adds retrieval behavior and workflow guidance that the structured fields do not provide.

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 define the parameters, and it does so completely: keyword is required, game_name is optional and scopes the search to a specific game folder. This adds precisely the meaning missing from 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 states a specific verb and resource: keyword retrieval in a local Markdown knowledge base. It also clarifies the intended content domain (monsters, bosses, tactics) and distinguishes the tool from write-oriented siblings by describing kb_write / kb_append as follow-up 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?

It gives clear usage context (looking up known information about a monster, boss, or tactic) and explicitly names kb_write / kb_append as alternatives when material is missing or outdated. It does not state when not to use this tool or name other search/list alternatives, so it stops short of full when/when-not 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 are provided, so the description carries the burden. It clearly discloses the destructive/overwrite behavior ('已存在则整体覆盖' and the explicit 注意: 这是覆盖写), which is the key behavioral trait for a write tool. It also documents return values (success and error formats). It does not mention permissions, atomicity, or size limits, so not a perfect 5.

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

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

Well-structured with labeled sections (用途/入参/返回/注意/下一步), front-loaded with the core action. Every line earns its place and there is no redundant filler.

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

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

For a 3-param write tool with no annotations and an output schema, the description covers purpose, parameters, overwrite semantics, return format, and sibling routing. Note that although an output schema exists, the description still describes return values, which is mildly redundant but harmless. Nearly complete aside from permission/path-safety details.

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 and largely does: it explains filename (no path), markdown_content (body), and game_name (optional, for subfolder categorization). This adds real semantic meaning beyond the bare schema property names. Minor gap: it doesn't specify accepted file extensions or path sanitization rules.

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

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

States a specific verb+resource (写进知识库 / write Markdown into knowledge base) and clarifies the semantics of create-vs-overwrite in the first sentence. It distinguishes itself from siblings by explicitly noting it is an overwrite write, contrasted with kb_append for appending.

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

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

Gives explicit when-to-use ('保存新学到的战术、怪物习性、本局结论') and explicitly names the alternative for the append case ('想追加请用 kb_append'), plus a follow-up suggestion (kb_search) for spot-checking. Alternatives and conditions are spelled out.

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 and mostly meets it: it discloses the multi-frame requirement (≥3) and the graceful-degradation path — service unavailable yields in-process synthetic frames tagged with _fallback and never throws. It does not cover auth, rate limits, or timing costs, leaving minor 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?

Front-loaded one-line summary followed by clearly labeled 用途 / 入参 / 返回 / 下一步 sections. Every sentence carries distinct information — payload, frame count, fallback behavior, follow-on tools — with no filler.

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

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

An output schema exists, yet the description still sketches the return shape (self state + entities list) and the _fallback flag, which is exactly the operationally important part. Combined with the frame-count and degradation notes, nothing an agent needs to call this correctly is missing.

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

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

The tool takes zero parameters and the description confirms this ('入参：无'), so there is nothing to disambiguate. Baseline of 4 applies for a no-parameter tool.

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

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

States a specific verb and resource ('获取当前游戏画面状态') and enumerates the payload (own HP, nearby entities list). It also positions itself relative to a sibling by naming predict_all_entities as its downstream consumer, so an agent can distinguish it without opening the schema.

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?

Explicit guidance: call 'each decision step before acting', call at least 3 consecutive frames for prediction to be valid, and explicit next steps (predict_all_entities or kb_search). This is the when/when-not/alternatives pattern done well.

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 and does so well: it discloses the no-input/history dependency, the max-8 threat-sorted output, the confidence < 0.65 gating rule (prediction_trusted=false, x_predict/y_predict null, 'don't trust it'), and the insufficient_data fallback. These are exactly the edge-case behaviors an agent needs.

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

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

Front-loaded one-line purpose followed by a labeled 用途/入参/返回/下一步 structure. Slightly long due to the field list, but each block adds actionable information and there is no filler.

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

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

For a 0-param tool with an output schema, the definition is fully complete: it covers purpose, dependency, next step, the confidence-gating edge case, and the insufficient_data failure mode. Nothing an agent needs to call it correctly is missing.

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

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

Zero parameters, so baseline is 4. The description reinforces this by explicitly stating '入参：无' and explaining the implicit input dependency (accumulated perceive_game history frames), which the empty schema cannot convey.

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

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

States a specific verb and resource ('预测画面中全部实体未来约 1.2 秒的位置') with a precise scope (all entities, ~1.2s horizon). It is clearly distinguishable from perceive_game (current-frame perception) and game_action (acting), so an agent can tell these apart without opening a schema.

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

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

Gives a clear use context ('判断威胁、决定走位与攻击目标') and the next-step routing to game_action's move/attack. It also flags the prerequisite that the call depends on prior perceive_game history frames. It stops short of stating when not to use it or naming an alternative predictor, so it is not a full 5.

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

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

With no annotations, the description carries the full burden. It discloses that this is a read operation, details the optional parameter's effect, and specifies the return text including a no-record message. However, it omits permissions, safety profile, and whether it has any side effects beyond reading.

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 purpose, then cleanly organized into 入参, 返回, and 下一步 sections. Every sentence serves a distinct function with no 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?

For a simple one-parameter read tool with an output schema, the description covers purpose, parameter behavior, return format, edge case, and next-step guidance. It is nearly complete, missing only minor details like matching strictness (exact vs substring).

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

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

Schema description coverage is 0%, so the description must compensate. It fully explains the single parameter: boss_name is optional, omitting it returns all records, and providing it filters by name match. This adds substantial meaning beyond the schema's bare 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 states a specific verb (读取) and resource (知识库里记录的 BOSS 行为习惯), clearly distinguishing it from general knowledge base tools by its focus on BOSS behavior records. It does not explicitly name sibling alternatives like kb_search, but the intent is unambiguous.

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 implies usage context by saying '把习性用于决策' and directs to kb_append for writing new observations. However, it lacks explicit guidance on when to use this tool versus general query siblings such as kb_search or kb_list.

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 and does reasonably well: it discloses that all historical frames are destroyed, explains the purpose (avoiding old-trajectory misjudgment), states the return type (确认文本, confirmation text), and specifies the necessary follow-up action. It does not mention permissions, reversibility, or side effects beyond the cleared frames.

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 core action, then concisely lists usage, parameters, return value, and next step. Every line earns its place, with no redundant or filler 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?

For a simple zero-parameter reset with an output schema, the description supplies everything an agent needs: what it does, when to call it, that it takes no arguments, what it returns, and what to do next. Nothing essential is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description confirms this with 入参：无, and there is no additional parameter meaning to provide.

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

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

The description states a specific verb and resource: 清空预判模块的全部历史帧 (clear all historical frames of the prediction module). This distinguishes it from siblings like clean_cache, which operate on other caches, and names the exact module affected.

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

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

It gives explicit triggering contexts: 新开一局、重生、或画面大幅跳变后调用 (call after a new game, rebirth, or large screen jump). It also provides the follow-up step of re-calling perceive_game to accumulate frames. However, it does not state when not to use the tool or an explicit alternative to use 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?

With no annotations, the description carries the full burden and discloses several behavioral traits: accepted input forms, return messages for success, dry-run mode, and error handling with listing of valid options. It does not state whether the operation requires specific game state permissions, whether it is reversible, or other side-effect details, but the return and dry-run disclosures are substantial.

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 clear segments for purpose, input, return values, and next step. It is front-loaded with the action, and every section adds useful information. It is slightly longer than strictly necessary because it describes return messages despite an output schema existing, but the extra context is justified for a zero-coverage parameter.

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, 0% schema coverage, and an existing output schema, the description is largely complete: it covers parameter semantics, return behavior (including dry-run and error), and a next-step workflow. The main gap is the absence of explicit guidance on when to choose this over sibling tools like switch_tactic. Still, an agent has enough to invoke it correctly.

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

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

Schema coverage is 0%, so the description must explain the single parameter. It does so thoroughly: set_name can be a name from combat.sets (with examples like shoot/dodge/focus_mothership) or an abstract name (combat/tank/retreat/chase/team) that is translated through combat.set_map. This fully compensates for the empty schema description.

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

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

The description states a specific verb and resource: '切换当前套装 / 阵型' (switch current set/formation). It clearly tells an agent what the tool does, but it does not explicitly differentiate from the sibling switch_tactic, even though both are switching operations. The resource is clear, but sibling differentiation is left to the name.

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

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

The description gives no guidance on when to use this tool versus alternatives like switch_tactic or game_action. It mentions a follow-up step ('下一步：perceive_game 确认切换生效'), but that is workflow context after invocation, not criteria for selecting this tool. This leaves 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?

With no annotations, the description carries the full burden. It does disclose the success message and the error condition (invalid filename or non-existent document returns error text), which is useful. However it omits whether the setting persists across sessions, its scope, or idempotency, so a mutation-style state change is only partially characterized.

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 broken into labeled sections (用途/入参/返回/下一步) and is front-loaded with the core action. Every sentence carries distinct information with no 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?

An output schema exists, yet the description still summarizes the return and error text, which is helpful. Combined with parameter meaning and follow-on guidance, it is nearly complete, though persistence/scope behavior of the 'current tactic' state remains unstated.

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

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

Schema coverage is 0% (the schema only names 'tactic_file: string'), so the description must compensate, and it does: it explains the parameter is a document name within the knowledge base. It still does not give format constraints or examples for a valid file name, keeping it from a 5.

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

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

The description states a specific verb and resource: '指定知识库里的一份 Markdown 文件作为「当前战术」' (set a Markdown file as the current tactic), and distinguishes the intent from mere retrieval. It does not disambiguate against the potentially confusing sibling switch_set, which keeps it short of a 5.

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

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

It explains the point of the operation ('让后续决策直接读取这份战术，不用每次重新检索') and names follow-on tools ('配合 kb_search / kb_append 迭代这份战术'). It gives clear context for when to reach for it but offers no explicit when-not or alternative-selection rule.

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

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

With no annotations, the description carries the burden. It discloses the return format (Markdown text manual) and a dynamic behavior (tool list generated at runtime, always consistent). It does not mention read-only safety or permission requirements, but for a manual-return tool this is largely implied.

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

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

The description is well-structured with labeled sections (用途, 入参, 返回, 下一步) and front-loaded with the core purpose. Every sentence adds useful information 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 simple one-parameter tool with an output schema, the description covers everything an agent needs: purpose, when to use, parameter values, return format, and a recommended next step. It is complete and actionable.

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 schema has no enum, so the description fully compensates by listing all five section values (all, quick, tools, chains, notes) and explaining what each returns. This is exactly the kind of semantic enrichment needed.

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

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

States a specific verb (返回) and resource (本服务的使用手册), and specifies its audience and scope (for newly connected Agents). It clearly distinguishes itself from all sibling tools as the onboarding guide, and even names itself as the first call in a recommended chain.

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

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

Explicitly says to call it first when first connecting, and provides next steps (perceive_game → predict_all_entities → game_action). It does not state when not to use it, but for a unique guide tool the context is clear enough.

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