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

With no annotations, the description carries the burden and it does disclose non-obvious behavior: rows map north→south, characters west→east, spaces are no-ops, and rotation keeps the min corner at origin. It also signals a write operation by directing dry_run=true. It stops short of explaining snapshot/undo behavior, but that is present in the schema.

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

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

Three dense sentences pack the purpose, coordinate axes, space sentinel, extra blocks, rotation invariant, and a safety workflow with no filler. It is front-loaded and 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 an 11-parameter, nested-object tool, the description provides the key mental model and the critical safety sequence, leaving details to a rich schema. It does not describe return values, but there is no output schema and the combination of description plus schema is sufficient.

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

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

Schema coverage is very high (91%), and the schema already documents palette, layers, blocks, rotation, and snapshot. The description mostly restates the schema's semantics (orientation, space, rotation corner) rather than adding new parameter meaning; the baseline 3 applies.

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

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

The description opens with a specific action—'Place a structure described as layers of characters'—and immediately supplies the coordinate semantics, so the agent knows the tool's domain. It is distinguishable from siblings like fill or paste_schematic by the ASCII-layer mechanism, 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 provides an explicit safe workflow: 'Run with dry_run=true first, and preview before that.' This tells the agent to invoke preview before build and to use dry-run before actually placing. It does not contrast build with fill/place_shape/paste_schematic, but the 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?

With no annotations, the description carries the full burden, and it does well: it discloses behavioral distinctions between modes, including item drops for destroy, interior untouched for outline, and automatic splitting over the 32768-block command limit. It does not explicitly state that the operation modifies the world or that snapshots are taken by default, but the schema's dry_run and snapshot parameters cover some of that.

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

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

Two sentences, front-loaded with the core action, then compactly packed mode semantics and the auto-split behavior. There is no filler or redundant restatement of schema fields.

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 10-parameter tool with no output schema, the description plus the schema covers the essential behaviors: modes, replace filtering, auto-splitting, snapshot control, dry run, and world selection. The main missing piece is an explicit statement of the expected result/return value, but that is not critical for 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 70%, and the description adds real meaning to the mode enum and replace_filter by explaining what each mode does. It does not clarify the from/to coordinate interpretation, though the schema's array-of-3-integers type provides a baseline hint.

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

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

The description clearly states the tool's action: 'Fill a box with one block' and enumerates the five modes, making the resource and operation specific. It does not explicitly distinguish fill from sibling tools like build or place_shape, so it stops short of a 5.

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

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

The mode list gives implied usage context: choose replace when you want optional filtering, keep for air-only, destroy to drop items, etc. However, there is no explicit guidance about when to use fill instead of build, place_shape, or paste_schematic, and no exclusion criteria or when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, but it merely restates that a block state exists at a position. It does not confirm that this is a read-only operation, describe what the returned block state contains, or mention failure/error behavior. The only read-only signal comes from the name and title, not the description.

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

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

The description is a single short sentence with no fluff, which is concise. However, it is closer to under-specification than to disciplined conciseness: it is a noun fragment rather than a structured instruction and omits key operational details.

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

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

For a tool with no annotations and no output schema, this description is incomplete. It does not explain the coordinate format for 'pos', the default or optional behavior of 'world', or what the block state result looks like. The description leaves too much for the agent to infer.

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 50%, and the description adds little beyond the word 'position'. The required 'pos' parameter has no schema description and no format clarification in the description, while the optional 'world' parameter is left entirely unaddressed despite having a partial schema description. The description does not compensate for the undocumented parameter.

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

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

The description names a clear resource (block state) and a location (position), and the title 'Read one block' supplies the action. This distinguishes it from sibling tools like read_region and get_heightmap, which operate over areas. It is not a fully explicit verb phrase, but the intent is unambiguous.

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

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

