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

No annotations are provided, so the description carries the full burden of behavioral disclosure. '获取' (get) implies a read-only operation, but the description says nothing about authentication, device-connection requirements, failure modes, or freshness of the returned activity data. It adds almost nothing beyond restating the name.

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

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

A single short sentence with zero waste and the core resource front-loaded. It is concise, though its brevity borders on under-specification rather than efficient communication.

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, relieving the description of explaining return values, and both parameters are fully documented in the schema. Still, for a tool with no annotations, the description omits essential operating context (device connection, client-type meaning) that an agent needs before invoking it correctly.

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

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

Schema description coverage is 100%, so both parameters (addr – ADB device address, client – client type) are already documented in the schema. The description adds no meaning beyond the schema, making the baseline of 3 appropriate.

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

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

The description states a specific verb and resource ('获取游戏当前活动信息' – get current game activity info), which is unambiguous about what the tool returns. However, it offers no differentiation from the many sibling maa_ tools (e.g., maa_check, maa_fight, maa_version) whose scope could plausibly overlap.

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

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

There is no guidance on when to use this tool versus alternatives such as maa_check or maa_version, nor any stated prerequisites (e.g., a connected device, an initialized MAA instance). The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the burden. '检查' implies a non-mutating probe, but the description never states that it is read-only, safe to call anytime, or what happens when the CLI is absent; the output schema partially covers the response side.

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

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

One short sentence with no waste, front-loading the check-installation purpose ahead of the version detail.

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

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

With no parameters and an output schema present, the description needn't explain return values. The only real gap is the unresolved overlap with maa_version and install-related siblings, which an agent would need to resolve before choosing.

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 there is nothing for the description to disambiguate. Baseline 4 applies for a no-arg 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: checks whether MAA CLI is installed and reports version info. The purpose is clear from the description alone, but it does not distinguish itself from the sibling maa_version, which plausibly overlaps in reporting version information.

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 call this versus maa_version, maa_install_cli, or maa_update_cli. An agent must guess whether this is a prerequisite probe before install/update or a plain version query.

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. '清除' implies a destructive mutation, but nothing is said about what exactly is removed, whether the removal is recoverable, whether Ama is required to be stopped, or what side effects occur. One phrase that essentially restates the title is far below the bar for an unannotated destructive 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?

A single short sentence with zero filler, and the action is front-loaded. It is efficient, though the brevity is really under-specification rather than disciplined conciseness.

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

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

The tool is simple (one optional param, output schema present), but with no annotations a description of a cache-purging operation needs to disclose at least the scope of what is deleted. As written it does not provide enough for an agent to call it with confidence.

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

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

The single 'targets' parameter carries a 100% schema description ('要清除的缓存类型，多个用空格分隔'), so the format is fully documented in structured data. The description adds nothing beyond it, which is the expected baseline when schema coverage is complete.

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 (clear MAA cache), which is enough for an agent to distinguish it from lifecycle siblings like maa_startup or maa_update_cli. It does not, however, explain how it differs from maintenance-adjacent siblings (maa_update, maa_hot_update, maa_self_update) beyond the word 'cache'.

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

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

There is no indication of when to clear the cache, when not to, or what alternative to use. An agent has no way to know whether this is routine cleanup or a recovery action, nor whether it should precede maa_update or maa_hot_update.

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 full behavioral burden. It only says 'close the client' without disclosing whether it force-terminates, requires ADB connectivity, what happens if the client is not running, or any side effects. For a state-changing tool, this is a significant transparency gap.

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

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

The description is a single, front-loaded sentence with no redundant or filler text. It is concise, though its brevity contributes to under-specification rather than being a structural flaw.

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 no annotations and a state-changing operation, the description is too minimal to be complete. It does not mention that the address is optional or how the client type affects behavior, nor does it provide any operational context for correct invocation. The output schema covers return values, but behavioral and usage context are missing.

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

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

Schema description coverage is 100%, so the schema already defines both parameters (addr and client) with defaults. The description adds no additional meaning beyond what the schema provides, which is acceptable at baseline 3 when the schema is fully documented.

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: '关闭' (close) the '明日方舟游戏客户端' (Arknights game client). It is clearly distinguishable from maa_startup by action, but it does not explicitly contrast itself with sibling tools or mention scope (e.g., all instances, ADB targets).

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

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

There is no guidance on when to use this tool versus alternatives like maa_startup, nor any prerequisites or exclusions. The agent is left to infer that this should be called to terminate the game client, but no context is 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 supplied, so the description carries the full burden and does not meet it: it doesn't say whether an existing output file is overwritten, whether the target format can be inferred from the file extension, or what happens on malformed input. The only behavioral signal is the list of supported formats.

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

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

A single short sentence with no filler, and the resource and supported formats are front-loaded. It is efficient rather than padded, though it verges on under-specification.

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 schema and output schema cover the mechanics, but key behavioral questions remain unanswered for a file-writing tool: how `format` behaves when omitted (default is an empty string), and whether `output_file` null means in-place or stdout. For a tool with no annotations, the description should resolve at least the format-inference rule.

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 100%, so all three parameters are already documented in the schema; the description adds nothing beyond restating the format values. Baseline 3 is appropriate, and notably it does not clarify the ambiguous empty-string default for `format`.

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

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

