CodeCraft

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

The annotations already indicate readOnlyHint=true, and the description adds useful behavioral context: when a request is blocked, the tool returns the reason, supporting evidence, and an alternative. It also calls out specific nonexistent APIs, going beyond what annotations provide. No contradiction 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 carry substantial value with no waste. The first states the core behavior and outputs; the second gives a mandatory-before-coding directive with concrete, high-risk examples. The most important usage guidance is front-loaded.

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

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

Although there is no output schema, the description adequately covers return behavior (why, evidence, alternative) and the most common misuse scenario. For a single-parameter, read-only feasibility check, nothing critical is missing for an agent 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 single 'request' parameter is already described as 'The user request in their own words. Any language is accepted.' The description reinforces this by referring to 'a user request' but adds no meaningful semantic detail beyond the schema.

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

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

The description clearly states the tool's purpose: checking whether a request can be built with a behavior pack and the @minecraft/server API. It also distinguishes this from sibling validation tools by focusing on feasibility and blocked-request outcomes rather than syntax or schema validation.

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 explicit timing guidance: 'Call this BEFORE writing any code or JSON.' It also warns about the most commonly hallucinated APIs. It doesn't explicitly name sibling tools as alternatives for other scenarios, so it falls just short of a 5.

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

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

With readOnlyHint=true already covering safety, the description adds meaningful behavioral context: the summary is not the raw schema, large nodes are narrowed with a truncation indicator, and descending via path provides fuller detail. This goes beyond the annotations and helps set agent expectations, though it is slightly vague about the exact truncation representation.

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 first states the core result, the second clarifies scope and truncation behavior, and the third gives direct usage guidance. No filler or redundant restatement of the tool name.

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

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

For a tool with no output schema, the description does a solid job of explaining what is returned, how truncation works, how to get more detail, and when to call it. The schema covers parameter details like defaults and error cases. It is complete enough for an agent to use correctly, though it does not mention where to find the document type list other than via the parameter schema's reference to get_version_info.

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 path, type, and version thoroughly. The description adds contextual relevance by mentioning required fields and format_version, but it does not add parameter-level detail beyond what the schema already provides, so the baseline score of 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 uses a specific verb ('summarises') and resource ('schema of a Bedrock document type'), then enumerates the exact contents: required fields, valid format_version values, and field metadata. It also explicitly distinguishes itself from returning the raw schema, so an agent can tell what this tool does and does not do.

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 intended context: 'Call this before writing a file to learn which fields are required and what format_version must be.' It also explains when to use the path parameter to descend into a child node. However, it does not explicitly name alternatives or state when not to use the tool beyond noting that it does not return the raw schema.

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?

readOnlyHint=true already signals a safe read, so the description does not need to repeat safety semantics. It adds useful behavioral context: format_version is independent of the game version, and the tool is an up-front prerequisite for behavior pack authoring, preventing a common conceptual misuse.

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 informative: the returns are enumerated in the first, the format_version caveat in the second, and practical usage in the third. There is no redundant or filler content.

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

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

Even with no output schema, the description enumerates precisely what the agent can expect to learn: min_engine_version, module versions, format_version values, and document types. Combined with the schema and read-only annotation, nothing critical is missing for correctly invoking this tool.

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

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

The schema describes the single optional version parameter with 100% coverage, including format and rejection of marketing numbers. The description only reiterates that the tool is scoped to 'this game version,' so it adds little beyond the schema—hence 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 description uses a specific verb ('Returns') and names a precise resource: version-number mappings for a given game version, including min_engine_version, module versions, format_version values, and document types. This concrete enumeration differentiates it from sibling tools like get_schema, which would retrieve schema definitions rather than version mappings.

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 states when to call: 'Call this before writing any behavior pack file.' It does not discuss when not to use it or compare with alternatives, but the directive is clear and actionable.

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

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

Annotations already indicate read-only behavior, so the description does not need to cover that. It adds valuable behavior beyond annotations: namespace defaulting, block states for block identifiers, and the critical warning that invalid identifiers fail silently in-game. This is meaningful operational context.

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

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

Three sentences with no wasted words. The main function is stated first, then the block-specific detail, and finally the usage warning. Every sentence earns its place and the critical guidance is front-loaded.

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 two-parameter tool with no output schema, the description covers what the tool does, the categories it recognizes, the special case for blocks, namespace handling, and the consequence of invalid input. An agent has enough to call it correctly and interpret the result sufficiently.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining the namespace default ('An identifier without a namespace is treated as minecraft:') and reinforcing the version default behavior through context, going beyond the schema examples.

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 (verify), a precise resource (minecraft: identifier existence and kind), and enumerates the categories it covers. It is clearly distinct from sibling validation tools, which target commands, JSON, scripts, or feasibility.

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 an explicit when-to-use directive: 'Verify every identifier here before writing it.' This makes the intended invocation context clear. It does not explicitly name alternatives or exclusions, but none of the sibling tools overlap closely enough to require that.

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 readOnlyHint annotation already signals a non-mutating operation, and the description adds valuable behavioral detail: it applies the correct validator per file type and runs extra checks schema validation cannot perform. It does not discuss output/error behavior, but that is not required for a read-only validation 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?

Two sentences, front-loaded with the core function and scoped immediately. The detailed list of semantic checks is compact and each clause adds information without 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 complex pack-validation tool, the description covers purpose, process, scope, and placement in the workflow. The absence of an output schema means the return shape is not described, but the invocation context is sufficiently complete for an agent to use the tool 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?

