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

With no annotations provided, the description carries the full burden and does so: it guarantees no password/token is ever returned, explains that refresh performs a real auth-server token exchange for skin sites, and warns that failures carry a needUserAction flag requiring the user to run a terminal command. This is exactly the behavioral context an agent cannot infer from the schema.

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

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

Front-loads the resource and verb set, then uses a bulleted action table with zero filler; the warning line is placed last because it only matters after a call fails. Slightly text-heavy with bold markers, but each line adds information rather than repeating the schema.

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

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

For a 3-parameter, multi-action tool with no annotations and no output schema, the description supplies per-action return contents (innerID, game name, UUID, type, server, credential presence), session scope of the 'use' selection, and error semantics. Nothing needed to invoke it correctly or interpret common failures 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 already 100%, so the baseline is 3, but the description goes further by binding each parameter to the action it belongs to (query only for search, innerID for use, optional innerID for refresh with documented defaulting behavior). That action-parameter coupling is the kind of semantics the flat schema does not express.

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 resource (MC accounts) and four discrete verbs (list/search/use/refresh), then enumerates exactly what each action returns or does. The 'use' action explicitly hands off to mc_connect, so an agent can place this tool relative to its siblings without opening the schema.

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

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

Every action is paired with its trigger and its required argument (search→query, use→innerID, refresh→optional innerID falling back to the selected/default account), and list is declared the default. The failure path even points to the exact follow-up command for the user, leaving no routing ambiguity.

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

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

No annotations exist, so the description carries the full burden, and it discloses genuinely useful behavior: bridge waits for server confirmation per block and halts on fall/lava risk; break auto-switches tools and refuses if none fits; attack chases named entities within 24 blocks and runs ~10s; equip auto-routes armor to slots; enchant opens the window automatically. It still omits session/auth prerequisites and what happens when place/use fail.

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 priority instruction is front-loaded, followed by a tight one-line-per-mode bullet list that stays efficient despite covering 14 modes. A few schema descriptions are echoed verbatim (e.g., the equip 'to' note), which is the only redundancy.

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

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

For a 15-parameter, 14-mode tool with no annotations and no output schema, the definition covers mode selection, per-mode parameters, auto-behaviors, and safety halts well. It leaves out return/failure semantics per mode and any session prerequisite, which matters given the mode breadth.

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 80%, so the baseline is 3, but the description goes further and binds every mode to its parameters inside the mode bullets (who for look/toward/use/attack, to for equip slots, item/name/template for anvil/smithing, count for toss), adding real coupling semantics the flat schema cannot express.

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?

It states a concrete verb-plus-resource ('与游戏世界互动') and enumerates 14 modes (look/toward/place/bridge/break/use/useitem/attack/equip/enchant/anvil/smithing/toss), so an agent knows exactly what it does. However, it never distinguishes itself from siblings who overlap heavily (mc_dig for break, mc_build for place/bridge, mc_move for toward, mc_chest for use), so the boundary remains ambiguous.

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

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

It gives explicit and clear guidance: 'prefer this, don't use server commands' (which routes against mc_command), plus per-mode triggers such as look+who for 'look at me', and risk-based stop conditions for bridge. It offers no exclusions against mc_dig, mc_build, or mc_move, which is the main missing piece.

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

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

With no annotations, the description carries the full burden and does well: it discloses that mutations take effect immediately, are persisted to `~/.mcp-mc-agent/config.json`, and which keys are silent no-ops. It omits whether `reset` is reversible or requires confirmation, which matters for a tool that can wipe all configuration.

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?

Purpose and the main misuse warning are front-loaded, and the bulleted action list scans quickly. The two large legacy-key warnings consume a lot of space before the agent learns what the tool actually writes, and could be compressed without losing the anti-footgun value.

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

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