The description gives no guidance about when to use this tool versus alternatives such as read_region, preview, or get_heightmap. It does not state exclusions, limitations, or recommended contexts. Usage can only be inferred from the tool name and title.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses output structure and grid orientation, but does not explicitly state whether the operation is read-only, how 'surface' is determined, or how sampling affects the result. This leaves some uncertainty for an agent.

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 with no wasted words. The primary output is stated first, followed by the practical use case. It is front-loaded and easy to parse.

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

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

For a heightmap query tool with no output schema, the description is reasonably complete: it explains the return format, coordinate orientation, and practical application. It could be more explicit about edge cases or the exact surface definition, but the core information an agent needs is present.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds useful context about the x/z rectangle and grid orientation, but it does not add meaning beyond what the schema provides for individual parameters like 'world' or 'sample'.

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 what the tool returns: surface y and surface block for an x/z rectangle as a sampled grid. It also names the practical use case ('site-scouting tool') and distinguishes it from sibling tools by its specific read-only terrain query purpose.

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

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

The description gives clear context for when to use the tool: to find flat ground and determine the y level to build at. It does not explicitly name exclusion criteria or alternative tools, but the use case is specific enough to guide selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It strongly implies a read-only operation by enumerating current-state fields of online players, and it does not hint at any destructive side effects. However, it does not explicitly state read-only behavior, permission requirements, or any data freshness caveats.

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 two short sentences with no wasted words. The first sentence front-loads the exact data fields returned, and the second sentence adds a practical use case. Every part 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 zero-parameter read-only tool with no output schema, the description is complete: it enumerates the player fields an agent can expect, implies per-player data, and gives an example scenario. Nothing critical is missing for correct invocation.

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

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

The input schema is empty with zero parameters, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, the description need not compensate for any schema gaps. The description appropriately focuses on the returned data instead.

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 tool as reporting the names, worlds, block positions, look direction, and gamemode of online players. It lacks an explicit verb like 'lists' or 'returns', but the resource and data fields are unmistakable. It also distinguishes itself from sibling tools, which focus on server info, regions, blocks, and schematics rather than player state.

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

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

The description provides a concrete use case: 'Use to pick a build site near someone.' This gives an agent clear context for when the tool is useful. It does not explicitly mention alternatives or when not to use it, but no sibling tool appears to compete with this player-listing function.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does reveal that snapshots are taken before writes, are returned newest-first, and expose IDs for undo. However, it does not explicitly state that listing is read-only or mention pagination/limits, though the verb 'List' conveys a safe read operation.

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

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

The description is a single, information-dense sentence with no filler. It packs the snapshot policy ('taken before writes'), ordering ('newest first'), and purpose ('ids for undo') into a compact statement, and the title supplies the missing verb.

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 list tool with no output schema, the description covers the core facts an agent needs: what snapshots are, their ordering, and how their IDs relate to undo. It does not explicitly say it lists all snapshots or describe the response shape, but the complexity is low and the title/schema cover basic 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 input schema is empty with zero parameters, so there are no parameter semantics for the description to clarify. The description offers no parameter-level detail, but none is needed; the zero-parameter baseline of 4 applies.

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

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

The title clearly gives the verb+resource ('List snapshots'), and the description adds that snapshots are pre-write, ordered newest-first, and carry IDs for undo. It is clear about what is retrieved, but it never explicitly differentiates itself from close siblings like undo, so it stops short of a 5.

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

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

The phrase 'with ids for undo' implies this tool is the lookup step before using undo, but the description never states when to choose list_snapshots over undo or another sibling. There are no explicit when/when-not conditions or alternative tool names, so guidance is only 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?

No annotations are present, so the description carries the disclosure burden. It does explain non-obvious behaviors: default origin at min corner, use_offset applying the file's stored offset, and ignore_air preserving surroundings. However, it omits broader side effects like block overwrite and the snapshot/undo default.

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 sentences with no filler; the key file types and origin behavior are front-loaded, and each sentence contributes useful 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 an 11-parameter world-mutating tool with no annotations or output schema, the description covers formats and the most non-obvious flags but omits the mutating/undo context and overwrite semantics. It is minimally viable for basic invocation but not fully complete.

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

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