Input schema coverage is 100%, and the schema fully documents files, path, content, and version including examples, defaults, and rejected formats. The description adds little parameter-specific meaning, matching the baseline for fully documented schemas.

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 action — validating every file of a behavior or resource pack — and distinguishes it from per-file validation siblings. It lists both the automatic validator dispatch and the semantic checks, making the tool's scope 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 explicitly says this is the LAST step before handing a pack to the user and notes it is faster and broader than validating files separately. It does not name specific sibling tools or exclusion cases, but the usage 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?

The annotations already indicate readOnlyHint=true, and the description is consistent: validation is non-mutating. The description adds rich behavioral detail: no-overload behavior returns valid usages, it reports whether cheats are required, and it resolves execute chains including nested execute. This significantly exceeds annotation coverage.

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

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

Three dense sentences carry substantial information without redundancy. The most decision-relevant details are front-loaded, and every sentence earns its place by adding either scope, failure behavior, or practical invocation guidance.

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?

Even without an output schema, the description tells the agent what results to expect on failure (valid usages), what additional information is provided (cheats requirement), and how complex execute chains are handled. This is sufficient for correct invocation and interpretation for a validation tool with read-only annotations.

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

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

Schema description coverage is 100%, so the schema already documents line and version, including the optional leading slash and version format/constraints. The description adds little parameter-specific meaning beyond noting validation of the command line, so the baseline score of 3 applies.

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

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

The description uses a specific verb and resource: 'validates a single Bedrock command line against the official command index.' It enumerates what is checked (existence, argument count, selectors, block states) and clearly differentiates itself from sibling tools like validate_json, validate_python, and validate_script.

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 instruction 'Run every command through this before giving it to the user' is an explicit when-to-use directive. However, it does not mention alternatives or conditions for when to prefer a sibling tool, so it stops short of the fullest 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?

The annotation readOnlyHint=true already signals safety. The description adds valuable behavioral detail beyond annotations: it returns per-error JSON pointers and rules, and includes unexpected property names and valid enum values in messages. This helps the agent understand the tool's output without being contradicted by 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?

The description is three focused sentences. The first states the core action and output, the second adds useful output detail, and the third gives a direct usage instruction. Every sentence earns its place with no redundancy.

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

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

The description fully covers the tool's purpose, output shape, and usage context. While there is no output schema, the description explains exactly what the tool returns per error. Parameter details are already present in the high-coverage schema, so nothing critical is missing for an agent 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add much parameter-level semantics beyond the schema, which makes the baseline 3 appropriate.

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

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

The description states a specific verb ('Validates'), a clear resource ('behavior or resource pack JSON file against the official schema'), and the output format ('JSON pointer, violated rule, readable message'). It is unambiguous and distinguishes validate_json from sibling validators like validate_command, validate_python, and validate_script.

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 an explicit usage directive: 'Run every JSON file you produce through this before handing it to the user.' This is clear context for when to use the tool, though it does not explicitly discuss when not to use it or name 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?

Annotations only provide readOnlyHint=true, so the description carries the behavioral burden. It discloses that validation uses the real interpreter, checks embedded commands against the official index, validates the /connect envelope shape, and explains the important result nuance that ok:true alone does not guarantee valid syntax. This goes well beyond the structured 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?

The description is front-loaded with the core purpose, then covers exclusions and critical result semantics without fluff. Every sentence adds value, and the structure leads from what the tool does to when not to use it to the key caveat.

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 validation tool with no output schema and minimal annotations, this description is remarkably complete. It covers the three validation axes, the alternative tool, the command-detection rule, and the meaning of syntaxChecked, leaving an agent well-equipped to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context for the code parameter by clarifying that the script runs outside the game and that only strings starting with / are interpreted as commands, which helps an agent understand what content is expected.

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

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

The description names a specific verb (validates), a clear resource (Python automation script), and a precise scope (runs outside the game, across three named axes). It also explicitly distinguishes itself from validate_script, making it easy for an agent to select the right 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 gives an explicit when-not-to-use rule: behavior pack scripts should go to validate_script instead, because Python does not run inside a pack. It also explains why the embedded command check matters and clarifies that only strings starting with / are treated as commands, giving practical selection and invocation 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 readOnlyHint=true, the description discloses what the tool actually does (compiles against the real type definitions for that version), what it returns (diagnostics with line, column, TS error code and message, plus the module versions it compiled against), and which failure class it catches. No contradiction with 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?

Three sentences, each earning its place: what it does, what it returns, and when to use it. The highest-value distinguishing fact (real TypeScript compiler against actual type definitions) is front-loaded, with zero filler.

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

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

For a tool with no output schema, the description compensates well by naming the diagnostics fields (line, column, TS error code, message) and the module-versions report. Parameters are fully documented in the schema. It falls short of a 5 only because the response envelope isn't specified and there's no mention of compile cost/time traits.

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 baseline is 3 per the rubric. The description adds a modest bit of cross-parameter meaning by tying version to 'the actual type definitions for that version' and referencing module versions, but the schema already documents code, channel fallback, and version constraints thoroughly.

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

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

The description names a specific verb (compiles), resource (behavior pack script against the actual @minecraft/server type definitions), and mechanism (real TypeScript compiler). The 'Catch non-existent APIs and calls removed in later versions' clause clearly distinguishes this from sibling validation tools like validate_json, validate_python, and validate_command, which check syntax rather than type-check script against versioned API definitions.

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?

'Catch non-existent APIs and calls removed in later versions here' gives an explicit trigger condition, and the note that Bedrock scripting APIs written from memory are the most common source of silent failures provides a concrete when-to-use scenario. It stops short of a 5 because it doesn't name alternatives or give when-not-to-use exclusions.

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