States a concrete verb+resource: converting configuration file formats, with the supported formats (JSON/YAML/TOML) named in parentheses. Its function is plainly distinct from every sibling (maa_run, maa_install, maa_infrast_* etc.), though it never explicitly contrasts itself with any of them.

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

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

There is no guidance on when to use this versus other tools, no prerequisites, and no mention of alternatives. The agent must infer that this is the format-conversion utility purely from the verb in the 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 behavioral burden and supplies none: it says nothing about side effects, whether a task is launched/queued, whether the CLI or game must be running, permission requirements, or what happens on invalid URIs. For an execute-style tool this is a serious 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?

A single four-character phrase is not wasteful in length but is under-specified rather than concise; there is no front-loaded statement of action or scope that an agent could act on.

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 needn't be explained, but with one required parameter, no annotations, and an execution-flavored tool, the description should at minimum state what the tool does and what the URI triggers. None of that is present.

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 100% – the maa_uris parameter already documents the space-separated URI/local-path format. The description adds nothing beyond the schema, so the baseline 3 for fully documented params applies.

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?

"自动抄作业" is slang that conveys roughly 'automatically run a shared task/strategy file', which is more than a pure restatement of the title, but it never names the resource or the action precisely (execute a MAA copilot task JSON/URI). Nothing distinguishes it from sibling copilot tools such as maa_sscopilot or maa_paradoxcopilot, so an agent cannot pick correctly from the name alone.

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

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

There is no explicit when-to-use, when-not-to-use, or prerequisite information. The only implicit cue is '自动', suggesting an automation/execution action, which is far too thin given three copilot-flavored siblings competing for the same intent.

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 supplied, so the description carries the full disclosure burden, yet it says nothing about whether the operation is read-only, whether the path is guaranteed to exist or is created on demand, or what happens for an uninstalled/invalid directory type. With an output schema present, return-shape explanation is not required, but the behavioral profile is essentially undocumented.

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 phrase with zero waste and is trivially front-loaded, but for a tool with no annotations and no usage context it reads as under-specification rather than disciplined 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?

The tool is simple (one required string parameter), the schema fully documents the accepted values, and an output schema covers the return value, so little is missing structurally. However, with zero annotations and no usage or behavioral note, the description leaves an agent without the safety and context framing it would otherwise need.

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 100% and the single dir_name parameter already enumerates all seven accepted values in the schema, so the description adds nothing beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.

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 Chinese description pairs a specific verb (获取/get) with a specific resource (MAA 目录路径/directory path), which is unambiguous. Among siblings that are almost all action commands (startup, install, update), this read-only path lookup is intrinsically distinguishable, though the description itself does not name any sibling or scope boundary.

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

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

There is no statement of when to call this tool, what prerequisite context it requires, or which alternative to prefer for related needs. The usage is only inferable from the tool name and purpose, with no explicit guidance in the description text.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does add one genuinely valuable guarantee beyond the schema: it will never spend Originite Prime to replenish sanity. But it says nothing about blocking/long-running behavior, what happens when sanity runs out, or failure handling — gaps that matter for an 8-param mutation-style task.

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

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

Two short lines with the purpose front-loaded and the safety caveat second — nothing wasted. The caveat earns its place because it constrains how the agent may use medicine/count parameters, though it restates the absence of a schema field rather than describing present ones.

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 needn't be explained, and all parameters are documented in the schema. Still missing for a long-running, potentially blocking task: prerequisites (game running, account state), what timeout=600 governs, and how client_type interacts with failures. Adequate but with clear 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 description coverage is 100%, with every parameter (addr, count, stage, series, timeout, medicine, expiring_medicine, client_type) documented in the schema itself. The description adds only the negative clarification about the absent Originite parameter, which is a useful semantic boundary but not parameter detail beyond the schema. Baseline 3 applies.

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: '运行战斗任务（刷关卡）' — running a combat/stage-farming task, which is concrete and actionable. However, it does not distinguish itself from combat-adjacent siblings like maa_copilot, maa_roguelike, maa_paradoxcopilot, or maa_reclamation, so the agent must infer which combat entry point applies.

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 purpose ('刷关卡' / farm a stage) implies when to use it, but there is no explicit statement of when to prefer this over maa_copilot or maa_roguelike, nor any prerequisite guidance (e.g. whether maa_startup must run first). Usage is only implied.

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

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

With no annotations provided, the description carries the full disclosure burden, and it says nothing about what the update mutates, whether it needs network access, whether it overwrites existing resources, or whether it is reversible. The presence of an output schema covers return values, but the mutation behavior itself is undisclosed.

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

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

A single short phrase with no filler, so it is not verbose. But it is under-specified rather than efficient — the brevity comes at the cost of the context an agent needs.

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 absence of parameters and the presence of an output schema lower the burden considerably, so the description does not need to explain results. Still, for a state-changing operation with zero annotation coverage, the agent is left without any indication of effects, prerequisites, or how it differs from the other update tools.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and no schema gap to compensate for. Baseline 4 applies.

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 identifies a specific verb ('manually update') and resource ('hot-update resources'), so the basic action is inferrable. However, it does not differentiate from closely named siblings such as maa_update, maa_self_update, maa_update_cli, and maa_update_core, leaving the agent unsure which update path applies.

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

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

