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

Goes well beyond the destructiveHint/idempotentHint annotations: it discloses required permissions, the online-player precondition with the exact error code, overflow behavior (player drops at feet, block items are lost and tallied in `dropped`), and the irreversibility of cleared/taken items. That is precisely the mutation-risk context an agent needs before calling a destructive tool.

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

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

Dense but front-loaded: target and permissions first, then per-action semantics, then slot reference data last. Every clause carries information; there is no filler or repetition of the schema.

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

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

For a destructive, nested-object, 7-parameter tool with no output schema, the description covers targets, permissions, per-action effects, and return hints (`dropped`, 'says what it took'). The preconditions for `set`/`give` combinations and what happens when a block target isn't a container are only implied, leaving minor 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 already 86%, yet the description still adds substantial meaning: it maps every slot index (0–8 hotbar, 36–39 armor, 40 offhand, ender chest 0–26, container 0–53 left-half-first) and clarifies `amount` semantics for take ('the whole stack when left out'). It also ties parameters to actions, which the schema does not do.

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-plus-resource: change what a player's inventory/ender chest or a container block holds. It immediately enumerates the five supported actions (give, set, take, clear_slot, clear), so an agent can distinguish this item-mutation tool from siblings like set_blocks or run_command.

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's effect is spelled out ('give adds an item where it fits', 'set puts an item in a slot, replacing what was there', 'clear empties everything, armor and offhand included'), which tells an agent exactly which action to pick. Preconditions (players:write / world:write, player must be online else `player_offline`) are explicit. It stops short of naming a sibling alternative for cases this tool can't cover.

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?

Beyond the readOnly/idempotent annotations it discloses real behavior: double chests count once, containers list their five most plentiful items, chunk-loading scope, the players:private permission requirement, and a prompt-injection warning that item names are player-written data. That last point is exactly the kind of non-structural risk an agent cannot infer from 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?

Four short sentences, front-loaded with what is returned and in what order, then filtering semantics, then access and safety. No sentence is filler despite the density.

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, the description still tells the agent what a result entry contains (container type, count of matching items, top five items) and what access is required. Eight parameters are adequately handled by the combination of description and 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 63%, so the description usefully adds meaning to `items` (filter to containers holding any listed item, and report counts) and to the radius/proximity semantics via 'around a point, nearest first'. World and cursor are only covered by the schema, and the description never mentions pagination.

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

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

States a concrete verb and resource ('Chests, barrels, shulker boxes... in loaded chunks around a point') plus ordering ('nearest first'). It also explicitly separates itself from the sibling get_block, which is the other tool that touches blocks.

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 routing rule to get_block for reading a single container in full, and implies search-then-inspect usage. It stops short of naming when not to use it (e.g., unloaded chunks require force_load_chunk first), but the operational context 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?

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, and the description's 'keep loaded … or release it' is consistent with an idempotent set-state operation, so no contradiction. It adds the useful behavioral nuance that loading persists without nearby players, but says nothing about how long force-loading survives (e.g., server restart), whether tickets accumulate, or what permissions are 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?

A single short sentence with no filler and the core capability front-loaded. Its brevity is efficient, though 'or release it' is slightly oblique when a direct statement of the toggle would be clearer.

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?

Treated as a state-mutation tool with a 4-parameter schema at 25% coverage and no output schema, the definition is thin: it omits coordinate units, the world default behavior, and any indication of what the call returns or how the agent verifies the new state. 'Even with nobody near' partially restores that, but the missing parameter guidance is the real gap for a required-three-argument call.

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% — only 'world' is documented — while chunkX, chunkZ and forceLoaded carry no schema descriptions at all. The description's 'or release it' loosely implies the binary forceLoaded flag, but it never clarifies that coordinates are chunk coordinates rather than block coordinates, which is the most likely invocation error.

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 conveys the resource (a chunk) and the state change (keep it loaded, or release it), which is a meaningful distinction from read-only siblings like list_chunks or get_block. It never names an explicit verb such as 'force-load' or 'set force-load state', and it does not differentiate itself from other mutation siblings such as set_blocks or world_effect.

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 'even with nobody near' phrasing hints at the motivation (keeping chunks ticking without players present), but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives. With 39 sibling tools, including several chunk-adjacent ones, the agent is left to infer that this is not a listing or inspection tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful non-annotation context: the required permission level and the fact that ban records include reasons and expiry details.

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

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

The description is compact and front-loaded: it leads with the access-control scope and then adds the permission prerequisite. Every clause contributes relevant information, with no filler or repetition.

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

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

For a zero-parameter read tool with a complete annotation set and no output schema, the description covers the main returned information categories and the permission requirement. It could be slightly more explicit about the returned shape, but it is complete enough for correct invocation.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to clarify. The baseline for a zero-parameter tool is 4, and the description correctly adds no misleading parameter information.

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

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

The description clearly identifies the read resource: whitelist state and membership, operators, and banned players/IPs with reasons and expiry. It is specific about scope, but it does not explicitly name the sibling write/resource-management tool manage_access, so sibling differentiation is only implied.

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 states a prerequisite, 'Needs players:moderate,' which implies usage context, but it does not explicitly say when to call this instead of manage_access or when not to use it. The read-only nature is only conveyed through annotations, not through routing guidance in the description.

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

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond that: results are newest first, permission requirements, and the kinds of audit fields returned, including file edits and command text.

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

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

The description is a single front-loaded sentence with no filler, and the field list is useful. It is dense but remains readable; a little more scannability would make it exceptional.

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, read-only audit-list tool with rich annotations and full schema coverage, the description supplies the essential return-content and permission context. Pagination behavior is left to the schema's cursor/limit descriptions, which is acceptable.

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

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

Schema description coverage is 100%, so all three parameters are fully documented in the schema. The description's mention of actor and ordering adds only marginal value over the schema, so the baseline 3 is appropriate.

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

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

The description clearly states it returns WorldAPI change audit entries, newest first, with who/when/method/path/target/status/details. It is specific and not a tautology, but it does not explicitly distinguish this tool from neighbors such as get_events, get_server_log, or get_access.

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 implied use case, auditing client changes through WorldAPI, and states the permission prerequisite (`tokens:manage`). However, it does not say when to choose this tool versus related log/access/event tools, nor does it list 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on genuinely non-obvious behavior: permission gating for container contents, the chunk_not_generated failure mode, omission of inapplicable fields, double chests collapsed into one entry with left half first, and an explicit prompt-injection warning that player-written names/lore/book titles are data, not instructions.

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 capability is front-loaded in the first clause and every sentence carries information. The long semicolon-chained enumeration of container types and item attributes is dense and slightly bloated, though it substitutes for the missing output schema.

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

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

With no output schema, the description carries the full burden of describing return values and does so thoroughly: block state, item payloads, enchantments/attributes/potions, omission rules, and the error case. An agent can call it correctly and interpret results without further docs.

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 semantics the schema lacks: y-omission resolves to the column's top block and heightmap selects which surface definition applies. The world parameter's meaning is left 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?