Schema description coverage is only 55%, so the description must compensate. It adds real meaning for origin, use_offset, and ignore_air, but leaves label, mirror, and rotation to inference, though the enums make those somewhat self-explanatory.

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 ('Paste') with named resource types (Sponge .schem, vanilla .nbt) and clarifies the core behavior. This clearly distinguishes it from read/save siblings like save_schematic and schematic_info.

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 choose paste_schematic over build, place_shape, or schematic_write, nor when to avoid it. The only usage-like detail is toggling use_offset/ignore_air, which is parameter behavior rather than tool-selection guidance.

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

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

With no annotations, the description carries the full burden of disclosing side effects, but it only mentions geometric modes and the radius-to-diameter rule. It does not state that blocks are written to the world, that snapshot/dry_run affect undoability, or what permissions might be required. For a mutating tool this is a meaningful transparency gap.

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

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

The description is two compact sentences with no filler, front-loading the shape list and then giving the single most important geometry caveat. Every sentence earns its place.

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

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

Given 18 parameters, no output schema, and no annotations, the description needs to signal world mutation, preview/undo behavior, or at least distinguish from related region tools. It does none of these. The result is too sparse to fully support correct tool selection and 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 89%, so the schema already documents nearly all parameters in detail. The description lists shapes already present in the enum and repeats the schema's 'diameter = 2r+1' note, adding no new parameter meaning. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

Title and first sentence name the operation (placing) and enumerate seven supported primitives, so an agent knows exactly what resource this produces. It is clear enough but does not explicitly differentiate from sibling tools like fill or build, so it falls one step short of top marks.

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

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

The description provides no guidance on when to use place_shape versus fill, build, or paste_schematic. There are no conditions, exclusions, or use-case examples. An agent is left to infer selection context from the tool name alone.

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

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

With no annotations present, the description carries the behavioral disclosure burden, and it does well: it states the tool is read-only ('Nothing is changed in the world'), describes both return artifacts, and explains the context>0 behavior. It could additionally mention access requirements or output-file lifecycle, but the core side-effect and output behavior are clearly disclosed.

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 tight sentences front-load the main action, specify outputs, and end with the key safety property. Every sentence earns its place and there is no filler.

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

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

This is a complex tool: seven top-level parameters, nested alternatives, no output schema, and no annotations. The description gives only a high-level overview and omits mode exclusivity, default/limit behavior, return structure, and how the HTML path is delivered, so it is not complete enough for reliable autonomous 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 29%, so the description needed to compensate, but it only clarifies context>0 and loosely groups the three input modes. It does not explain that build/shape/schematic are alternative sources, what max_layers controls, how world/title are used, or the expected output contract.

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 ('Render') and identifies three input kinds (build spec, shape, schematic) plus the two output forms (ASCII slices and a 3D HTML viewer). It also states 'Nothing is changed in the world,' which distinguishes it from placement-style sibling tools, though it does not name those siblings 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?

The title 'Preview a build before placing it' and the note that nothing changes in the world imply this is for verification rather than execution. However, the description never explicitly tells the agent when to choose preview over build, place_shape, or paste_schematic, nor does it state that no world modification will occur as a reason to prefer it.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals non-obvious behavior: ASCII layer slices are only included when the box is ≤4096 blocks or full=true. It does not explicitly state that the operation is read-only, although the verb 'Read' and the verification context strongly imply 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?

The description is two short sentences with no filler. The first states the core behavior and condition; the second gives the intended usage. Everything present 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 tool with no output schema and no annotations, the description gives a useful summary of the return content and a usage context, but it omits critical parameter details such as max_layers semantics and from/to coordinate conventions. It is adequate for basic invocation but not fully complete.

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

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

Schema description coverage is only 20% (world is described), and the tool description must compensate. It explains full's role and hints that from/to define a box, but it does not explain the coordinate order, whether bounds are inclusive, or the behavior and purpose of max_layers. These are significant gaps for a region-reading tool.

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

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