No when-to-use context is given, and no alternative is named despite five sibling tools whose names also imply updating. The word 'manually' vaguely hints at an on-demand trigger versus automatic updates, but this is never made explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the bare action. It does not say whether importing overwrites existing configuration, where the config is written, whether it validates the file, or what happens on conflict.

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

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

A single short phrase with no wasted words, but that terseness comes at the cost of any structure or front-loaded guidance. It is concise but under-specifies rather than efficiently informing.

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

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

The tool is a mutation-style import with no annotations, and although an output schema exists (so return values need not be explained), the description says nothing about overwrite behavior, destination, permissions, or the meaning of the type parameter in context. For a config-import operation this is a significant gap.

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

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

Schema description coverage is 100%, so both parameters (type with its default and enumeration of cli/profile/infrast, and file_path) are already documented in the schema. The description adds no extra meaning about format, relative-vs-absolute paths, or interaction between type and file_path, so baseline 3 applies.

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 verb (导入) and resource (配置文件), but it is terse and does not distinguish this from siblings such as maa_install, maa_init, or maa_convert, all of which also involve configuration handling. An agent reading only this line cannot tell precisely what makes maa_import unique.

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

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

There is no indication of when to use this tool versus the many other setup/install/config siblings (maa_install, maa_init, maa_install_cli, etc.). No prerequisites, no exclusions, and no alternative routing 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 the full behavioral burden, yet it says nothing about side effects, whether sanity/energy is consumed or granted, whether it requires an active game session, or whether it can fail partway. For what appears to be a state-changing automation action, this is a critical 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?

At six characters the text is not concise but under-specified; there is no front-loaded statement of action, scope, or outcome. Brevity here costs comprehension rather than saving anything.

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 output schema covers return values and the single parameter is documented, but with no annotations and no behavioral text, an agent cannot know the preconditions or effects of invoking this action. Given ~30 sibling tools, the definition is not complete enough to call safely.

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 (client, default "Official") exists and schema description coverage is 100%, so the schema already documents it fully and the description adds nothing. Baseline 3 applies when the schema does the work.

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 "基建收取理智" essentially restates the tool name (base/infrast + collect + sanity≈energy) in Chinese rather than stating a distinct operation. It does not distinguish this from siblings such as maa_infrast_production, maa_infrast_trade, maa_infrast_purchase, or maa_infrast_switch, all of which are equally plausible 'base infrastructure' actions.

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

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

There is no statement of when to use this versus the other five infrast tools, no prerequisites (e.g. game must be running, base configured), and no exclusions. The agent must infer timing and alternatives entirely from the tool name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Manage' and examples like manufacturing and purchasing imply state-changing in-game actions, but the description does not state side effects, resource consumption, prerequisites, or whether operations are reversible.

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 phrase with the core purpose front-loaded and no wasted words. The parenthetical examples add useful scope but remain brief.

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

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

Although the parameter set is simple and an output schema exists, this is an unannotated action-oriented umbrella tool among many specific infrastructure siblings. The description does not clarify its exact scope, how it interacts with sibling tools, or what side effects an agent should expect.

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

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

There is only one parameter, and schema description coverage is 100%, so the schema already documents the 'client' parameter. The description adds no parameter-specific meaning beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific resource domain ('基建管理') and gives examples of included activities (auto shift change, manufacturing, purchasing). However, it does not differentiate this umbrella tool from dedicated siblings such as maa_infrast_production, maa_infrast_purchase, or maa_infrast_trade.

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 parenthetical examples imply some coverage, but there is no explicit guidance on when to use this tool versus the many sibling infrastructure tools or when not to use it. The agent is left to infer selection criteria.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the bare action: no permission/state requirements, no resource cost, no indication of whether starting a task is repeatable or conflicts with a running task. It is not misleading, but it adds almost no behavioral information for an action 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?

It is one short sentence with no waste and the action is front-loaded, but the terseness reflects under-specification rather than disciplined editing — there is no operational content beyond the name-level phrase.

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 and a fully documented single parameter reduce the burden, but for a game-action tool with no annotations the description should at least state requirements and what the returned result means for the started task. As written, an agent cannot tell what state it must be in or what side effects to expect.

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

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

The single 'client' parameter has 100% schema coverage including a default of 'Official', so the schema already does the explanatory work. The description adds nothing about valid client values or when to change the default, which is the expected baseline for full 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 names a specific action (start a manufacturing task) in a specific subsystem (infrastructure/base production), with the parenthetical '开始制造任务' removing ambiguity about whether it configures or starts production. It is distinguishable from siblings like maa_infrast_trade or maa_infrast_purchase, though it never names those alternatives to reinforce the distinction.

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

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

There is no guidance on when to use this versus maa_infrast_manage or maa_infrast_switch, no stated prerequisites (e.g. being in the base, having materials), and no mention of what happens after the task is started. The agent must infer all operational 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?