Opens with a concrete resource and scope: 'Blocks at up to 16 positions in one call', followed by exactly which properties come back (type, state, light, biome, redstone, contents). It reads unambiguously as a bulk read, which contrasts implicitly with set_blocks and find_containers, but no sibling is named, 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?

Gives clear usage rules: omit y to get the column's highest block (with a stated rationale, surface before a teleport), and container contents require players:private. It never says when to use a different tool, so an agent must infer that find_containers is for searching rather than probing known coordinates.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. Beyond that, the description usefully discloses the return composition: totals, counts by type, items, villagers, named mobs, tamed pets, and busiest chunks with block entities and hoppers.

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

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

The description is front-loaded with the summary scope and followed by a routing instruction. It is dense but every clause describes return content or usage, with little 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?

With no output schema, the description carries the burden of explaining what the summary contains, and it does so in detail. It is nearly complete for a read-only summary tool, though it could say more about the types parameter and coordinate/radius interaction.

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 50%, and the description clarifies the radius mode by saying 'within radius of x, y, z' and the loaded/world scope. However, it does not explain the types filter or the world parameter naming, so it only partially compensates for schema gaps.

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

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

The description states a specific resource and scope: a compact entity summary for a world, either loaded entities or entities within a radius. It distinguishes the tool from list_entities by contrasting summary counts with one-by-one entity listing.

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

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

It explicitly recommends calling this before list_entities, giving a clear sequencing rule and alternative. It does not spell out when not to use it or that radius requires x, y, and z together, which keeps it from 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?

Annotations already cover the read-only, idempotent, non-destructive profile, so the description's added value is the default ordering, the permission dependency for chat events (chat:read plus the server's events.chat), and the prompt-injection warning that chat content is untrusted data. It stops short of describing pagination behavior or response shape beyond what the cursor parameter implies.

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 default ordering, then the filters and the security caveat — a sensible order. The long event-type enumeration is useful but makes the first sentence dense; it still earns its place by telling the agent valid `types` values.

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 7 optional parameters and no output schema, the description supplies the missing pieces an agent needs: default ordering, permission gating for chat, the plugin-type discovery path, and a data-vs-instructions warning. Only the response/pagination shape (beyond the cursor parameter) is left implicit.

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 86%, so the baseline is 3; the description adds real meaning by establishing 'newest first' as the default order and by explaining that types may include plugin-defined `ext.<namespace>.<event>` values discovered via list_extensions. The time and player filters are only restated at a high level, which keeps it at 4 rather than 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?

States a specific resource (recorded events) with its default ordering ('newest first') and enumerates the concrete event types available, so an agent knows exactly what it is retrieving. It does not explicitly differentiate itself from close siblings like get_audit_log, get_server_log, or wait_for_event, which keeps it from 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?

'Filter by type, player, and time' implies the query use case, and the chat caveat names the conditions needed for chat events. However, there is no explicit guidance on when to choose this over get_audit_log or get_server_log, nor on when to use wait_for_event instead of polling.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes further with real behavioral caveats: ties share a place, experience and tamed counts are lower bounds because vanilla keeps no lifetime total, and the max of 5 boards. It stops short of saying how expensive the scan is or how ties are ordered within a place.

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 behavior, and nearly every clause carries new information (units, presets, syntax, defaults). The final sentence is a dense run-on listing aggregate fields, which costs it a point on readability, but there is no filler.

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

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

With no output schema, the description must imply the return shape; it does so partially by describing ranked entries with shared places and a totals mode with named aggregate fields. It never states the overall structure (e.g. how multiple boards are keyed in the response), which is the remaining gap for a 2-param aggregation tool.

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

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

Schema coverage is 100% so the baseline is 3, but the description substantially exceeds it: it enumerates every preset with its unit (playtime in hours, travel in km, damage in hearts, netherite as ancient debris) and defines the free-form `category:key` syntax with examples like `custom:jump` and `killed:*`, plus wildcard support. That is meaning the schema's one-line example does not convey.

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

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

Opens with a specific verb+resource+scope: 'Players ranked by statistics, up to 5 boards at once.' It is instantly distinguishable from the player-inspection siblings (get_player, list_players) because it declares ranking/aggregation as its output.

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 second half establishes an explicit branch: pass `statistics` for boards, or omit it to get presets-with-units plus server-wide totals. That is clear usage context, but it never names an alternative tool or states when a sibling would be preferred over this one.

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

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

Annotations already declare read-only, idempotent, non-destructive, but the description adds genuinely new behavioral facts: offline players return stale last-known location, offline inventories come from the saved player file, several parts require the players:private permission, and permission checks answer whether the player is an operator. It even flags that item names, lore, and book titles are player-written data rather than instructions, a prompt-injection caveat nothing in the structured fields conveys.

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?