The description states a clear verb and resource: reading a region of blocks and returning block counts plus ASCII layer slices. It distinguishes itself from sibling tools like get_block or get_heightmap by describing box-level output rather than single-point queries, though it does not explicitly name those alternatives.

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 says 'Use after building to verify the result,' which gives a clear intended context. It does not, however, explain when not to use it or when to prefer a sibling tool like get_block or preview.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds a significant behavioral guardrail: administrative commands are refused unless the environment variable is set, and the tool returns raw command output. It does not detail failure modes or side effects, but the 'raw console command' framing signals arbitrary execution.

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 sentences, each earning its place: the core action, the admin restriction, and the usage routing. The most important information is front-loaded and nothing is redundant.

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

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

The description provides the essential facts: what the tool does, what the output is, a key restriction, and guidance on when to use it. It lacks details on output formatting or error handling, but for a simple one-parameter tool this is a minor gap.

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

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

The schema already covers the single parameter with a clear example and 'without a leading slash' instruction, so the baseline is 3. The description adds value by suggesting valid command categories (time, weather, tp, give, say) and the admin-command restriction, which helps the agent choose appropriate values.

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

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

The description states a specific verb ('Run') and resource ('raw server console command'), and makes it clear the tool returns the command's output. It also distinguishes itself from the sibling build tools by naming the kinds of commands it is for (time, weather, tp, give, say).

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

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

The description explicitly says to prefer the build tools and that this tool should be used for console commands like time, weather, tp, give, say. It also gives a concrete condition for admin commands being refused unless BLOCKWRIGHT_ALLOW_ADMIN=1. This is clear guidance on when and 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?

With no annotations, the description carries the behavioral disclosure burden. It communicates the core outcome and the useful detail that block entities are included. However, it does not mention overwrite behavior, file path constraints, or whether the operation is non-destructive to the world, though 'copy' implies it is.

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 focused sentence that front-loads the core action and adds only the essential detail about block entities. There is no redundancy or 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 five-parameter tool with no output schema or annotations, the description gives enough to attempt a call but omits defaults, overwrite behavior, coordinate boundary semantics, and return behavior. It is adequate but not thorough.

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

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

Schema description coverage is only 20%, with only 'world' described. The description compensates by clarifying from/to as a box, mapping the format enum to .schem (Sponge v3) or .nbt (structure), and identifying path as the output file. It still leaves gaps around format defaults, path semantics, and coordinate inclusiveness.

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

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

The description clearly states the operation: copying a box from the world into a .schem or .nbt file, with block entities included. It distinguishes this from paste_schematic by direction, though it does not explicitly separate it from the similarly named schematic_write.

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

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

There is no guidance on when to use this tool versus any sibling such as paste_schematic or schematic_write. The description implies a saving use case but does not state prerequisites, exclusions, or alternatives.

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

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

With no annotations provided, the description must carry the behavioral burden. It implies a read-only inspection operation and lists the output contents, which is helpful. However, it does not explicitly state that no modification occurs, how errors like missing files are handled, or whether the path is local to the server.

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 sentence that front-loads the key output fields. There is no redundant wording, and every phrase contributes to understanding the tool's purpose.

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

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

For a simple inspection tool with one parameter and no output schema, the description adequately lists return values but omits usage context such as path interpretation and edge-case behavior. It is minimally complete but leaves room for ambiguity about how the path should be supplied and what happens for invalid files.

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

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

The input schema has 0% description coverage for the single 'path' parameter, so the description must compensate. It only indirectly relates path to '.schem/.nbt files' without explaining path semantics, allowed file types, or required format. The agent has limited added meaning beyond the parameter name 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?

The title 'Inspect a schematic file' provides a specific verb and resource, and the description enumerates the exact metadata fields returned (format, size, offset, DataVersion, block counts, block-entity count). This clearly distinguishes it from sibling tools like preview, get_block, or paste_schematic, which operate on different aspects.

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 what the tool does but gives no guidance on when to use it versus alternatives. It does not mention when to prefer schematic_info over preview, read_region, or schematic_write, nor any prerequisites such as file existence or path restrictions.

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

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