With no annotations, the description carries the full behavioral burden, yet it discloses nothing about cost, what items are bought, whether the action is automated/irreversible, or what permissions/config are needed. The parenthetical only restates the verb rather than adding behavioral context.

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 phrase with no wasted words and is front-loaded, but its brevity crosses into under-specification rather than efficient conciseness.

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

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

An output schema exists and the parameter is well documented, so those are covered. But with zero annotations and many closely related sibling tools, the description should explain domain context and when this purchase action applies, which it wholly omits.

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 100% (the single 'client' parameter is documented in the schema with a default), so the baseline of 3 applies. The description adds no additional meaning about what 'client' controls in this context.

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

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

The description names a specific action and resource ('infrast purchase / buying materials'), so the agent knows it is a procurement action. However, it gives no domain framing and does not distinguish it from strong siblings such as maa_infrast_trade or maa_infrast_manage, which plausibly also involve acquiring items.

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

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

There is no guidance on when to use this instead of maa_infrast_trade, maa_infrast_manage, or maa_infrast_production, and no prerequisites or exclusion conditions are stated. The agent must infer usage purely from the name.

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

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

No annotations are provided, so the description carries the full burden. It discloses nothing about state mutation, whether shifts replace existing assignments, whether the operator must be free, or what happens on conflict — critical for a mutation-style game automation 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?

Four characters is not concise but under-specified; there is no front-loaded statement of what the tool does beyond a label. Brevity here reflects missing content rather than efficient writing.

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

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

An output schema exists, so return values need not be explained, but the description leaves the core operation undefined for a two-parameter mutating tool with no annotations. An agent cannot reliably know what this call changes in game state.

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 100%: both parameters (room with enumerated values, operator) are documented in the schema itself. The description adds no extra meaning, so the baseline of 3 applies when structured data does the heavy lifting.

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?

"基建换班" (infrastructure shift change) is a near-restatement of the title with no expansion. It hints at swapping personnel in the base facility but doesn't specify the operation, scope, or how it differs from siblings like maa_infrast_manage or maa_infrast_production.

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

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

There is no guidance on when to use this tool, no prerequisites, and no mention of alternatives among the many maa_infrast_* siblings. The agent is left to infer everything from a four-character phrase.

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 full behavioral burden. It implies a mutation (selling materials) but says nothing about what gets consumed, whether the action is reversible, or any permission/rate 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?

A single short phrase with zero filler and the key concept front-loaded. It is compact, though the brevity borders on under-specification rather than efficient structure.

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 needn't be spelled out, but for an unannotated mutation tool in a large sibling family, the description omits the behavioral and contextual details an agent would need to invoke it confidently.

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

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

There is only one optional parameter, 'client', and the schema already documents it with a description and a default of 'Official' (100% coverage). The description adds nothing beyond that, so the baseline 3 applies.

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

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

The description '基建贸易（出售物资）' names the resource (infrastructure trade) and narrows it to selling materials, which does distinguish it from the sibling maa_infrast_purchase. However, it is too terse to convey what the trade actually affects or outcomes, so the purpose is only broadly identifiable.

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

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

There is no statement of when to use this tool versus maa_infrast_purchase, maa_infrast_production, or maa_infrast_manage. The 'sell' nuance implies a direction but gives no preconditions or exclusion rules.

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 disclosure burden. It does not say whether init overwrites an existing configuration, whether it is idempotent, or what the 'force' flag changes—despite the presence of a 'force' parameter strongly implying destructive/reinitialization 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?

The single short phrase is front-loaded and free of waste, but it is under-specified rather than well-scoped. Brevity here costs more clarity than it saves.

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

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

Although an output schema exists (reducing the need to describe returns), the definition leaves the core behavior—what gets initialized, overwrite semantics, and the effect of 'force'—undocumented in a large sibling set with no annotations or parameter descriptions to fall back on.

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

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

Schema description coverage is 0% for two parameters ('name' and 'force'), and the description mentions neither. It does not clarify what 'name' selects (a config profile?) or what 'force' overrides, leaving both parameters entirely undocumented.

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 verb and resource ('initialize MAA configuration'), which is more than a bare name restatement, but gives no detail about what is initialized or how it differs from close siblings like maa_startup and maa_install. An agent cannot distinguish init from startup/install without guessing.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the 30+ siblings. The agent must infer whether init must precede maa_startup or is optional.

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 bears the full disclosure burden. It says nothing about what gets downloaded, whether existing files are overwritten, network or permission requirements, or the operation's reversibility — significant gaps for an install/mutation tool.

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

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

A single short sentence with the action and resource front-loaded and a parenthetical qualifier that earns its place. No filler or redundancy.

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

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

