Skip to main content
Glama

CodeCraft

by io.github.TanerTalas

Validate a whole pack

review_pack
Read-only

Validates every file of a behavior or resource pack in one call: it applies the right validator to each file (JSON schema, script compilation, command syntax) and then runs the checks a schema structurally cannot do — identifier consistency, filename rules, manifest module type, texture keys, component names, Molang queries and loot/trade table paths. This is the LAST step before handing a pack to the user, and it is both faster and broader than validating each file separately.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesThe files in the pack. Include the manifest — several checks depend on it.
versionNoGame version under data/, e.g. 1.26.40 or 1.26.40.5. Defaults to the newest available version. Marketing numbers (26.40) are rejected.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All CodeCraft toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool addresses a distinct stage or artifact: feasibility, schema/version/identifier lookup, and separate validation for commands, JSON, Python, TypeScript, plus a whole-pack review. The descriptions explicitly tell the agent when to call each, so boundaries are clear.

Naming Consistency5/5

All nine tool names follow a consistent verb_noun snake_case pattern, with get_/lookup_ for information retrieval and validate_/review_ for checking. The validate_* family is uniform and the remaining names are still predictable from their action.

Tool Count5/5

Nine tools is well-scoped for a Minecraft Bedrock pack assistance server: three lookup tools and six validation/review tools. Each covers a distinct artifact or stage without redundancy.

Completeness5/5

The set covers the full authoring workflow from feasibility and version/schema/identifier lookup to per-file validation and final pack-wide review. There are no obvious dead ends or missing lifecycle operations for the server's stated purpose.

Resources