With no annotations, the description carries the burden and does disclose meaningful behavior: it does not affect any server and writes to the schematic directory for relative paths. It stops short of revealing whether files are overwritten or what happens on invalid paths, but the key safety-relevant behavior is clearly stated.

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

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

The description is two sentences with no filler. The most important behavioral constraint ('without touching any server') and path behavior are front-loaded, and 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 complex tool with nested build and shape objects, no annotations, and no output schema, the description is minimal. The schema covers parameter details well, but the description does not clarify whether build and shape are mutually exclusive, what happens on overwrite, or what the tool returns. It is adequate but has clear gaps.

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

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

Schema description coverage is low at the top level (25%), and the description does add some value by explaining that relative paths target the schematic directory and by mapping .schem/.nbt to file formats. However, it does not explain the two main modes 'build' and 'shape', their relationship, or when each is appropriate; it mostly relies on the rich nested property descriptions 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?

The description clearly states a specific verb and resource: 'Save a build spec or a shape as a .schem (Sponge v3) or .nbt (vanilla structure) file'. It is not a tautology and distinguishes the offline/local intent with 'without touching any server'. However, it does not explicitly differentiate itself from the similarly named sibling 'save_schematic'.

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 'without touching any server' implies this tool is for writing schematic files offline, and 'Relative paths go to the schematic dir' gives useful context. But there are no explicit when-to-use/when-not-to-use statements or named alternatives such as save_schematic, build, or place_shape.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It implies a read-only information retrieval by listing informational fields, but it never explicitly states that it has no side effects or whether any permissions are required. For a zero-parameter info tool this is acceptable but not fully explicit.

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 sentence that efficiently lists the four information categories. It is concise and puts the most concrete item first, though it reads as a series of field names rather than a complete sentence with a verb.

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

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

Given no output schema and no annotations, the description is the sole documentation. It covers the main content categories but doesn't describe the response shape, types, or the meaning of 'effective blockwright configuration.' This is adequate for a simple info tool but leaves some ambiguity.

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

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

The tool takes no parameters, and the input schema has 100% coverage (empty). Per the zero-parameter baseline, the description doesn't need to add parameter information, and it doesn't omit anything relevant.

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 enumerates the specific data returned: Minecraft version, player count, snapshot availability, and blockwright configuration. It identifies the resource (server info) and is distinct from siblings like get_players or list_snapshots, though it lacks an explicit verb and doesn't explicitly contrast with those tools.

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

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

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention that get_players gives more detailed player data or that list_snapshots handles snapshot-specific operations. The intended use is only implied by the name and listed content.

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

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

With no annotations, the description carries the behavioral burden. It discloses the important side effect that each restored snapshot is removed from the list. However, it does not explain whether restoration overwrites current state irreversibly, how newer snapshots are handled, or any permission requirements.

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

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

The description is a single, well-structured sentence. The core action comes first, the source for the optional id is provided, and the side effect is stated without any 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?

The description covers the main action, the id source, and a side effect, which is solid for a simple tool. But it does not explain the 'steps' parameter explicitly, nor does it describe failure behavior or what happens to snapshots newer than the one being restored. Given there is no output schema and no annotations, these gaps leave some ambiguity.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It gives useful meaning for 'id' by tying it to list_snapshots, but the 'steps' parameter is only vaguely implied by 'snapshot(s)' and its role in controlling how many snapshots to restore is not stated.

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 ('Restore') and resource ('snapshot(s)'), and clarifies the scope: snapshots taken before writes. It also distinguishes itself from list_snapshots by indicating it consumes an id from that listing rather than merely showing it.

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

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

The description gives clear context: use this after writes to restore the newest pre-write snapshots, or provide a specific id from list_snapshots. It does not explicitly list exclusions or alternatives, but the intended timing and targeting are evident.

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