An output schema exists, so return-value detail is not needed, and a zero-param tool keeps the surface small. However, for a first-run install the description omits prerequisites and any note on relationship to maa_update_core, leaving the agent guessing about sequencing.

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 there is nothing for the description to disambiguate; baseline 4 applies. No parameter-level misunderstandings are possible.

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 (安装/install) and concrete resource (MaaCore 及资源), so the agent knows exactly what the tool does. It does not explicitly distinguish itself from close siblings like maa_update_core or maa_install_cli, though the 'first use' note hints at the boundary.

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 parenthetical '(首次使用需要)' gives an implied condition for use — first-time setup. It does not tell the agent when to prefer this over maa_update_core or maa_install_cli for subsequent/CLI scenarios, leaving the alternatives unaddressed.

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 does not say whether installation is destructive, whether it overwrites existing files, what permissions/network access are needed, or how long it takes. The presence of an output schema relieves it of explaining return values, but the operational behavior of an install operation remains undisclosed.

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?

It is a single short phrase with no wasted words, but the brevity reflects under-specification rather than efficiency. It is front-loaded but says almost nothing beyond the resource names.

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

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

For an install tool in a 33-sibling namespace with no annotations, the description omits prerequisites, the relationship to the install/update siblings, and any side-effect disclosure. The output schema mitigates return-value gaps, but the selection-critical context 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 single `force` parameter is fully documented in the schema (100% coverage) as forcing a reinstall. The description adds no meaning beyond that, so the baseline 3 for schema-covered parameters applies.

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

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

The description names a specific verb (安装/install) and specific resources (MAA CLI and MaaCore), which is more precise than a bare name restatement. It does not, however, differentiate itself from siblings like maa_install, maa_update_cli, or maa_update_core, leaving ambiguity about when each applies.

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

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

There is no guidance on when to use this versus maa_install, maa_update_cli, or maa_update_core, nor any stated preconditions (e.g., first-run versus repair). The agent must infer usage entirely from the tool name.

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

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

With no annotations, the description carries the full burden, but it does not explicitly state that the call is read-only, side-effect free, or cheap. Because it has zero parameters and an output schema, the risk of misuse is low, so 'list all available' conveys most of the behavior implicitly.

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

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

A single short sentence with the resource front-loaded and no filler. It is efficient, but so terse that it omits practically all supporting context.

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?

Because an output schema exists, return values need not be described. However, for a discovery tool that sits alongside ~35 action tools, the description should tell the agent how the output connects to the rest of the toolset (for example, 'use these names with maa_run'). That link 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 has zero parameters, which is the baseline for a 4. No parameter explanation is needed, and the description correctly implies the call is unfiltered ('所有').

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 ('列出' + '所有可用的预定义任务'), so an agent knows it is a listing/discovery call. It does not differentiate itself from the many sibling tools (maa_run, maa_startup, etc.), so it falls 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?

There is no indication of when to call this versus the alternatives, nor any hint that the returned predefined task names are the inputs expected by maa_run or similar execution tools. The only usage signal is the implicit 'list things' framing.

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 disclosure burden, yet it says nothing about whether this starts an asynchronous run, blocks, requires the game to be launched first, or what side effects it has. The presence of an output schema relieves some of the burden of explaining return values, but operational behavior remains undisclosed.

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?

It is short, but it is not concise in the useful sense — a single four-character phrase that conveys nothing beyond the title. Brevity here reflects under-specification rather than disciplined editing.

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 1 required param and an output schema the structural side is covered, but a tool sitting in a family of 34 similarly prefixed automation tools needs at minimum a statement of what operation it performs and when to prefer it over maa_copilot or maa_sscopilot. That is entirely missing.

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

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

Schema description coverage is 100% and the single param 'maa_uris' (space-separated URIs) is fully documented in the schema. The description adds no additional meaning, so the baseline of 3 applies.

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 is essentially a restatement of the tool name ('Paradoxcopilot' → 'paradox simulation'), with only the modifier 'automatic' added. It gives no indication of what the tool actually does at runtime (start a task? list jobs?) or how it differs from close siblings like maa_copilot, maa_sscopilot, and maa_roguelike.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. An agent must guess entirely from the name that this is the 'paradox simulation' variant among many similarly named automation tools.

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

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

With no annotations, the description carries the full burden of disclosure, yet it says nothing about side effects, in-game resource consumption, prerequisites (account/login state), duration, or whether the operation is interruptible. 'Automatic' hints that it runs unattended but conveys no behavioral contract.

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?

It is short, but this is under-specification rather than conciseness — there is no front-loaded statement of purpose, scope, or outcome, only a restated label.

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

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

Although an output schema exists, the description gives an agent nothing about what initiating an automated Reclamation run entails, how long it runs, or what conditions must hold. For an automation trigger tool with zero annotations, this is far too thin.

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 100% and the single 'theme' parameter has a default and a description noting only 'Tales' is currently available. The description adds nothing, but the schema already does the work, so baseline 3 applies.

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 is four characters, "自动生息演算", which essentially restates the tool name and title ('Maa Reclamation') plus the word 'automatic'. It gives no verb and no resource beyond what the name already says, and does nothing to distinguish it from siblings like maa_roguelike or maa_fight.

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

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

There is no guidance on when to use this tool, when not to, or which sibling to pick instead. An agent has no signal for choosing maa_reclamation over maa_roguelike or maa_fight.

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 implies significant side effects (it starts new recruitment jobs) but says nothing about ordering of collect-then-start, what happens when there are no results, whether it blocks, or what failure looks like — all important for a state-changing 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?