Long, but almost every clause maps to a distinct behavioral fact, and the highest-value information (what is returned, offline vs online, permission gate) is front-loaded. It is one dense paragraph with heavy nested parentheses, so scanning for a specific `include` value is harder than it needs to be; light structure would have earned a 5.

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, so the description carries the full return-value burden, and it does: it describes item payloads (enchantments, attributes with tooltip adjustment, potion durations in ticks, armor trim, shulker/bundle contents) and notes that inapplicable fields are omitted. For a six-parameter read tool with permission-gated sections, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is already 83%, so a 3 would be the floor, but the description goes well beyond it: each `include` value is explained with its return shape and online/offline constraint, `statistics` categories are spelled out with units (play_time in ticks, distances in centimeters), and `permission` is illustrated with a concrete node such as worldedit.wand. The inventory slot map (0–8 hotbar, 36–39 armor, 40 offhand) and ender chest 0–26 add interpretation the schema lacks.

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 (a player's profile and, while online, full state) and then enumerates the exact state fields returned: game mode, health, food, XP, location, flight, speed, ping, client. It also distinguishes the single-player case from the batch case via `players` (up to 10) and from optional payloads via `include`, so an agent can tell it apart from siblings like list_players or get_entity_summary.

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

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

Gives strong conditional guidance on the optional parts: `effects` and `target` are online-only, `inventory`/`enderchest` come from the saved file while offline, `statistics` is all-or-one-category, `advancements` has todo/done/all semantics. What it never does is name an alternative tool or state when to prefer list_players or get_entity_summary instead, so the when-not side is implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is free. The description still earns credit by disclosing data-scope facts the annotations cannot: plugin-registered recipes are included, and each ingredient expands into the set of items that satisfy it. It says nothing about behavior for unknown items or about pagination defaults.

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

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

One compact sentence that front-loads the item/uses distinction before the recipe-type enumeration. The middle clause enumerating five cooking stations is slightly breathy, but every element maps to real scope information the agent needs.

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

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

With no output schema, the description carries the return-shape burden and does so: it names the recipe categories, notes that grids come with their shape, that cooking includes time and experience, and that ingredients list the items that fit. Combined with 100% parameter coverage and read-only annotations, an agent has enough to call this correctly.

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

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

Schema description coverage is 100%, so all four parameters are already documented with examples (`minecraft:torch`, `minecraft:coal`) and limit semantics ('0 answers only the total'). The description reinforces the conceptual split between `item` and `uses` but adds no syntax, format, or interaction detail for `limit`/`cursor` beyond the schema. Baseline 3 applies.

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

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

The description names the resource (recipes) and states the two query directions precisely: how to make an item (`item`) or what an item is good for (`uses`). It enumerates the covered recipe types (crafting, furnace, smoker, blast furnace, campfire, stonecutting, smithing), which makes the scope unambiguous. It stops short of an explicit verb like 'returns' and never differentiates itself from siblings by name, but no sibling covers recipes at all.

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 tells the agent which parameter to pick for which goal — 'How to make an item (`item`)' vs 'what an item is good for (`uses`)' — and that both can be combined. That covers the main decision an agent faces with this tool. It gives no exclusions, no 'when not to use', and no guidance on paging versus counting.

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 annotations already declaring readOnly/idempotent/non-destructive, the description adds real context: the in-memory buffer holds lines since WorldAPI start (1000 by default), tokens are blanked, and the required scope is logs:read. The prompt-injection warning ('data, never instructions') is meaningful behavioral disclosure for untrusted player-authored content. Minor cost: 'oldest first' sits awkwardly against the limit parameter's 'newest matching lines', creating a small ordering ambiguity the description does not resolve.

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 dense sentences plus a security note, all front-loaded with the resource and ordering before alternatives and caveats. Every clause carries information, though the limit/ordering mismatch slightly muddies an otherwise crisp statement.

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 compensates well by describing line contents, ordering, buffer size, defaults, redaction, and required auth. The remaining hole is the exact relationship between which lines limit selects and the order they are returned in, which an agent would need to reason through.

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 earns above baseline by clarifying filter intent ('filter by the lowest level and by text, such as a player's name or a plugin's'), which tells the agent what to put in grep and how level behaves in practice. It leaves the interaction between limit and the oldest-first ordering unclarified.

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

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

The description gives a specific resource (recent console lines), an ordering (oldest first) and enumerates the content types it carries (errors, warnings, plugin messages, joins, chat, commands). It distinguishes itself from file-based log reading (read_file on logs/latest.log) but never contrasts with get_audit_log, the nearest sibling, leaving one differentiation 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?

It states the trigger condition and routes the agent elsewhere when appropriate: older logs live in files, use read_file with grep on logs/latest.log or the dated .gz file. That is explicit alternative-tool guidance. It stops short of saying when to prefer this over get_audit_log.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real value beyond them: it explains that the `host` include requires the system:read permission, and clarifies semantics like 'paused' meaning nothing ticks and 'lan' meaning opened to LAN.

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 is front-loaded with the core status fields, but the description is a dense, comma-spliced run-on that spends most of its length on an exhaustive field inventory. It is informative yet verbose, with lists of metrics an agent may not need up front.

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, the description carries the burden of describing return values and does so thoroughly, covering default fields, conditional `include` behavior, and permission requirements. It is complete enough to call correctly, though it omits guidance on when to prefer it over related status/log tools.

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

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

Although schema coverage is 100% and only one optional param exists, the description expands on what each enum value actually pulls in: `performance` adds tick percentiles, CPU, per-world chunk/entity stats and JVM internals; `host` adds OS, CPUs, RAM, disk and container limits. That is meaningfully more than the schema's terse 'Parts to add'.

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

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

The description clearly conveys that this tool returns a server status snapshot, enumerating the exact fields (version, TPS, memory, chunks, entities, platform/side). It is specific about the resource, though the action verb is only implied and it never distinguishes itself from overlapping siblings like get_world or get_server_log.

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

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

Usage is implied by the content: an agent can infer it should call this when it wants an overview of server health. But there is no explicit when-to-use / when-not-to-use guidance, and no routing to alternatives such as get_events or get_server_log for logs, or which sibling to prefer for world-specific data.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety burden is light; the description still adds real context by decoding dayTime values (0 sunrise, 6000 noon, 13000 night, 18000 midnight) and spelling out what each include section contains. It omits what happens on an unknown world name or whether listing is filtered by permission, which keeps it below a 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?

It is dense but well ordered: default single-world fields first, then the no-argument list mode, then the opt-in include extras. The long field enumeration is justified because no output schema exists, though the single-sentence colon chain is heavy to parse.

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

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

With no output schema, the description carries the return-shape burden and does so in detail, including the shape divergence between single-world and all-worlds calls. It lacks any note on failure modes (unknown world) or how much is returned for very large include sets, which is the only real remaining gap for a 2-parameter read tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning beyond the schema: it explains the dayTime encoding for the returned field and expands each bare enum value ('rules', 'size', 'respawn') into a concrete list of sub-fields such as spawnProtection, respawnRadius, and explored area in km². Only the 'size' units and the world-key format are left where the schema already had them.

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 makes clear this is a read of world state and enumerates exactly what is returned (time of day, weather, difficulty, border, gamerules), plus the two modes: single world vs 'every loaded world with its dimension key and player count'. It does not name the counterpart mutation tool set_world/save_worlds to sharpen the distinction, but the resource and scope are 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?

'Without world, every loaded world with its dimension key and player count' implies the list vs detail choice, so parameter-driven usage is inferable. However, there is no explicit when-to-use/when-not guidance relative to siblings such as set_world or get_server_status, and no stated prerequisites or error behavior when a world name is invalid.

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

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

Annotations already cover read-only, idempotent, non-destructive, so the bar is lower, yet the description still adds real behavioral context: what the listing contains (entity/tile-entity counts) and what the detail mode returns (entities by type, player dwell time, slime chunk, force-loaded status). It does not discuss pagination behavior for `cursor`/`limit`, which is the only remaining gap.

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

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

Short, front-loaded with the listing behavior, then the sort guidance, then the detail mode, then a coordinate primer. The phrasing is telegraphic ("With chunk, that one chunk in detail:") but nothing is redundant, so it reads as terse rather than wasteful.

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 five optional parameters including a nested `chunk` object and no output schema, the description carries a heavier burden, and it does describe returned content for both modes plus the coordinate convention. It is nearly complete, though it never explains how `cursor` paging plus `limit` interact in practice.

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 meaning the schema does not: it explains what each `sort` mode prioritizes and defines chunk coordinates as block coordinates divided by 16 and floored. That is real semantic value above the enum documentation.

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

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

The description states a concrete resource (loaded chunks) and the payload it carries (entity and block entity counts), plus a second mode that returns one chunk in detail via the `chunk` parameter. It does not name or contrast any sibling (e.g. list_entities, get_block), so it is clear but not differentiated.

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 genuine when-to-use cue: sorting by `entities`/`tileEntities` surfaces the busiest chunks, "which is where lag usually sits," and tells the agent to switch to the `chunk` parameter for single-chunk investigation. There are no explicit exclusions or named alternatives, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive), so the description earns credit for what they cannot say: only loaded chunks are visible, 25 results per page, fields that don't apply are omitted rather than null, and item/lore/book-title strings are player-written data rather than instructions. That last point is an unusual and genuinely useful safety disclosure.

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?