For a config tool with no output schema, it covers what is read or written, where it persists, when it takes effect, and which keys are dead. It leaves the shape of `get`/`list` responses and the failure mode of an unknown `path` unspecified, which the agent must discover by calling.

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 already 100%, so the baseline is 3, but the description goes well beyond it: it enumerates the accepted `path` values, documents value types per key (`commandWhitelist` array with exact / regex / "*" matching semantics, `memoryPerSession` boolean with its directory layout), and explains what each `action` does to `path`/`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?

States a specific verb pair (read/write) and a clearly scoped resource (mcp-mc-agent's global config) and enumerates the five actions it supports. It does not, however, distinguish itself from the sibling `mc_config`, which an agent could easily confuse with this admin variant.

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?

Each action is paired with the condition that selects it (get defaults, set needs path+value, unset reverts to default, reset restores all, list shows defaults vs effective). It also explicitly warns that `mcModePresets`/`mcPlusPresets`/`expressEnabled` are DSH leftovers with no effect, effectively saying 'do not bother using these'. It stops short of saying when to pick this tool over `mc_config`.

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

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

No annotations exist, so the description carries the full burden and does so richly: rate limit (120/hour), adaptive backoff (doubling delay up to 30 min, reset on activity), wake timings (5s idle, 45s nudge), threat detection rules (22-block ranged mobs only if line-of-sight, drowning wake triggers), and persistence to `.mcp-mc-agent/auto.json`. It also discloses the safety envelope (no tearing down others' builds, no touching chests, no wandering far), which is exactly the mutation-risk context annotations would normally supply.

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 content largely earns its place, but it is a dense wall of bolded Chinese text with heavy emoji use, and the critical action list is buried after two long conceptual paragraphs. The operational essence (what actions exist and what they do) should be front-loaded instead of arriving near the end.

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

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

For a complex, zero-annotation, no-output-schema autonomy controller, the description covers actions, defaults, persistence, rate limits, safety boundaries and escalation to the AI. The remaining gap is that `action:"status"` output content is never described, so the agent does not know what the status view returns.

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 the baseline is 3, but the description goes further by attaching behavioral consequences to each `action` value and by naming concrete `patch` keys (`standing`, `idleWakeSec`, `idleWake`, `avoid`) that the schema cannot document because `patch` is `additionalProperties: true` with no listed properties. It stops short of enumerating the full config key set, so it is strong rather than exhaustive.

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?

Opens by naming the resource ("自主行为层") and immediately states the zero-argument default ("不传参数 = 看状态"), then enumerates its two subsystems (reflex layer / idle decision layer) with concrete duties. It differentiates itself from siblings by explicitly noting that mc_say is only for asking about Master's chests/buildings and that `avoid` is a separate switch. It is not a clean verb+resource phrase, but an agent can tell what this tool owns.

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?

Provides an explicit action roster with per-action meaning (status / off / on / stay / follow / wake / set) and calls out the trap that `off` is NOT a full stop, naming the exact `set {"idleWake":false}` and `set {"avoid":false}` needed for full silence. It also states the standing instruction ("Master 在对话里改了主意 → 立刻用 set 把 standing 写成他那句新的") so the agent knows when to invoke `set` versus leaving defaults alone.

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

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

With no annotations, the description carries the full burden and does most of it: it discloses auto-navigation/pillaring, the default cap of 64, the ~10s time budget, partial-completion return fields (`used`/`held`, `remaining`, `hint`), and idempotent resumption. It does not say what happens if the inventory runs short or a cell is genuinely unreachable mid-fill, which is the main remaining gap for a world-mutating 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?

Well front-loaded: purpose, then use cases, then the time-budget warning and resumption rule. Every sentence carries information, though the emoji/bold formatting and the doubled explanation of 'just resend the same range' / 'already-correct cells are skipped' are slightly redundant.

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

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

No output schema exists, and the description covers the important return signals (`used`/`held`, `remaining`, `hint`) plus the resumption loop, which is the behavior an agent most needs. What's missing is failure-mode coverage — running out of blocks, blocked pathing — for a tool with no annotations and 8 parameters.

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

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

Schema coverage is only 25% — the six coordinate parameters carry no descriptions at all. The description partly compensates by establishing that the two triples are opposite corners of a solid cuboid and that `max` caps placement, but it never states the coordinate frame, whether corner order is interchangeable, or whether the y-bounds are inclusive.

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: fill the solid cuboid (x1,y1,z1)–(x2,y2,z2) with the named block, with a hard cap of `max`. It explicitly names the sibling it replaces for one-off placement (mc_act{place}), so an agent can choose between them without opening either schema.

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

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

Gives concrete use cases ('a wall / a pillar / a platform') plus the alternative and when to prefer it. It also states the operational constraint (keep each call to ~10 seconds) and the exact recovery protocol: re-send the identical range, already-correct cells are skipped automatically rather than erroring.

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

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

With no annotations and no output schema, the description carries the full burden: it discloses that this is a pure informational read-out, lists the categories of limits and configuration it exposes, and warns against retrying unsupported versions. It does not say whether results are cached or how static they are, but the safety/behavioral profile is effectively clear.

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

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

Two compact blocks: a bracketed scope header followed by the when-to-use rule. The content is dense with enumerated items but every clause carries information (versions, namespace, caps, config), and the decision guidance is placed at the end where it is most actionable.

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 no-param, no-output-schema introspection tool with no annotations, the description supplies the reader with what will be returned (version range, login methods, namespace, limits, config highlights) and how to act on the answer. Only minor gaps remain, such as whether the values reflect live state or a static manifest.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate at the argument level, and it correctly signals a no-input query tool.

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

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

The description states a specific verb and resource set: it reports what the plugin can do and where its boundaries lie, enumerating concrete contents (testedVersions, mineflayer version, login methods, tool namespace, sequence-step/memory/event-queue caps, current config). This is far more specific than a restatement of the name, and the 'boundary' framing distinguishes it from action-oriented siblings like mc_connect or mc_status.

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

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

It gives an explicit trigger ('before joining, when unsure whether a version can connect, check this first') and a fallback behavior ('if truly unsupported, tell Master honestly, don't force it'). It does not name a competing sibling to use instead for a related need, so it falls just short of a 5.

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

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

No annotations are provided, so the description carries the full burden and does so: it discloses that it mutates real world chests, that it is gated by mc_observe in forced mode, that `all:true` will move tools too, that `keep` protects items, that it re-reads the chest after moving, and that full inventory/chest/blocked-open are reported honestly. `dryRun` is also surfaced as a no-side-effect mode.

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

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

Front-loaded with the core identity and then a tight bulleted action breakdown, with the gating warning last. A few lines are flavor rather than information ("真·仓库", "攒家当就靠它"), and the bullets are dense, but almost every line conveys an operational rule.

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

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

For an 11-parameter mutation tool with no annotations and no output schema, the description covers the missing pieces: side effects on the world, the prerequisite gate, fallback behavior when no chest exists, the destructive edge of `all:true`, and what the tool reports back after acting. Nothing an agent needs to call it safely is absent.

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% with per-parameter descriptions, so the baseline is 3; the description goes beyond by explaining the semantics that the schema only hints at — `all:true` really means everything including tools, `keep` is a safety valve for put, and `name`+`count` interact (naming an item implies moving all of it by default). It does not spell out the `radius` bound or how x/y/z combine with `action`, which the schema covers.

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 (chest/bucket storage on the server, explicitly not item granting) and enumerates the three actions (list/put/take) with their scopes. It also distinguishes itself from mc_give ("不是作弊给物"), so an agent can tell it apart from siblings without opening the schema.

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

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

Explicitly says when to use each action (list default, put, take), when the auto-place fallback kicks in and how to disable it (`placeChest:false`), and routes to `mc_craft {name:"chest"}` when nothing is available. It also names the precondition of the mc_observe gate, which is a when-to-use condition, not just a warning.

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

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

With no annotations, the description carries the behavioral burden and does well on prerequisites: it discloses that a whitelist applies, lists the default allowed commands, and warns that commandWhitelist cannot be modified from an MC-mode session. However it says nothing about execution semantics — return format, failure behavior for non-whitelisted commands, or whether the command runs synchronously — so gaps remain for a privileged mutating 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?

Three compact sentences, front-loaded with capability then whitelist mechanics then the last-resort warning. Slightly dense with bold markers and the long inline command list, but no sentence is filler.

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

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

For a single-parameter tool with no output schema, the description covers permissions, the allowlist boundary, session-mode constraints, and alternative tools. Return values aren't described, but that is a minor omission given the tool's simplicity and the absence of an output schema.

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 schema itself specifies a leading-slash full command string, so the parameter is already documented. The description adds meaning beyond the schema by defining which command names are actually permitted and how to extend that set, which materially informs what value to pass.

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 ('execute server commands') plus resource and identity scope ('as the player'), then distinguishes itself from siblings by naming mc_act / mc_build / mc_move as the preferred path for normal actions. An agent can place this tool relative to the rest of the suite without reading any schema.

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

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

Explicitly frames itself as a last resort ('⚠️ 这是最后手段') and directs the agent to mc_act / mc_build / mc_move first, noting those don't require OP. It also tells the agent how to widen the allowlist via mc_admin_config and where that change must be made (normal session, not MC 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 does well: it discloses read vs write mode, that reads also return defaults, that patches are shallow-merged, that the config is session-scoped, and that mentionPatterns is configurable rather than hardcoded. It omits what happens to unknown keys, whether changes survive a reconnect, and any permission expectations.

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

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

Front-loads the read/write model and the no-params case, then layers examples and a practical tip. Slightly dense with two example payloads, but every sentence adds a fact an agent would otherwise have to guess.

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 2-param tool with nested free-form objects, no annotations and no output schema, the description covers the essentials: what reads return (current config + defaults), how writes are shaped, and how to reset. Persistence scope and error behavior on bad keys are the only real gaps.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning for patch: dot-notation for nested keys, a worked example object, and the semantics of mentionPatterns as a list of learned nicknames. The reset parameter is left to the schema, which is acceptable since the schema documents it.

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

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

States a specific verb pair and resource: read/write this session's MC config, and enumerates the domains it covers (watchdog wake conditions, near radius, heartbeat interval, observation window, appellations). It does not name the sibling mc_admin_config, so an agent cannot tell from the description alone how session config differs from admin config.

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

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

Explicitly says no params = read-only view, pass patch = write, and gives a concrete situational trigger ('if "any player chat wakes you" is too noisy, set wakeOn.anyChat=false'). Missing is routing against the sibling mc_admin_config, which is the one alternative an agent would plausibly confuse this with.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that the call blocks until chunk loading completes, that omitting host with no MC_HOST errors out, and that force causes a real disconnect/rejoin visible to other players. It stops short of timeouts, retry behavior, or what a successful connect returns.

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

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

Front-loaded with the key constraint (no credentials here, see mc_accounts) and then the host/env-var rule. The force guidance is the longest passage and borders on instructional over-sharing, but it is actionable and each clause maps to a real failure mode.

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 6-parameter, zero-required, no-annotation tool this covers prerequisites, defaults, failure modes, and out-of-band remediation commands. Missing only return-value/pagination behavior, which is minor since no output schema exists but the agent could benefit from knowing what a successful connect yields.

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 the baseline is 3, but the description adds non-schema semantics: host falls back to the MC_HOST environment variable, account defaults to the session-selected account, version should normally be omitted for auto-detection, and force is explicitly not a chunk-refresh tool. These are cross-parameter behaviors the schema does not state.

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 (connect to an MC server) and immediately scopes it against mc_accounts by declaring '这里没有账号密码' – account choice is delegated. An agent can distinguish this from mc_disconnect/mc_accounts/mc_sessions without opening a schema.

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

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

Gives a clear workflow: check mc_accounts first, select with action:"use" or name an innerID, and pass host/port yourself (falling back to MC_HOST). It also tells the agent when NOT to use force and what to do on login failure. It lacks only an explicit comparison to sibling tools like mc_sessions or mc_status.

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, so the description carries the full burden and does so thoroughly: auto-crafts intermediate products, auto-places the table from inventory, reports exactly what materials are missing, treats count as a total rather than an increment, resets the crafting grid before each action, and does not touch the world so it bypasses mc_observe gating. This is behavior an agent could not infer from the schema.

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

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

Purpose is front-loaded and the bullets are individually informative with no repetition. It is on the long side with heavy emoji and formatting, but nearly every line earns its place by documenting a distinct behavior.

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 11-param, no-annotation, no-output-schema mutation-ish tool this covers the critical behaviors: material shortfalls, table placement, count semantics, and grid cleanup. Return-value shape is only sketched ('结果会如实说一个都没做'), leaving minor gaps, but an agent has enough to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond it: name accepts aliases like 'planks' resolved against inventory logs, count is a total unless paired with more:true, and placeTable:false disables auto-placement. It does not add anything for x/y/z/radius/table, which the schema already covers.

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

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

States a specific verb+resource ('合成物品') and immediately distinguishes it from the cheating alternative ('真合成，走服务端的合成台，不是作弊给物'). An agent can tell it apart from mc_give without opening either schema.

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

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

Explicitly names the survival workflow it serves, tells the agent to dryRun when unsure, to use list:true to inspect recipes, to use mc_scan after repeated timeouts, and even to call mc_dig first when materials are missing. Clear when/when-not and routed alternatives.

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

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

With no annotations, the description carries the burden and does substantial work: it discloses that MCP has no mid-session prompt injection and prompts are supplied once at handshake, and it defines what perf measures (wall clock / CPU / event-loop delay per action). It does not state whether the call is read-only overall or that resetPerf mutates the sample buffer beyond the schema note, or whether the call is expensive.

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

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

Front-loaded with the verb and the state inventory, then qualifications. Dense but nearly every clause carries information. It is a single run-on with nested parentheses and could be split into purpose / trigger / perf sections for faster scanning.

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

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

No output schema exists, yet the description enumerates the returned sections (state fields, promptInjection with file location/existence/size/in-instructions flag, perf per action), which is exactly what an agent needs to decide whether to call it. For a one-optional-param diagnostic tool with no annotations, nothing material 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?

Only one optional parameter and schema coverage is 100%, so the schema already explains resetPerf. The description's reference to perf samples gives context but adds no syntax or behavioral detail beyond the schema. Baseline 3 applies 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?

States a specific verb (诊断/diagnose) and enumerates the exact resource surface: bot internal state (physics, control bits, inbound packets, event queue, synthesis window/grid), plus promptInjection status and perf monitoring. An agent knows precisely what comes back. It never names a sibling (e.g. mc_status) to sharpen the boundary, so it stops short of 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?

Gives concrete symptom-based triggers — 'can't move / not receiving messages / synthesis reports missing material' — and a separate purpose for perf (deciding whether to move an action to a Worker thread). No when-NOT-to-use guidance and no explicit alternative (mc_status / mc_capabilities) is offered, so it is clear context without exclusions.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses automatic tool switching ('会自己换成对的工具'), that results include the `held` item, a hard ~11s execution ceiling, that a partial run returns a 'time budget exhausted' message, and that dug blocks are retained in inventory so partial calls aren't wasted. Missing only failure modes (block not found, out of `maxDistance`, invalid coordinates).

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

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

Front-loads the two targeting modes, then the time-budget constraint before the re-call instruction. The repetition of the 11-second limit is deliberate emphasis on the one constraint that most affects correct invocation, and nothing else is padding.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, the description covers the essential runtime model: how targeting works, the per-call time cap, continuation semantics, tool auto-switching and the `held` result field. The remaining gap is the un-bundled x/y/z alternative and unstated error behavior, which leaves it just short of fully self-sufficient.

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

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

Schema coverage is 33% — only `count` and `maxDistance` are documented in the schema. The description meaningfully compensates for `name` (nearest match) and reinforces `count`, but `x`, `y`, and `z` have no coverage anywhere, and the description never states that the three coordinates must be supplied together as an alternative to `name`.

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

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

States a specific verb and resource (dig blocks) plus the two selection modes — by `name` for the nearest matching block, or by `pos` for an exact coordinate — and notes that `count` repeats the action. It is unmistakable what the tool does, though it never names or contrasts a sibling tool (e.g. mc_move, mc_scan) to sharpen 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?

Gives clear operating context: pick `name` for nearest-match digging or coordinates for a specific target, and use `count` with a re-call loop for bulk work. The 10–11 second per-call budget and the explicit 'just call mc_dig again to continue' instruction are strong practical guidance, but there is no statement of when NOT to use it or which sibling to prefer instead.

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

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

With no annotations, the description carries the full burden. It usefully discloses session scoping (other sessions' bots unaffected) and a watchdog side effect ('看门狗会自动关闭并提醒你'), but that clause is ambiguous about what exactly gets closed. It also omits irreversibility, whether the session record persists, and what reconnecting requires.

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

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

Three short clauses with the core action front-loaded and no filler. The final clause about the watchdog is slightly vague in wording but does add information.

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

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

For a session-terminating tool with no annotations and no output schema, the description covers the key side effect (watchdog shutdown plus notification) and blast radius. It still leaves the reason parameter and post-disconnect session state unexplained, so it is adequate rather than complete.

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

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

There is one parameter, 'reason', with 0% schema description coverage, and the description never mentions it. Under low coverage the description is expected to compensate, so the unexplained reason field is a clear gap.

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

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

States a specific verb and resource ('从 MC 下线', bot exits the game) and scopes it to the current session, which implicitly contrasts with mc_connect. It stops short of naming a sibling tool explicitly, but the action is unambiguous.

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

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

'不影响其他会话的机器人' gives a boundary condition for when this tool is safe to use instead of a broader disconnect. However, there is no explicit statement of when to choose it over alternatives (mc_stop, mc_sessions) and no preconditions or recovery guidance.

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

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

With no annotations at all, the description carries the full burden and does: it discloses the destructive-by-default consumption behavior and the peek escape hatch, FIFO ordering, the token-efficient one-line-per-event output shape, and the interruptible long-poll semantics including the interrupted:true flag and the fact that the waking content is already recorded in the queue. That is exactly the mutation/blocking context an agent needs before calling.

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

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

Front-loaded with the core verb and scope, then the two exclusions, then the waitSec caveat in priority order. Heavy bold/emoji markup and the parenthetical asides add noise, but no sentence is genuinely redundant.

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

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

For a 4-optional-param tool with no annotations and no output schema, the description supplies the return format (one line = time + type + content), the ordering, the consumption semantics, and the interrupt signal. Only small things are unstated, such as empty-queue behavior and whether the queue is shared across sessions.

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 baseline is 3; the description still adds value by framing waitSec as a last-resort option with a 10s ceiling and explaining that the returned interrupted:true means someone is pinging you and the payload is already in the queue. It reinforces peek's non-consuming meaning and the default-consumption contrast. Minor gaps remain: no guidance on choosing limit values or on what an empty queue returns.

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 (读取/消费当前会话的 MC 事件队列) and enumerates the event categories it covers (chat, system, damage, lifecycle). It also explicitly carves out what it does NOT cover (teleport, pickups, other players joining/leaving) and names mc_watch {action:"log"} as the tool for those, so an agent can separate it from its siblings without reading any schema.

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

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

Gives explicit when-to-use guidance: default is consuming, peek=true is read-only, and waitSec is described as a fallback that should not be used for long idle waits. It names the alternative (mc_watch log) and the exact condition that routes there, plus the concrete trigger that should wake the agent (mention/damage/death/disconnect).

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

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

With no annotations, the description carries the full burden and does so well: it discloses server-side async smelting, maxWaitSec default 0 (no babysitting), auto-placing the furnace (placeFurnace default true), the 8-item batch limit, and that it is gated by mc_observe. It stops short of describing return values or what happens when materials are missing beyond the furnace case, keeping it at 4 rather than 5.

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

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

Front-loaded with purpose, then scannable bullets covering fuel logic, wait behavior, and modes. It is long, but justified by a 12-parameter tool; some defaults are restated from the schema, which is the only mild waste.

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 12-parameter, no-output-schema, no-annotation mutation tool, the description covers defaults, side effects on the world, the observation gate, and failure routing to crafting. Only the precise return shape and non-material error modes are unaddressed, which is acceptable given no output schema.

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 baseline is 3, but the description adds genuine meaning: fuel auto-selection math (1 coal per 8, list to inspect), the ability to pass a product name and have raw material located automatically, and the fuel-priority rule (sticks/logs are crafting stock). This goes well beyond the schema's one-line parameter notes.

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 (server-side furnace smelting, explicitly 'not cheating to give items') and anchors it to a concrete goal ('rough iron → iron ingot → iron pickaxe'). It distinguishes itself from crafting by routing furnace-crafting to the mc_craft sibling, so an agent can tell it apart without opening schemas.

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

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

Gives explicit when-to-use, the alternative path when no furnace is nearby (mc_craft {name:"furnace'}), and per-mode guidance for takeOnly, list, and dryRun. The 'load and return, don't babysit' guidance and the batch-size recommendation remove the main decision ambiguity.

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

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

With no annotations, the description carries the full burden and does well: it discloses the protocol-level slot mechanism, that non-OP users can invoke it, and that clearAll=true wipes the inventory (a destructive side effect). It omits failure behavior, anti-cheat/server-side risk, and whether creative mode is strictly required.

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

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

Three short, front-loaded clauses: capability, examples, and the clearAll edge case. Nothing is wasted and the most important fact (protocol-level, non-OP usable) comes first.

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 4-parameter tool with full schema coverage and no output schema, the description covers mechanism, permission scope, and the destructive clearAll path. Only the return value and the creative-mode enforcement question remain unaddressed, which is a minor 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 the schema already documents name, slot, count and clearAll. The description reinforces the item-id format with examples and restates clearAll's clearing behavior, but adds no syntax or constraint meaning beyond the schema.

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

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

The description states a specific verb and resource: directly obtain items in creative mode, with concrete id examples (oak_planks / diamond_sword / white_concrete) and the mechanism named (protocol-level slot modification). It does not distinguish itself from siblings like mc_craft or mc_kit_express, 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?

It implies the operating condition (creative mode) and notes it works without OP, which is real usage context, and clearAll=true's effect is stated. However, it never says when to choose this over mc_craft (craft from materials) or mc_inventory, so routing guidance 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 at all, the description carries the full disclosure burden, and it discloses very little. '看' implies a read-only operation, but nothing confirms there are no side effects, states expected permissions, or describes the return shape for a tool whose output would be a structured inventory listing.

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, front-loaded with the verb and the three resources covered. It is appropriately sized, though it could have used the same space to add a routing hint without becoming verbose.

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

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

For a zero-param, no-output-schema read tool, the description does roughly enumerate what comes back (inventory, equipment, held items), which is the minimum needed. However, it omits whose inventory is inspected and whether the result is a snapshot versus a live view, leaving meaningful ambiguity.

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 no parameter semantics to explain; the baseline for 0 params applies. The description does not need to compensate for any schema gaps.

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

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

The single sentence names a specific verb ('看' / view) and concrete resources: backpack, equipment slots, and held items. An agent immediately understands this is an inventory inspection tool, though it never says whose inventory (the bot's own) or distinguishes itself from siblings like mc_status or mc_observe.

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 exclusions, and no reference to any alternative such as mc_status or mc_observe which likely also surface state. The agent must infer the use case entirely from the tool name and resource list.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the return is a single line whose content depends on `mc_admin_config`'s `expressBase`, and it instructs not to re-prefix links with a domain. It omits whether the file is copied/uploaded or read in place, which would matter for a sharing 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?

Front-loaded with the core action and the config-dependent return, but the `.mcp-mc-agent/.express/` constraint is repeated three times (opening line, first bullet, closing warning), which is padding without added information. Formatting is otherwise scannable.

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

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

For a single-parameter tool with no output schema, the description explains what is returned and how it varies by configuration, plus the link-handling rule. An agent can invoke it correctly. Only the file-transformation semantics (copy vs reference) remain unexplained.

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 `path` parameter is documented in-schema; the description restates the same relative/absolute and `.express/` constraint rather than adding new syntax or format detail. Baseline 3 is appropriate given 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?

States a concrete verb+resource: delivering files from the publish area `.mcp-mc-agent/.express/` to the user. The scope constraint makes the resource unambiguous. It does not explicitly differentiate from siblings like mc_kit_image, which is the only gap.

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

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

Gives explicit conditional guidance: if expressBase is unconfigured, tell the user the absolute path; if configured, embed the full URL using markdown for images vs links for other files. It also states the hard constraint that only publish-area files are shareable. No usage alternatives worth naming, but the when/how is clear.

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

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

No annotations are provided, so the description carries the behavioral burden; it does disclose the default output directory, inline image return, and the publish area path. However, it does not explain overwrite behavior, error handling, or permission/rate constraints for save or render.

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 definition front-loads the key idea that SVG is the editing language, then uses a compact action list with no obvious filler. The length is justified by five actions, output behavior, and publish routing.

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 14-parameter multi-action tool with no annotations or output schema, the description covers each action's purpose and return/publish behavior well enough for selection and invocation. It still stops short of side-effect details for save/render and formal return shapes.

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 the baseline is 3, but the description adds useful action-level constraints such as svg and svgPath being mutually exclusive and width/height/scale being render options. Most individual parameters are still left to the schema, but the added routing semantics go beyond the structured fields.

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

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

The description states a concrete image toolkit and enumerates five specific actions (info/embed/render/grid/save), with SVG rasterization and grid composition as the core model. It also distinguishes the publish retrieval path by naming mc_kit_express, so the tool's role is clear against nearby siblings.

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

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

It gives clear per-action guidance, including that embed is mandatory for referencing images inside SVG and that render takes either svg text or svgPath. It also explains the default output location and publish flow through mc_kit_express, though it does not explicitly say when not to use the tool overall.

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 disclosure burden and does well: it states that data survives sessions and restarts, that `README.md` is loaded into server instructions (an important side effect), that delete on a directory path removes the whole directory, and that read on an image returns the image itself. The remaining gap is return-format detail beyond the outline of search hits and index contents, and any locking or concurrency 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 purpose and storage layout are front-loaded, followed by a scannable bulleted action list, and then path syntax and the no-shell caveat. Almost every line carries information, although the bullets sit adjacent to the already self-documenting schema descriptions, which creates some redundancy.

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

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

For a 16-parameter, annotation-free, output-schema-free tool, the description covers routing all nine actions, the on-disk layout, the README index side effect, path/topic/server resolution, and the safety boundary. It does not describe return shapes in much detail, but the variants for index, kinds, and search are outlined 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%, so all 16 parameters are already documented, including their per-action applicability (record/append, put, search) and the required-fields rules. The description adds only the interaction rule that you supply `path` or `topic`, with `server` defaulting to the current server and `_global/` used when omitted. This is useful but largely restates what the schema already says about `topic`, `path`, and `server`.

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

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

The description opens with a concrete verb and resource combination: 长期记忆（跨会话、重启后还在）, stored under `.mcp-mc-agent/` with server-indexed subfolders. It then enumerates all nine actions with a one-line statement of what each does, for example index 看总览, delete 删文件, and search 跨文本文件搜关键词. No sibling tool deals with persistence, so an agent can identify this tool's role immediately.

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

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

The description gives strong selection guidance among the nine actions: record is marked 推荐 and mentions its per-key accumulation semantics, append is explicitly text-file-only, write is for restructuring, and put for copying workspace files. The warning that the tool 只读写文件，不执行任何东西 sets a hard boundary on what it may be used for. It does not say when memory should or should not be consulted in the agent's workflow, but the action-level routing is unusually 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?

With no annotations, the description carries the full burden and does it well: it states read-only/no-connect behavior, the exact wire protocol and multicast address, the 1.5s announcement cadence, and the bounded constant return time from `seconds`. The main gap is that it says nothing about how multiple simultaneous announcements are aggregated or ordered in the result.

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

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

Front-loaded with the purpose, then protocol detail, then failure guidance — a sensible order with little waste. The default/max of `seconds` is stated in both the prose and the schema, and the emoji/formatting adds noise, but every substantive sentence earns its place.

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

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

With no output schema and no annotations, the description still tells the agent what comes back (address, port, MOTD), how long the call takes, and what to do when it returns empty. That is everything needed to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: `seconds` is a hard ceiling on the whole call because the tool never scans, not a per-host timeout, and it repeats the default 3 / max 15. It never mentions the `mode` parameter explicitly, which is why it falls short of 5.

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

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

The description names a specific verb+resource (probe LAN Minecraft servers) and adds a hard scope boundary: it only listens for the vanilla multicast announcement, it does not scan ports or send packets. That boundary cleanly separates it from siblings like mc_scan and mc_ping, and it names mc_connect as the follow-on tool.

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

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

Explicit when-to-use (the other side used 'Open to LAN'), explicit when-not (don't expect it to work through WiFi/VPN/containers that block multicast), and an explicit alternative on failure (ask the other party for the address). It also routes the agent forward to mc_connect after a hit.

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 and largely meets it: it discloses that image format produces a top-down render that is inlined to the agent and also persisted to disk, with the default path given. It omits failure/edge behavior (unloaded chunks appear as '?' but no error semantics) and any cost/size caveats beyond token savings.

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

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

Front-loaded with the default layer and the mode list, which is good, but the middle is a dense run-on packing four glyph legends with heavy bolding and mixed punctuation, which hurts scannability. The content mostly earns its place, yet the structure could be tightened into discrete mode entries.

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 13-parameter, zero-required read tool with no output schema, the description covers the output shapes (char grid vs image vs both), defaults, and coordinate sourcing from mc_scan. Remaining gaps are minor: interaction with unloaded chunks, and no mention of how radius/scale interact with rendering cost.

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 baseline is 3, but the description adds genuine meaning beyond the schema: the per-mode glyph legends (what '#'/'v'/'~'/'?' mean in floor vs cave vs surface modes) and the slab semantics (上下各看几格) are not derivable from the schema alone. These are exactly the semantics an agent needs to read the output.

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?

Opens with a concrete verb+resource ("看周围地形" – view surrounding terrain) and immediately specifies the default layer being rendered plus the glyph legend. It is clearly distinct from siblings like mc_scan (which supplies target coordinates) and mc_observe, though the differentiation is implicit rather than stated as an explicit contrast.

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

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

Gives real selection guidance: mode choices are enumerated with the condition that selects each (auto switches to cave layer underground, column for vertical profiling), and the chars-vs-image tradeoff is spelled out ("字符图省 token 且坐标精确；形状/外观问题用图像"). No explicit when-not-to-use statement, so short of a 5.

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

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

No annotations are supplied, so the description carries full weight and does a lot: the 10-second per-call cap, the arrived:false + remaining + hint continuation contract, the auto-pillar side effect that swaps the held item, and the water pathfinding failure with its workaround. It stops short of the permission/authorization or failure modes an agent would want if a call is rejected outright, so it sits just above adequate rather than fully comprehensive.

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?

Structure is strongly front-loaded: mode definitions first, then the time-budget rule, then water and pillar caveats. It is long and the emoji/warning markers plus some restated cautions add bulk, but each block conveys distinct operational information rather than filler.

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

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

For a tool with no output schema, the description fills the gap by naming the exact return fields (arrived, remaining, hint, pillaredWith, held) and explaining what to do with them. Combined with the time-budget and water rules, an agent has everything needed to call it correctly and handle a partial result.

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 40%, so the description must compensate, and it mostly does: it defines all four mode values and their coordinate requirements (jump needs none, swim without coordinates surfaces only). budgetMs is only indirectly covered via the '10 seconds per call, never exceed 11' rule, and the x/y/z coordinate space (absolute vs relative) is never stated, leaving one real gap.

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

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

The description opens with a one-word verb ('移动') but immediately enumerates four concrete modes (walk/fly/jump/swim) with distinct behavior, so the resource and scope are clear. It separates itself from siblings by pointing to mc_dig and mc_act{mode:"break"} as the right tools for other jobs. A first-line summary above the mode list would make it 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?

Every mode carries an explicit selection condition: fly is 'most stable, default in creative', jump is for steps/getting unstuck and needs no coordinates, swim handles water and with no coordinates only surfaces for air. It also states the anti-pattern (pathfinding in water, digging water with mc_dig) and prescribes the repeated-call loop for long distances.

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, so the description carries the full burden and does so: it discloses the render semantics (players humanoid, hostile monsters red / passive yellow, dropped items black-outlined, dark purple = unloaded chunk), the conflict-resolution rule (program raycast wins over client prediction), and an explicit uncertainty section warning against treating guesses as fact. It also notes the inline delivery and the gate mode opt-in via view.json.

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

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

Front-loaded with purpose and usage, which is good, but the body is dense with emoji bolding and includes tangents — the gate-mode config file path and the mc_kit_express save workflow are peripheral to invoking this tool. The core message survives, but a fair amount of the text could be cut without loss.

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 output schema and nine optional parameters, yet the description explains what comes back (inline image plus three-part perception, with an option to suppress either via `image`/`percept`) and where files land. Combined with 100% schema coverage on the tuning knobs, an agent has enough to call it correctly; only token/size trade-offs are hinted rather than spelled out.

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 ranges and defaults already documented for fov, width, height, distance, image, percept, entities and crosshair, so the baseline is 3. The description only adds meaning for `out` (route to .express/<subdir>/ and fetch via mc_kit_express, default lands in .out/), leaving the other eight parameters entirely to the schema.

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

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

States a specific verb and resource: render a first-person screenshot from the player's eyes and return it inline with a three-part perception breakdown. It also names what the perception contains (pixel ratios, entity positions, crosshair target, held item, program raycast, nearby entities with coords/health), so the agent knows exactly what it gets back.

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

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

Explicit both ways: read-only queries (mc_status / mc_inventory / mc_scan) don't need it, but 'look once before acting' for dig/place/break/build, moving, finding things, confirming entities, or when stuck. It also gives a cadence rule (one image per action segment, re-look when the environment changes), which is unusually actionable.

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

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

There are no annotations, so the description must carry the full behavioral burden, and it does: no login, no account, no joining the server, connection closed immediately after, timeouts handled internally so the call will not hang. It also decodes the failure surface (ECONNREFUSED = nothing listening, ENOTFOUND = bad hostname, timeout = firewall or enable-status=false), which is exactly the side-effect and failure-mode disclosure a caller needs for a read-only network probe.

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?

Purpose and safety profile are front-loaded in the first two lines, then sibling routing, so nothing structurally important is buried. It is dense with emphasis markers and a parenthetical error glossary, but every line still carries information an agent would otherwise have to guess.

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?

Four optional parameters, no output schema, and no annotations, yet the description enumerates the returned fields (reachability, version, protocol, MOTD, players, latency) and maps the common error codes to plain-language causes. An agent can decide whether to call it, how it will behave, and how to interpret the result without further context.

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 every parameter (port, address, subserver, timeoutMs) is already documented with defaults, accepted formats and clamping ranges in the schema. The description adds no parameter-level detail beyond referring to a known address, 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?

States a specific verb and resource: it sends exactly one Minecraft STATUS ping against a single known address and returns reachability/version/protocol/MOTD/player count/latency. It explicitly distinguishes itself from mc_connect (joins the server) and mc_lan (discovers unknown addresses). It does not, however, say anything about the sibling mc_status, which an agent could easily confuse with a status ping, so the differentiation is clear but not complete.

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

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

Gives an explicit when-to-use ("已知地址时"), an ordering recommendation ("先用 mc_ping 确认地址与版本（推荐）再 mc_connect 进服"), and an alternative for the opposite case ("不知道地址时用 mc_lan"). The agent knows both when this tool is right and which sibling to reach for when it is not.

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, so the description carries the full load. It does disclose the key side effect that every player on the server sees the message, which is the most important behavioral fact for a broadcast tool. It says nothing about rate limits, cooldowns, or what happens on failure/disconnect, and truncation is only covered by the schema.

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

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

A single front-loaded sentence with the audience constraint attached inline. No filler and nothing buried.

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

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

For a one-parameter tool with no output schema, the description covers purpose and audience but omits operational context such as cooldowns, failure modes, or what a successful send returns. Adequate to call correctly, not complete.

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

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

Schema coverage is 100% and the single parameter already documents that it must be one line and is truncated to 220 characters. The description adds no format, encoding, or content restrictions beyond the schema, 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 specific action (speak) on a specific surface (MC public chat) and clarifies the audience (all players in game can see it). That scope distinguishes it from command-like siblings such as mc_command, 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?

There is no when-to-use or when-not-to-use guidance and no alternative named. The parenthetical about all players seeing the message hints that this is a broadcast, but the agent must infer on its own that private/command channels live elsewhere.

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 behavioral burden. 'Scan' implies a read-only, non-destructive operation, but the description never states that explicitly, nor mentions cost/performance tied to radius and height limits.

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

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

Two compact clauses, mode-switching condition front-loaded, zero filler. Every phrase carries information.

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

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

For a 4-parameter, no-annotation, no-output-schema read tool, the description plus full schema coverage is close to sufficient. The gap is that it doesn't explicitly confirm the operation is safe/read-only, which an agent must currently infer from the verb.

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 the baseline is 3; the description earns extra by documenting cross-parameter semantics the schema does not — that presence of 'name' switches the tool into a positions-lookup mode and changes what 'limit' means. The remaining defaults and caps are already in the schema.

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

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

States a concrete verb and resource ('扫描我周围方块') and distinguishes two output shapes: block positions when a name is given, block statistics otherwise. It doesn't name the nearest sibling (mc_observe / mc_dig), so differentiation from those tools is left to inference.

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 conditional clause ('给 name 就…不给就…') gives clear in-tool mode selection, which is real usage guidance. However it never says when to pick this over mc_observe or mc_dig, and gives no prerequisites such as being connected or in-world.

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

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

With no annotations, the description carries the full burden and does so: it discloses the 10-second run cap, the error short-circuit default, and exactly what the response contains on a timeout (stoppedAt, remaining, hint). It also explains the resumption protocol (re-call with steps from stoppedAt onward), which is behavior an agent could not infer from the schema.

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

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

Front-loaded with purpose, then ops, then the time-budget caveat and resume instruction. Dense but each section earns its place; the op enumeration is long yet necessary given the opaque item schema. Minor redundancy between the '10 seconds' prose and the budgetMs default/limit.

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?

There is no output schema, and the description still documents the return shape on the failure path (stoppedAt, remaining, hint) plus the recovery loop. Combined with the op list, budget behavior, and error policy, an agent has everything needed to call this correctly on the first attempt.

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 three top-level params, so the baseline would be 3. However, the `steps` items are untyped objects (additionalProperties: true), and the description supplies the entire op vocabulary with argument signatures — meaning the schema alone would leave the tool unusable. That is genuine added meaning beyond the schema, not repetition.

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

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

The description states a specific verb and resource: execute a sequence of world interactions ('按顺序执行一串世界交互'), and positions itself as a replacement for writing a script. The enumerated op list (wait/move/look/place/break...) makes the scope concrete and distinguishes it from the single-action siblings such as mc_move, mc_dig, and mc_say.

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

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

It gives a clear use case ('走到这里放几个方块，再走到那里放几个') and an explicit operational guideline: split into 3-4 step batches rather than one long chain. It stops short of naming which sibling to call instead when only a single action is needed, so the exclusion boundary is implied rather than 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 provided, so the description bears the full burden. The listing/diagnostic framing implies a harmless read, and it names the fields an agent can check, but it does not state ordering, whether inactive sessions are excluded, or the response shape for a tool with no output schema.

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

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

A single front-loaded sentence with the action first and the diagnostic intent in a tight parenthetical; no filler and nothing buried.

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

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

With no annotations and no output schema, the description still conveys the resource, that it is a read listing, and what information it returns (bot status, connection info). Only the multi-session aggregation behavior and return ordering remain unspecified, a minor gap for such a simple tool.

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

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

The tool takes zero parameters, which is the baseline 4 case; the schema is trivially complete and the description adds nothing that conflicts with it.

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

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

States a specific verb and resource: list all currently active MC session instances, with a parenthetical naming the diagnostic payload (bot status, connection info). An agent can tell it apart from most siblings, though the boundary with mc_status and mc_diag is never made explicit.

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

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

The phrase '诊断用' implies a diagnostic context, which is a hint about when to reach for it, but there is no explicit 'use when X, use mc_status/mc_diag instead for Y' guidance despite several close siblings.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does disclose the default behavior (summary) versus verbose behavior (full detail, 5 chats, connection info) and implies this is a passive state read with no side effects. However, it says nothing about failure behavior when no session is connected or the account is offline, and never explicitly confirms read-only/no-mutation semantics — meaningful gaps 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?

Two sentences, front-loaded with the field list so the agent knows the payload before the optional branch. Every clause earns its place: the field enumeration and the verbose contrast both carry information. Slightly dense field-list formatting but no filler.

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

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

With no output schema and no annotations, the description compensates well by enumerating the returned fields and the summary/verbose split. Still missing: what is returned or raised when there is no live session, and any hint of how this differs from mc_observe/mc_diag. Those omissions keep it from a 5 for a zero-annotation, zero-output-schema tool.

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

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

There is only one optional parameter and schema coverage is 100%, so the baseline is 3. The description earns above that by explaining what verbose actually changes — connection info, all watchdog switches, and 5 chat entries instead of a summary with the last 3 chats — which is more concrete than the schema's generic 'complete detail'. Enumeration of the default payload versus the verbose payload is real added meaning.

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 (view my Minecraft status) and then enumerates exactly the fields returned: online status, coordinates, facing, health, hunger, held item, mode, watchdog presence, and recent chat lines. That makes the tool's scope concrete and distinguishable from write/action siblings like mc_move or mc_give. It does not, however, distinguish itself from read-oriented siblings such as mc_observe or mc_diag, so it stops 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?

The description implies usage (quick glance by default, full detail via verbose:true) and implicitly draws the verbose boundary — 3 chats and summary fields vs. connection info, all watchdog switches, and 5 chat lines. But it never says when to prefer this over mc_observe, mc_diag, or mc_sessions, and there is no exclusion guidance. Usage is inferable rather than 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 provided, so the description carries the full burden, and it does: it discloses the graceful-then-forceful shutdown sequence, what gets destroyed (all session background tasks, watchdog), and the key side-effect boundary (does not abort the caller's own turn; server cannot stop the client turn; no force-stop exists). That is exactly the behavioural context an agent needs before invoking a destructive session-level operation.

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

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

The core action is front-loaded in the first sentence, with warnings after it in priority order. It is somewhat verbose and uses a parenthetical aside about stoppedLLM that adds little, but nearly every sentence carries a distinct behavioural fact.

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

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

For a one-parameter, no-output-schema, no-annotation tool, the description covers what it does, when to use it, what it destroys and what it cannot do. It does not state failure behaviour (e.g. what happens if the game does not quit gracefully) or confirm whether the session remains usable afterwards, which is a minor remaining gap.

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

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

One optional parameter (reason) with 100% schema description coverage, so the schema already explains its meaning ('reason, written to log'). The description adds nothing about the parameter, and the baseline 3 applies when the schema does all 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?

Specific verb+resource (stop this session's Minecraft) plus a concrete two-phase behavior: graceful game quit, then clearing all session background tasks including the watchdog. It never references the sibling mc_disconnect, which is the most obvious semantic neighbour, so an agent cannot fully disambiguate from the text alone.

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

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

Gives an explicit use case ("I don't want to play anymore, log off") and an explicit non-use case with the alternative action ("to stop your own running action, just don't call tools"). It also states there is no force-stop path, which closes off a tempting misuse. Missing only a comparison against mc_disconnect/mc_task for the overlapping 'tear down state' scenario.

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

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

With no annotations, the description carries the full burden. It does disclose genuinely useful behavior: persistence to tasks.json and survival across reconnect, plus that run advances one step per round. It omits critical traits — notably that steps contain `op`/`args` tool invocations, so run appears to execute other tools; there is no disclosure of failure handling, the meaning of force, or whether any step is destructive.

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

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

Two compact sentences, front-loaded with what the resource is and where it lives, then the action glosses. No filler. The telegraphic style borders on under-specification for a 9-parameter, 11-action tool, but the ordering and density are good.

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

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

For a tool with 9 parameters, 11 distinct actions, no annotations, and no output schema, the description covers only 4 actions and never explains what a run actually does or what a task record looks like. An agent could not reliably pick done vs cancel vs forget, or predict run's side effects, from this text alone.

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 the baseline is 3, but the description adds real meaning the schema does not: run advances one step per round, resume re-verifies, plan/step do bookkeeping. That clarifies enum values a schema alone leaves as bare strings. It still leaves list/get/note/done/cancel/forget and the force/limit interactions 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?

States a concrete verb+resource pair: a persistent progress ledger for long tasks, with storage location (tasks.json under the memory root) and lifetime (survives disconnect/reconnect). It also names four of the actions (run/resume/plan/step). It does not differentiate itself from nearby siblings such as mc_sequence or mc_auto, which an agent could plausibly confuse with task orchestration.

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