A single short sentence with both actions front-loaded and zero filler. Nothing to trim.

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 needn't be explained. However, for a composite mutation tool with no annotations, the definition leaves behavioral gaps — sequencing, idempotency, and failure behavior — that an agent would want before calling it.

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

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

Schema coverage is 100% for the single 'client' parameter, so the schema already documents it. The description adds no meaning about the client parameter or its default, which is acceptable under the high-coverage baseline but yields no extra value.

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 two concrete operations — collecting all recruitment results and starting a new recruitment — so the agent knows exactly what the tool performs. It is clear on verb and resource, but it never mentions it is a composite of maa_recruit_collect and maa_recruit_start, which are both siblings, so the differentiation is left implicit.

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?

"一键" (one-click) implies this is the convenience path versus doing collect and start separately, but the description never says when to prefer it over maa_recruit_collect or maa_recruit_start, nor any preconditions. Usage is only implied, not stated.

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

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

No annotations are supplied, so the description carries the full burden. It does not state whether collecting consumes or redeems the recruitment slots, what happens when no result is available, or what state changes occur — all critical for an automation 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 single four-character phrase contains no filler, but it is terse to the point of under-specification for a tool with side effects and multiple near-identical siblings.

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?

No annotations, no usage routing, and no mention of side effects or state, despite an output schema and a crowded sibling namespace. The description is not complete enough for an agent to invoke this confidently over its siblings.

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 100%, so both the slot index (0-3) and client type are fully documented in the schema. The description adds no parameter meaning beyond that, which is acceptable at baseline 3 given the schema's completeness.

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

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

States a concrete verb and object (收取公招结果 = collect recruitment results), which is clear enough to act on. However, it does nothing to distinguish this from the closely named siblings maa_recruit_get and maa_recruit_all, so an agent cannot tell which of the three to call.

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

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

There is no guidance on when to use this versus maa_recruit_get, maa_recruit_start, or maa_recruit_all, and no preconditions are given. The agent must infer selection from the tool 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 provided, the description carries the full burden of behavioral disclosure, yet '获取当前公招结果' says nothing about whether this is read-only, whether it requires a prior maa_startup or recruitment state, or what happens when no recruitment is active. The implicit read nature is helpful but insufficient for a tool with zero annotation coverage.

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

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

A single short phrase with no filler, front-loaded with the action. It is efficient, though the terseness edges toward under-specification rather than optimal structuring.

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 needn't be explained, and the single optional parameter is fully documented by the schema. Still, the description omits state prerequisites and sibling differentiation, leaving meaningful gaps for an agent operating among many maa_recruit_* 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 100%, covering the single optional 'client' parameter, so the baseline is 3. The description adds no extra meaning about the client selection or its defaults beyond what the schema already documents.

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 verb 获取 (get) plus resource 公招结果 (recruitment results) makes the operation identifiable at a glance. However, it never distinguishes itself from close siblings like maa_recruit_collect or maa_recruit_all, which plausibly return similar recruitment data, so an agent must guess between them.

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

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

There is no statement of when to use this tool versus maa_recruit_collect, maa_recruit_all, or maa_recruit_start, and no prerequisites or preconditions are given. The agent is left to infer the usage context entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only says "start". It does not disclose that this is a mutating in-game action, whether it consumes resources, what happens if a recruitment is already in progress, or what permissions/connection state are needed.

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 single four-character phrase is not concise-but-complete; it is under-specification. There is no front-loaded scope, no key constraint, and no routing information – nothing that earns its place beyond the tool name.

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

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

An output schema exists so return values need not be explained, and parameters are fully documented in the schema. But with zero annotations and no usage context, the definition leaves an agent unable to tell when this action should fire relative to its recruit siblings or what state it requires.

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 100%, with tags, time and client all documented with examples (including the 300/1800/7200/28800 time mapping). The description adds nothing beyond the schema, so the baseline 3 applies.

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?

"开始公招" only restates the tool name maa_recruit_start – a start verb plus the same resource. It conveys no scope, no distinction from siblings like maa_recruit_get, maa_recruit_collect or maa_recruit_all, so an agent must infer what starting a recruitment actually entails.

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

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

There is no guidance on when to call this versus the three sibling recruit tools (get/collect/all), no mention of prerequisites such as the game client running or MAA being connected. The agent is left to guess at ordering within a recruitment workflow.

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 disclosure burden. It implies a pure computation returning an offset value but says nothing about whether it is side-effect free, how the timezone affects the result, or what the returned offset means — leaving the agent to guess at 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?

A single short sentence with zero padding, so nothing is wasted, but the brevity comes at the cost of substance rather than from efficient front-loading. It is under-specified rather than 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?

An output schema exists and the input schema is fully documented, which covers the return-value burden. However, the core concept ('DayMod condition offset') is never defined, so for a domain-specific tool in a 35-sibling suite the description is not complete enough for correct invocation.

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

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