Core scope and the sibling routing are front-loaded in the first two sentences. The tail enumeration of item fields (attributes, trims, firework flight, shulker contents) is a long run-on, but with no output schema most of those clauses carry real informational load, so the length is defensible rather than wasteful.

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, the description must describe returns, and it does: entity detail fields (position, health, equipment, effects, owner, tags, spawn reason, villager trades) and item-level fields, plus the note that inapplicable fields are omitted. An agent can predict the response shape well enough to plan a call.

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 73%, and the description still adds meaning the schema lacks: radius results are ordered nearest-first, pagination is 25 per page, uuid suppresses the other filters, and limit=0 returns only a total. The bare x/y/z coordinates and cursor mechanics are left to the schema, which is acceptable at this coverage level but keeps it off a 5.

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

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

The first sentence states a specific verb (lists), resource (loaded entities in a world), page size, and the four filter axes, which is enough for an agent to distinguish it from get_entity_summary, get_player, or locate without opening any schema. The uuid sentence further delineates a second mode (single-entity detail) rather than leaving ambiguity.

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

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

The description explicitly routes to a sibling ('For a crowded world, get_entity_summary first') and gives the selection condition, and it explains the special-case usage of limit=0 as a count-only call and uuid as an override of the other filters. When-to-use, when-to-use-something-else, and the shortcut semantics are all present.

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

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the safety profile is handled. The description adds genuinely useful context the annotations cannot: the result set is server-dependent ('what's here depends on the server'), which tells the agent not to cache or assume a fixed list. It doesn't describe pagination or empty-result behavior, but for a zero-arg discovery call that is minor.

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, no filler, with the actionable directive ('call this first instead of guessing') placed last as a clear closing instruction. The first sentence is dense with parentheticals that could be split, but each clause carries information about what comes back and who consumes it.

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, so the description carries the burden of explaining return values, and it does: namespaces, resource paths, and event topic strings with their format and consumers. Combined with the 'depends on the server' caveat and the call-first advice, an agent has everything needed to invoke it correctly.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description instead spends its words on the output shape, which is the right allocation here.

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

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

The description states the resource precisely: a catalog of other plugins that expose data via WorldAPI, returning each namespace, its readable resource paths, and its event topics. It implicitly separates this from list_plugins by scoping to plugins that 'share their own data through WorldAPI', though it never names list_plugins outright to make the distinction 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?

'Call this first instead of guessing' is an explicit call-ordering instruction that routes the agent here before attempting read_extension or get_events. It also tells the agent what to do with the results (use paths with read_extension, topic strings with get_events/wait_for_event). It stops short of stating when not to use it or why list_plugins would be preferred in some cases.

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

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

The description adds substantial behavior beyond the annotations: ordering, returned fields, path conventions, permission requirements, exclusions for hidden files and sensitive artifacts, and special handling for logs and configs. These details are exactly what an agent needs to call the tool correctly despite having 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?

The description is dense but mostly front-loaded and each sentence adds operational information. The final sentence about configs is somewhat run-on and the opening phrase is awkward, but the overall size is reasonable for a tool with several special cases.

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, the description carries the burden of explaining return contents, ordering, permissions, excluded paths, and the logs/configs modes, and it does so thoroughly. An agent has enough information to understand what this tool will and will not expose.

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 schema documents both parameters, but the description still adds useful semantics: path examples and forward-slash/relative-path rules, plus a fuller explanation of what `configs: true` returns and which permission it needs.

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

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

The description clearly identifies the resource as a server folder and specifies the returned information: names, folders-first ordering, sizes, modification times, and whether read_file/edit_file accept each entry. It also covers special modes for logs and configs, though it opens with the fragment 'A folder of the server' rather than an explicit verb and does not fully route among all sibling tools.

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

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

It gives implied usage context by explaining when `configs` is used and how `logs` is listed, plus the permissions needed for logs versus other files. However, it does not explicitly say when to use this tool instead of siblings such as read_file, get_server_log, or list_plugins.

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

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

Annotations already cover read-only/idempotent/non-destructive safety, so the description's job is to add behavioral context — and it does, disclosing that online=true switches to a live-state view returning world, game mode, health, food, level, ping, idle time and location. It doesn't state whether the roster is paginated or how far back 'has played' reaches, which would have made it a 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?

Two dense sentences with no filler, front-loaded with the resource scope and followed by the field list and mode flags. The second clause is somewhat run-on, stacking two distinct behaviors into one sentence, but nothing is wasted.

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

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

With no output schema and no annotations about return shape, the description correctly spends its words enumerating the returned fields for both the default and online views, which is the main thing an agent needs. It omits default sort order and pagination behavior, but those are covered by the schema's cursor parameter.

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?

Against 75% schema coverage, the description still earns credit by explaining the non-obvious semantics of limit=0 (count-only) and online=true (switches the entire result shape), which go beyond the schema's terse hints. The sort enum values and cursor mechanics are left entirely to the schema, keeping it out of 5 territory.

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

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

The description names the resource precisely ('Everyone who has played here') and enumerates the core fields (online state, first/last seen, playtime), which is more specific than the bare name. It implicitly separates itself from the singular get_player by scoping to 'everyone', but never names a sibling explicitly, so it stops short of full differentiation.

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

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

It gives clear conditional guidance: 'limit 0 only counts them' and 'online true lists who is playing now instead', directly telling the agent which mode to pick for counting vs. live status. It stops short of a 5 because it offers no exclusions or named alternatives (e.g. use get_player for one player's details).

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value with no output schema: it enumerates the returned fields and points at read_file for config contents, which is behavior beyond the annotations.

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

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

One compact sentence that front-loads the resource and then lists the returned fields; no filler, and the sibling pointer is tacked on at the end where it doesn't obscure the main claim.

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, the description carries the return-shape burden and does so by naming the fields, plus it explains how to obtain file contents. It stops short of noting ordering or whether disabled plugins are included, but nothing critical for a no-arg read tool is missing.

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

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

The tool takes zero parameters, so the baseline is 4; there are no inputs needing explanation and the description wastes no space pretending otherwise.

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?

A specific noun-plus-fields statement ('Installed plugins with version, enabled state, data folder, config files') makes clear this enumerates plugins and what's included. It doesn't explicitly differentiate from lookalikes such as list_extensions, but the resource 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?

Usage is only implied by the parenthetical '(read them with read_file)', which usefully routes the agent to a sibling for config contents. There is no explicit 'use this when…' or exclusion relative to list_extensions.

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

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

Annotations already cover read-only, idempotent, non-destructive, so the description's added value is the secrets policy (token values are withheld) and the permission gate — genuinely useful context beyond the annotations. It does not mention result size, pagination, or ordering for large token sets.

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 returned fields, then the flag semantics, then the permission gate, then the creation note. Four sentences with no filler, though the first two sentences partly overlap in listing group/permission data twice.

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, so the description carries the return-shape burden and does so by enumerating the fields and noting that token secrets are excluded. Combined with the permission requirement and the creation-location note, an agent has 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% and the schema says only "Add the groups and permissions"; the description expands this meaningfully by explaining that groups adds each group with its resolution and each permission with what it allows, i.e. the effect of the flag and the extra data. Slightly above the baseline 3 for a documented single flag.

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

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

The description names the resource (WorldAPI tokens) and enumerates exactly what is returned: name, config groups/permissions, resolved permissions, origin, creator, expiry. It also states what is NOT returned ("The tokens themselves never show"), which sharply distinguishes this from any credential-dumping tool.

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

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

It states the prerequisite ("Needs tokens:manage") and explicitly rules out the create path by pointing to the in-game command and admin panel "not here". There is no token-related sibling to route against, so no alternative tool comparison is possible, which keeps this at 4 rather than 5.

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

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

Annotations already declare read-only, idempotent, non-destructive semantics, and the description adds substantially more: `block` only scans loaded chunks (32 by default) and reports skipped chunks via `unloadedChunks`, `biome` reaches unexplored terrain (1024 by default), and structure search blocks the server thread, with a warning to keep radius modest. It also states the permissions needed for coordinates (players:private or anonymous access), which is exactly the beyond-schema context an agent needs.

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

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

It leads with the core purpose and is dense with no filler sentences, but it is one long paragraph mixing target syntax, defaults, permission requirements, and performance warnings, which makes it harder to scan than a short structured layout would be.

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 ten parameters, no output schema, and 70% schema coverage, this definition does the heavy lifting on coordinate resolution, defaults, permissions, and performance. It never mentions the `limit` or `world` parameters, and `unloadedChunks` is described without stating that it is a return field, leaving a small gap for a tool this complex.

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

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

The description adds meaning well beyond the 70%-covered schema: it gives concrete `targets` syntax per kind (`minecraft:diamond_ore`, `#minecraft:logs`, `village` matching every village kind), default radii for blocks and biomes, and the rules for omitting x/z, including the WORLDAPI_PLAYER fallback and spawn fallback for biomes and structures. It says nothing about `limit` or `world`, which the schema covers only briefly.

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

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

The opening sentence gives a specific verb and resource ('nearest blocks, biomes, or structures of some kinds, nearest first') and the three kind branches are each spelled out. It distinguishes the modes from one another, but does not name sibling tools such as get_block or find_containers to say when those apply instead.

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 tells the agent when each kind applies and what each one covers: `block` reads only loaded chunks, `biome` reaches unexplored land via the world generator, and `structure` can filter with `unexplored` to ones nobody found yet. The only missing piece is explicit routing against sibling tools.

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

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

Annotations already flag destructiveHint=true, but the description adds substantial context beyond them: whitelist enforcement kicks non-whitelisted online players, bans kick anyone online they hit, operator grants imply every command, and it names required permissions (server:console for operators, players:moderate generally). The user-confirmation requirement for bans and kicks is exactly the kind of pre-call caution an agent needs.

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

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

A single front-loaded summary clause followed by operation-by-operation sentences, each sentence carrying a distinct fact (permission, side effect, or confirmation rule). No repetition of the title or 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 destructive, 7-parameter, no-output-schema tool, the description covers permissions, side effects, and confirmation policy well. It leaves open what a partial/mixed call returns and whether operations are atomic on failure, which matters given the composability the description advertises.

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

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

With schema coverage at only 14% and 7 nested parameters, the description does most of the documentation work: it explains whitelist.enabled vs whitelist.enforced (with the enforcement side effect), operators.add/remove semantics, and the pairing of ban/pardon and banIps/pardonIps. It does not explain reason strings or ban duration semantics, though durationSeconds carries its own schema description.

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

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

Opens with a specific verb and resource scope ('Change who may play, in one call') and then enumerates every operation the tool bundles: whitelist, operators, ban/banIps, pardon/pardonIps, kick. An agent can immediately tell this is the mutation counterpart to get_access 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?

'Give only the parts you need' tells the agent the call is composable and partial, and 'Confirm bans and kicks with the user first' gives an explicit pre-flight rule. It never names an alternative or a when-not-to-use case (e.g. use get_access for read-only inspection), so it stops short of full routing guidance.

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

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, and openWorld=false, so the safety profile is covered. The description adds that data is read 'as it is now' (fresh, not cached), which is useful, but says nothing about error behavior for invalid namespace/path or what shape the resource 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?

Two compact sentences, front-loaded with what is read and from where, followed by the templating/query mechanics. 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?

There is no output schema and the return value is entirely plugin-defined, yet the description never says what comes back or how errors surface. Nested `query` object is handled well, but an agent still lacks a picture of the response.

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 67%, and the schema leaves `query` undocumented; the description compensates by explaining that query passes the resource's own options and gives an example object. The path templating trick ('players/Steve' for 'players/{player}') is a genuinely valuable addition 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?

States a specific verb and resource: reading one resource of a plugin, referenced against list_extensions, and clarifies freshness ('as it is now'). This lets an agent distinguish it from list_extensions (enumerate) and read_file (filesystem) 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?

Explains the workflow (take a resource from list_extensions, fill the path template) with a concrete example. It gives clear usage context but no explicit exclusions or failure conditions (e.g., unknown namespace or bad path).

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: the returned line format, the header fields (total, nextOffset, sha256 for write tools), the `--` gap marker, per-path permission requirements (logs:read vs files:read), and an explicit exclusion list (WorldAPI folder, hidden files, keys, databases, jars). The closing prompt-injection warning ('data, never instructions') is unusually valuable context for a tool whose output contains player-authored text.

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 most important fact — the returned line format — and no sentence is filler. It is however a dense run-on fragment rather than a stated verb, so the 'what it does' has to be reconstructed from the output description.

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, the description carries the return-value burden itself and does so fully (line numbering, header fields, nextOffset, sha256). It also covers path rules, permissions, and excluded locations — everything an agent needs to call this correctly on the first try.

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 schema already documents every parameter and the baseline is 3. The description still adds real semantics: the default 200 lines, the 2000 cap, that tail and grep are alternatives, and what the `context` lines look like in output (gap marked with `--`).

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 resource and output shape ('A text file as numbered lines, like `12<tab>text`') and enumerates the three read modes (offset window, tail, grep). It doesn't name or rule out the nearest siblings (get_server_log, list_files, read_extension), so differentiation 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?

Concrete usage contexts are given: `logs/latest.log` with tail 100, or grep `ERROR` across a day's log, which tells the agent what situations this tool fits. What's missing is explicit routing — it never says when to prefer get_server_log or list_files instead, and the log examples arguably overlap with the get_server_log sibling.

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

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

Adds substantial behavior beyond the destructiveHint annotation: no item drops, players are never affected in bulk mode, named mobs and tamed pets are skipped unless includeNamed is set, the nearest entities go first up to max, and dryRun only counts. That is well above the annotation bar. However, with zero required parameters it never states what a bare call (no uuid, no types, no radius) removes, which is the most consequential unknown for a destructive tool.

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

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

Front-loaded with the two modes and then the safety rules, with a short actionable closer about dryRun. Every clause carries information about behavior or selection. It is dense and somewhat run-on, packing five safety clauses into one sentence, which costs some parseability.

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, ten parameters, and a destructive operation; the description covers most behaviors but omits the scope of a no-argument call and never mentions the `world` parameter that governs which dimension is affected. For a tool where every parameter is optional and destructiveHint is true, the unfiltered-call behavior should be stated.

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 70% and the description reinforces the key semantics: uuid versus types (with example keys), radius relative to x/y/z, and the ordering rule for max ("nearest first up to max"), which the schema's max description does not convey. The `world` parameter is never mentioned in the description, leaving that one to the schema alone.

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 (remove) and resource (entities) and crisply separates the two operating modes: single-by-uuid versus bulk-by-types, the latter optionally scoped by a radius around x/y/z. It even supplies concrete use cases (dropped items, arrows, mob farm overflow). It does not contrast itself with siblings like list_entities or spawn_entity, so it is clear but lacks explicit sibling differentiation.

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

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

"Try dryRun first and tell the user what would go" is explicit procedural guidance for a destructive call, and the stated use cases (dropped items, arrows, overflow) tell the agent when this tool is the right one. It stops short of naming alternatives or stating when not to use the tool.

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

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

Annotations already flag destructiveHint=true, but the description goes further: it states worlds and players are saved, all online players are disconnected, requires server:control, and that a restart may effectively be a no-op stop depending on the host's restart policy. That is exactly the operational context an agent needs beyond the annotation flags.

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 key action and the save/shutdown sequence are front-loaded, and every clause carries meaning. The single dense paragraph is slightly run-on but has no filler sentences.

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

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

For a destructive, no-output-schema tool, the description covers prerequisites, side effects, pending-operation semantics, and the outcome of status. Nothing material an agent needs before invoking it 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 only 33% and the enum values have no descriptions, but the description explains the meaning of each action (restart, stop, cancel, status) and that warnings occur at set marks. It does not explain countdownSeconds' unit or 0-3600 bounds, leaving a minor gap compensated mostly by the schema itself.

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?

Starts with a concrete verb (restart/stop) and resource (the server), then explains the countdown-warning-save-shutdown sequence. It clearly distinguishes this from siblings like save_worlds and get_server_status by describing the shutdown outcome and the supervisor-dependent restart behavior.

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 clarifies what cancel and status do relative to restart/stop, notes that only one operation can be pending and scheduling replaces it, and adds a concrete precondition: confirm with the user because everyone is disconnected. This gives an agent both when-to-use and when-to-be-cautious 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?

Beyond the destructive annotation, the description explains that commands run as an operator can change the live world, players, and server; names example commands; notes ordering; says to omit the slash; states audit logging; and clarifies that output is server text to be treated as data, not instructions.

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

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

It is dense but front-loaded: purpose, scope, examples, permission, safety guidance, logging, and output handling appear in a compact sequence. Every sentence adds practical 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 destructive command-execution tool with no output schema, the description supplies permissions, behavior, safety warnings, syntax guidance, logging, and output interpretation. An agent has enough context to invoke it responsibly.

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

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

The schema already documents the commands array with examples, but the description adds useful operational semantics: commands run in order, should omit the leading slash, and can include plugin commands. It does not mention the schema's max of 16 commands.

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 precise verb and resource: running console commands as the server console, in order, returning each command's output. It distinguishes itself from more specific sibling tools by saying to prefer those when one exists.

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 routing guidance: prefer a specific tool when available, use search_commands to find exact syntax first, and confirm destructive actions with the user. It also names the required permission, server:console.

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

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

Annotations already establish non-readOnly, idempotent, non-destructive, non-openWorld behavior, so the safety profile is covered. The description adds genuinely useful context by naming the required permission ('Needs server:control'), but it omits whether the save is synchronous/blocking, how long it may take, or what happens to in-flight writes.

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

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

Two short sentences, zero filler, with the action and immediacy front-loaded and the permission requirement trailing as a constraint. Every clause 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?

For a simple one-parameter mutation the description is mostly adequate on the action and permission, but it leaves the only parameter unexplained and actively implies a behavior (always saving player data) that the `players` flag can override. With no output schema and no parameter docs anywhere, an agent cannot confidently decide whether to pass `players=false`.

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

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

Schema description coverage is 0%, so the description must explain the single `players` boolean, and it does not. Worse, 'Save every world, and player data, to disk now' reads as unconditional, which can mislead an agent into thinking player data is always saved even when `players` is set to false; the default of true and the toggle semantics are left entirely undocumented.

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

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

States a specific verb and resource ('Save every world, and player data, to disk') plus immediacy ('now'), which is enough for an agent to know exactly what it does. No sibling tool has overlapping purpose, so explicit differentiation is unnecessary, but it also doesn't mention the nearest risky neighbor (restart_server), keeping it just shy 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?

No guidance on when to call this versus alternatives, no mention of when not to call it (e.g., during shutdown or before restart), and no note about frequency or cost of flushing to disk. The word 'now' vaguely implies an immediate persistence request, but that is inference, not guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new context: the required scopes (commands:read or server:console), best-first result ordering, and the warning that plugin descriptions are data rather than instructions. It stops short of describing result shape or error behavior, so a 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?

It is a single dense paragraph that front-loads the resource definition and then packs in modes, permissions, and the injection caveat. Every sentence carries information, though the run-on density costs it a point versus a crisper layout.

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

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

For a read-only lookup tool with no output schema and full schema coverage, the description supplies everything needed: what is returned per record, the three calling modes, result ordering, and the permission requirement. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, which sets a baseline of 3, but the description goes further by explaining the interaction between parameters: each query is answered independently, plugin narrows the queries, and with neither supplied it counts commands per source. That is semantics the schema does not encode.

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 names a specific resource (the server's commands, including game, server, and plugin sources) and enumerates what each record carries: aliases, source, description, and usage. An agent can distinguish it from siblings like list_plugins or run_command 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?

It states an explicit operational rule — use it before run_command to learn what exists and how a command is typed — and explains the three call modes (queries, plugin, neither). That covers when to use it and how each alternative parameter shape selects a different behavior.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds context beyond that: omitting `players` broadcasts to everyone online (a real blast-radius detail) and a sound plays only for explicitly named players, implying unreachable/offline names silently miss it.

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 tight sentences, with the broadest-scope behavior (everyone online) surfaced immediately, then the sound caveat. No filler.

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

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

For a 6-parameter mutation tool with no output schema, the description covers targeting, kinds, and the sound constraint. Missing are delivery failure behavior (unknown/offline names) and whether `format` applies to titles and action bars alike.

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 67%, with enums and defaults documented inline. The description clarifies the `players` omission semantics and the sound restriction, but says nothing about `format`, `subtitle`, or how names vs UUIDs behave — those rely entirely on 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 names specific verbs and resources — chat message, title, action bar text, sound — and states the targeting scope (named players or everyone online). It is clearly distinguishable from generic siblings like run_command, though it never names an alternative 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?

It states the default audience when `players` is omitted and that a sound only plays for named players, which is useful routing context. However, it never says when to prefer this over run_command or world_effect, nor when to choose title vs actionbar vs chat.

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 annotations already declaring not read-only, idempotent and non-destructive, the description adds real value: the online-player prerequisite and the concrete error code `player_offline`. It stops short of saying whether a failed batch is atomic, but the essential operational context is present and consistent with annotations.

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, no padding, with the core grant/revoke semantics front-loaded and the precondition following. Every clause carries information an agent needs.

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

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

For a 3-required-parameter mutation with thin annotations and no output schema, the description covers semantics, precondition and failure mode. Minor omissions (batch atomicity, the 50-key cap already in the schema) do not block correct invocation.

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

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

Schema coverage is 67%, and the description supplies the meaning of the one undocumented parameter, `done`, in both of its states. That directly compensates for the coverage gap rather than restating 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 ('Complete every criterion') and resource (advancements for a player), and clarifies the bidirectional semantics of the required `done` flag. It doesn't reference siblings, but none of the listed siblings overlap this function, so differentiation is moot.

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 maps `done true` to granting and `done false` to revoking, and states the precondition (player must be online). No alternatives or exclusions are named, but there is no sibling that could be confused with this tool.

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

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

Beyond the destructiveHint=true annotation, it concretely discloses that prior content is irrecoverably gone, that physics=true triggers neighbor updates (sand falls, water flows), and that the server caps volume at 32768 blocks by default — exactly the side effects and limits an agent needs before a mutation.

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 dense paragraph that front-loads the two modes, then mode behavior, then side effects and the safety warning. Nearly every clause earns its place; only the slightly run-on mode sentence could be tightened.

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 destructive, nested-schema mutation tool with no output schema, the description covers modes, limits, and side effects well. It omits mutual exclusivity of `blocks` vs `box` and any sense of the success/failure response, which keeps it from being fully complete.

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

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

With only 25% schema coverage and nested objects, the description carries the load: it explains the 64-item cap on `blocks`, the block-state string format with examples, the inclusive corner semantics of `box`, the mode enum meanings, and what `replace` targets. It does not address the `world` parameter or what happens when both `blocks` and `box` are supplied.

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 names a specific verb and resource ('Place ... blocks') and immediately distinguishes its two operating shapes: a list of up to 64 single blocks versus a corner-to-corner box fill. An agent can tell this apart from read-only siblings like get_block 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?

The description tells you which mode to pick and what each box mode does ('replace' sets everything, 'keep' only fills air, 'replace_type' only changes blocks of type `replace`), plus a caution to confirm large changes with the user. It never names an alternative sibling tool or states when not to use this, so it stops short of a 5.

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

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

Annotations already declare readOnly=false, destructive=false and openWorld=false, but the description adds three things they don't: the clear-then-remove-then-add resolution order, the return value ('answers with the effects the player has afterwards'), and the player_offline failure mode. Minor gaps remain, such as what happens when add targets an effect the player already has.

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 sentences, each carrying distinct information: actions, ordering, return value, and precondition. The ordering constraint is front-loaded where an agent will read it before composing arguments.

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, so the description correctly compensates by stating what the call returns. Precondition and error code are covered, which is the main failure mode for this tool. Nested effect objects in add are left entirely to the schema, which is acceptable given the 75% coverage.

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 75%, so most parameters are already documented in the schema, including clear ('Take away every effect first') and the add fields. The description's ordering sentence is genuinely additive because it fixes how clear, remove and add interact within a single call, which the schema never states. Beyond that, no format or validation detail is supplied.

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 specific set of verbs and a precise resource: give, take away, or clear a player's potion effects. Scope (a single player) is unambiguous. It stops short of naming the sibling world_effect, so an agent must infer the player-vs-world split from the parameter names 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?

Offers real operational guidance: the three actions resolve in a stated order, and the player must be online or the call fails with player_offline. It never states when to prefer this over world_effect or get_player, so alternatives remain unaddressed.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so safety is partly covered. The description adds real value with the online precondition and the exact `player_offline` error token, but omits side effects an agent would want — e.g. whether health=0 kills the player, whether the change is transient, and whether unspecified properties are left untouched.

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, zero preamble: the property enumeration comes first and the hard precondition second. The comma-spliced property list is dense but each clause adds information; nothing 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?

With 18 parameters, no output schema, and sparse schema descriptions, the description gets most of the way there but leaves meaningful holes: an omitted parameter, no statement of what a successful call returns or confirms, and no note that supplying only `player` produces no change.

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 only 17%, so the description must carry the load. It partly does: it names nearly every settable property and supplies ranges and defaults for food (0–20) and speeds (-1 to 1; 0.2/0.1). But it leaves out `exhaustion` entirely, never distinguishes `level` from `exp`, and gives no units for health, fireTicks, or remainingAir.

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 specific verb ('Set') and enumerates the exact player properties affected, so the resource and operation are unambiguous. It doesn't name or contrast any sibling, but 'player' plus the Minecraft-specific property list inherently separates it from update_entity, set_effects, and teleport_player.

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 only usage rule given is the precondition 'The player must be online; otherwise the error is `player_offline`', which is genuinely useful. There is no guidance on when to prefer this over siblings such as update_entity or set_effects, and no statement that at least one property should be supplied (only `player` is required, so a name-only call appears legal but pointless).

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the agent knows this is a mutating but non-destructive, non-idempotent call. The description adds useful partial-update semantics ('only what you give changes') and clarifies that `respawn` changes the server-wide spawn point. It doesn't cover persistence requirements (does the world need saving?), permission needs, or failure behavior for conflicting inputs.

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?

Densely packed but front-loaded, with each sentence addressing a distinct parameter cluster. Some sentences are long and stack multiple facts (e.g., the `border` sentence), but nothing is plainly 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 an 11-parameter, nested-object mutation tool with no output schema, the description is thorough for nearly every parameter. The main gap is operational: persistence/save implications and interaction rules (e.g., passing both `dayTime` and `addTicks`, or both `spawn` and `respawn`) are not stated.

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 55%, so the description carries real weight and does so well: it explains `dayTime` tick values with concrete anchors (sunrise/morning/noon/night/midnight), `addTicks` as an alternative, `durationTicks` at 20 per second, the shape and an example of `rules`, what `border` subfields accomplish, and the critical distinction between `spawn` (this world's point) and `respawn` (the server's spawn point).

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 ('Change' a 'world') and immediately scopes it as a partial update ('only what you give changes'). It also distinguishes itself from the sibling get_world by noting that get_world with `include rules` lists game rules.

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 operating model: pass only the fields you want to change, with concrete context for each domain. It stops short of explicit 'when not to use' guidance or routing to alternatives such as world_effect or save_worlds after mutation.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent mutation, and the description adds a genuinely useful behavioral fact: the server caps the count at 50 by default. However, it says nothing about permission requirements, whether spawned entities persist across restarts (despite a `persistent` param), or what the call 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?

Two tight sentences, front-loaded with the core action and followed by the one operational constraint that matters. No filler or restatement of the title.

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 9-parameter mutation tool with a nested location object and no output schema, the description is thin: it omits return information (e.g., whether spawn results/entity IDs come back), permission expectations, and the meaning of most optional flags. An agent would need to guess at half the parameter surface.

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 only 44% across 9 parameters, so the description needs to compensate and does not: `ai`, `glowing`, `customName`, `count` semantics, and the oddly placed `format` are all left undocumented. The description only echoes the `type` example and the count cap, adding almost nothing beyond the structured 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 ('Spawn one or more entities of a type') plus a concrete example id (`minecraft:cow`), which unambiguously separates it from siblings like list_entities, update_entity and remove_entity. The scope ('one or more', 'at a location') is clear from the first clause.

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

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

The purpose implies when to use it, but there is no explicit guidance on alternatives (e.g., use update_entity to modify an existing entity, remove_entity to clear it) nor any stated prerequisites such as operator permissions. The only conditional information is the server-side count cap.

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

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

Annotations already establish that this is a mutating, non-destructive, non-idempotent operation. The description adds useful behavioral context beyond that: the online requirement, the specific `player_offline` error, and the recommendation to check the surface first. It does not cover permission requirements or chunk-loading behavior, so it is strong but not exhaustive.

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

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

The description is three front-loaded sentences with no wasted text. The target-mode constraint appears first, followed by the prerequisite and the online failure condition.

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 teleport mutation with rich schema coverage and clear annotations, the description covers the essential call requirements and one common failure mode. It could say more about permissions or what happens if the destination is in an unloaded chunk, but it is otherwise complete enough for an agent to invoke correctly.

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

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

With 100% schema description coverage, the schema already carries the parameter basics. The description adds a meaningful constraint that is not obvious from the schema alone: exactly one of location, toPlayer, or worldSpawn must be provided. It also ties the get_block check to selecting safe y coordinates.

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

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

The description uses a specific verb and resource ('Teleport a player') and explicitly enumerates the three target modes: coordinates, another player, or a world spawn. This lets an agent distinguish it from sibling tools like locate or set_world 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?

It gives clear contextual guidance: exactly one target mode must be supplied, the player must be online, and get_block should be used first to find a safe surface. It does not state when not to teleport or name a direct alternative tool, which keeps it 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?

Annotations already declare that this is a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description adds the operational scope and player exclusion, but does not explain whether updates are partial, how omitted fields behave, what permissions are needed, or what happens for invalid entities.

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

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

The description is a single compact action list followed by an exclusion, with no filler. It is front-loaded with the operations an agent needs to recognize the tool.

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 17-parameter mutation tool with low schema description coverage and no output schema, the description is too thin. It omits required uuid usage, several optional parameters, interaction semantics between fields, and failure behavior, leaving material gaps 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 only 18%, so the description must compensate. It maps several parameters to actions (rename, AI, glowing, gravity, invulnerability, health, fire, teleport, push, tags), but leaves silent, persistent, customNameVisible, format, world, uuid, and the semantics of negative fireTicks or health zero unexplained.

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

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

The description names the resource (an entity) and enumerates concrete operations: rename, toggle AI/glowing/gravity/invulnerability, set health/fire, teleport, push, tag. It also explicitly excludes players, which distinguishes it from player-focused siblings such as set_player_property and teleport_player.

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 'Not for players' gives a clear when-not condition and implicitly routes player changes to the player tools. However, it does not name the alternative tools explicitly or describe when to use this versus spawn_entity/remove_entity beyond the player exclusion.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so the description's real contribution is that this call blocks live, that it can time out, and that certain event types require chat:read or logs:read permissions – permission requirements that would otherwise be invisible. It stops short of saying what a timeout actually returns, which is the one behavioral detail an agent most needs.

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

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

Front-loaded with the core action and timeout behavior, and the long event-type list earns its space as a value reference. The list is delivered as one run-on sentence with an interleaved parenthetical about permissions, which makes it slightly harder to scan than necessary.

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 'get it' does not describe the shape of a returned event or what happens on timeout (error versus empty result) – a significant omission for a blocking tool where callers must branch on that outcome. Permission scoping and type enumeration are well covered, so the gap is narrow but real.

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 75% and the schema gives no enums, so the description's enumeration of valid 'types' values (player.join, block.break, server.console, etc.) is genuinely load-bearing information not available elsewhere. It also explains that 'player' and 'world' act as narrowing filters and that timeoutSeconds is bounded by client limits, though it adds nothing about the default or the 1-300 range 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 specific verb and resource ('Wait until an event happens live and get it, or time out') and enumerates the concrete event types, which immediately separates it from the sibling get_events that returns already-recorded events. An agent can tell exactly what this tool does 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?

Gives three concrete usage scenarios ('tell me when Steve logs in', 'wait until night is skipped', 'wait for the console to say Done') and notes the timeoutSeconds client constraint. It does not explicitly say when to prefer a sibling such as get_events for past events, so the routing guidance 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?

Annotations already declare destructiveHint=true, non-readOnly, and non-idempotent; the description adds useful behavior beyond that: effectOnly makes lightning harmless, breakBlocks destroys terrain, fire ignites, sounds are heard nearby, and unsupported particle types are called out. It still leaves some consequences of explosions and lightning unstated, so not a 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?

It is a single compact paragraph, front-loaded with purpose and then one sentence per effect type; no sentence is wasted. It could be slightly better organized as a list, and the opening line is less precise than the rest, so 4.

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 multi-mode destructive tool with no output schema, the description covers all four modes and key caveats, while annotations cover the safety profile and schema covers coordinates and defaults. Remaining gaps are mostly tool-selection guidance rather than invocation-critical detail.

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 93%, so the schema carries most parameter documentation. The description adds real meaning for key mode-specific parameters (effectOnly, power with TNT=4, breakBlocks/fire, sound and particle examples, unsupported particle keys), which lifts it above the baseline 3.

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 first sentence is vague ('Make something happen at a location'), but the following sentences name four concrete effect types and what each does, so an agent can tell this is an environmental-effects tool. It does not explicitly distinguish itself from siblings such as run_command or set_effects, which keeps it from 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 gives mode-specific hints, such as effectOnly making lightning harmless, but never states when to choose world_effect over run_command, set_blocks, spawn_entity, or set_effects. Usage is implied by the kind enum rather than explicitly routed.

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