Schema description coverage is 100% with only two optional parameters (divisor, timezone), both already documented in the schema, so baseline 3 applies. The description adds no meaning beyond the schema — notably it never explains how 'divisor' relates to the 'offset' it claims to return.

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 says it 'gets the offset of the DayMod condition' (获取 DayMod 条件的偏移量), which is a verb plus a resource, but 'DayMod condition' is unexplained internal jargon and the name 'maa_remainder' suggests a remainder computation rather than an offset. With 35 sibling tools and nothing to distinguish this from task-scheduling tools like maa_startup or maa_activity, an agent cannot confidently tell what this returns.

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

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

There is no statement of when to call this tool, no prerequisites, and no reference to any alternative. The agent is left to infer usage entirely from the title and jargon term 'DayMod'.

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

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

No annotations are provided, so the description carries the full behavioral burden and delivers almost none of it: nothing about whether this is a long-running blocking task, whether it can be cancelled, what it consumes, or what it produces. The single word '自动' hints at automation but discloses no operational traits.

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?

At eight characters it is terse to the point of under-specification rather than efficient. There is no structure to front-load because there is essentially no 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?

An output schema exists, so return values need not be explained, and parameters are covered by the schema. But for a tool that presumably kicks off an automated multi-stage game run, the description leaves the agent without enough to know what will happen or when to invoke it.

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

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

Schema description coverage is 100%, with both theme (including all valid theme values) and starts_count fully documented in the schema. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

The description names a resource (集成战略/roguelike mode) and implies automated execution, so an agent can roughly infer it runs the Arknights Integrated Strategies mode. However, it never says it launches a task, and it gives no differentiation from siblings like maa_fight, maa_copilot, or maa_paradoxcopilot that also start automated runs.

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

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

There is no when-to-use guidance, no prerequisites (e.g., MAA must be connected, game running, CLI installed), and no alternatives named. The agent has to guess whether this starts, configures, or reports on the roguelike mode.

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

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

With no annotations, the description carries the full burden, and it does add one genuinely valuable behavioral fact: tasks consuming stone (>0) are rejected outright. However, it omits other important context such as required ADB/device connectivity, what happens on interactive prompts, and side effects on the game client.

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

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

Two short sentences, with the core purpose front-loaded and the rejection constraint as a clearly separated note. Efficient, though the parenthetical could arguably be trimmed.

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

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

An output schema exists and all four parameters are documented, so the remaining gap is small. The description supplies the key safety constraint (stone consumption rejection) but could mention prerequisite ADB/device setup or how batch mode interacts with interactive steps.

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 100% and each parameter (addr, task, batch, timeout) is documented inline, so the baseline is 3. The prose adds no new meaning about the parameters beyond restating task file scope.

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: run a custom task defined by a TOML/JSON task file under config/tasks. This is clearly distinguishable from sibling predefined-task tools like maa_startup or maa_fight, though it does not name any sibling explicitly.

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

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

Usage is only implied by the phrase 'custom task' and the file location — the agent can infer this applies when a user-supplied task file exists rather than a built-in task. There is no explicit when-to-use/when-not guidance or alternation with maa_startup or other fixed tasks.

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 of behavioral disclosure. It states only that the CLI is updated, without explaining permissions, network use, what a forced update does, or whether the CLI is replaced or restarted.

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 phrase with no wasted words, but it is under-specified rather than appropriately concise. It provides no structure or detail for an agent to act on.

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

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

An output schema exists, so return values need not be explained in detail. However, with no annotations and an undocumented force parameter, the definition omits essential context for a mutation tool, including prerequisites and the effect of forcing the update.

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, force, has no description in the schema and is never mentioned in the tool description. With 0% schema description coverage, the description fails to compensate for this gap, leaving the parameter's meaning entirely unexplained.

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

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

The description gives a specific verb and resource: updating maa-cli itself. It is clear what the tool does, but it does not distinguish this from likely-overlapping siblings such as maa_update_cli or maa_install_cli.

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

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

There is no guidance on when to use this versus maa_update_cli, maa_update_core, or maa_install_cli, despite several related update/install siblings. The agent is left to infer the conditions from the tool names 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 the full disclosure burden, yet it says nothing about side effects, prerequisite state, blocking/long-running behavior, or failure modes for what appears to be an automation-dispatch 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?

Six characters with no wasted words, but this is under-specification rather than conciseness — there is no front-loaded statement of purpose an agent could act on.

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 does exist, so return values need not be described, but for an automation-launch tool with no annotations and no parameter guidance the description leaves nearly everything an agent needs unanswered.

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 100% and the single required parameter maa_uri is documented in the schema itself; the description adds no meaning beyond it, so the baseline 3 applies.

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?

"自动保全派驻" merely restates the game-mode concept behind the tool name (ss = 保全派驻) without a verb or any statement of what the tool actually does — start a task? configure one? With siblings maa_copilot and maa_paradoxcopilot present, no differentiation is offered.

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

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

There is no when-to-use, when-not-to-use, or prerequisite information (e.g. whether the game must be running or the URI pre-existing), and no pointer to the closely named sibling tools that an agent would need to choose between.

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 behavioral disclosure burden. It only states the high-level action, omitting what happens if the game is already running, required permissions, device connection requirements, failure modes, or side effects. Output schema exists, so return format need not be 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?

A single concise sentence with no waste, and the core action is front-loaded. It is appropriately sized but perhaps overly sparse for a tool that launches an external application.

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 startup tool with no annotations, the description is too thin. It does not cover prerequisites (ADB connection, device state), expected behavior on success/failure, or interaction with sibling tools. Output schema reduces the need to explain return values, but other critical context 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 100%, so all three parameters (addr, client, timeout) are fully documented in the schema. The description adds no parameter-level detail, which is acceptable given the schema already does the heavy lifting.

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: launch the game (明日方舟) and enter its main interface. It is clear and unambiguous, though it does not explicitly contrast itself with siblings such as maa_run or maa_closedown.

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

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

There is no guidance on when to use this tool, what prerequisites are needed (e.g., ADB device connectivity), or how it relates to alternatives like maa_run or maa_closedown. The agent is left to infer usage context entirely.

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 full behavioral burden, but it only implies mutation via '更新'. It says nothing about whether this downloads from the network, whether it overwrites an existing installation, whether it requires permissions or a stopped instance, or whether it is reversible. For an update tool that can alter installed binaries, that is a significant gap.

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

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

A single short phrase with no padding; the resource scope is front-loaded. It is efficient, but at this length the brevity comes from under-specification rather than discipline, which is penalized under other dimensions rather than this one.

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

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

An output schema exists and zero params means the schema carries little burden, so the remaining gap is entirely about identity: the agent cannot determine what makes this different from maa_update_core or maa_hot_update. That ambiguity is the one thing the description needed to resolve and does not.

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 there is nothing for the description to clarify and the baseline of 4 applies. No parameter-related wording is needed or expected 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 names a verb and resource (update MaaCore and its resources), which is more specific than a bare restatement of the title. However, it does not distinguish this tool from siblings such as maa_update_core, maa_update_cli, maa_hot_update, and maa_self_update. maa_update_core in particular appears to overlap directly with what this description claims, leaving the agent unable to tell which one to choose.

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

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

There is no when-to-use, when-not-to-use, or prerequisite information at all. Given a sibling set containing four other update-flavored tools (maa_update_core, maa_update_cli, maa_hot_update, maa_self_update), the absence of routing guidance is a real selection hazard rather than a minor omission.

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 disclosure burden, yet it reveals nothing about the mutation: no indication of network access, download behavior, whether files are replaced, whether running instances are affected, or reversibility. For an update operation with zero annotation coverage, this is a serious gap.

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

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

The single phrase is front-loaded and waste-free, but here brevity tips into under-specification rather than economy, since no useful context is 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?

An output schema exists, so return values need not be described, and there are no parameters to cover. Even so, for a mutating update tool in a dense cluster of similarly named siblings, the description omits the selection context an agent needs.

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 there are no parameter semantics to explain; the baseline of 4 applies.

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 verb and a resource ('update MAA CLI'), so the basic action is identifiable. However, it does nothing to differentiate it from sibling tools like maa_update, maa_update_core, maa_self_update, and maa_install_cli, which an agent must distinguish between to select correctly.

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

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

There is no guidance on when to use this tool versus the many adjacent update/install siblings, and no stated prerequisites such as whether MAA must already be installed. The agent is left to infer everything about selection 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 the full burden of behavioral disclosure. It implies a mutation (“更新”) but does not describe whether the update is destructive, requires network access, replaces existing files, needs a restart, or has other 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 short phrase with no wasted words, and it front-loads the action and target. It is concise, though the extreme brevity contributes to the missing selection and behavioral context.

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 large set of update-related siblings and the absence of annotations, the description is not complete enough for reliable tool selection. An output schema exists, so return values need not be explained, but the description should still clarify scope versus related update tools and any important side effects.

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

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

The tool has zero parameters, so parameter semantics are not applicable; the schema baseline of 4 applies. The description does not need to explain parameters because none exist.

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

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

The description states a specific verb (更新/update) and resource (MaaCore and resources), so the agent can understand the basic operation. However, it does not differentiate this tool from closely related siblings such as maa_update, maa_hot_update, or maa_update_cli.

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, no prerequisites, and no exclusions. Among many update-related sibling tools, the agent is left to infer the correct choice.

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 full behavioral burden is on the description. 'Get' implies a safe read, and the output schema covers the response shape, but nothing states prerequisites such as whether either component must already be installed or what happens if it is not.

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

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

A single front-loaded sentence naming the action and both components, with no filler. Nothing could be removed without losing meaning.

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 zero-parameter read with an output schema and no annotations, the description is nearly sufficient. The only real gap is the absence of any note about failing or partial results when one of the two components is not installed.

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 there is nothing for the description to disambiguate; baseline 4 applies. The schema also confirms an empty object with additionalProperties false.

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 ('maa-cli 和 MaaCore 版本信息'), so the agent knows exactly what comes back. No sibling tool is named, but none of the listed siblings deals with version reporting, so the operation is naturally 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?

Usage is only implied: an agent can infer this is the way to check installed component versions, but the description never says when to prefer it (e.g., before calling maa_update_core or maa_update_cli) or what it does when a component is missing.

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