Validate resource pack textures for size limits over 2MB, lowercase naming without spaces, and pack icon dimensions to catch packaging issues before release.
Validate textures in a resource pack for size limits (>2MB), naming conventions (lowercase, no spaces), and pack icon size.
| Name | Required | Description | Default |
|---|---|---|---|
| packPath | Yes | Path to the resource pack directory |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the concrete validation criteria (2MB limit, lowercase/no-spaces naming, icon size), which is real added context. However, it never says whether the tool only reads or can report/fail, nor how violations are surfaced, so an agent cannot predict behavior past the check list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence in which every clause (size, naming, icon) corresponds to a real check performed. There is no filler or 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 is complete on what is checked but silent on the result contract: with no output schema and no annotations, an agent cannot tell whether this returns a boolean, a violation list, or throws on failure. Adding that one detail would make the definition self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, packPath, and the schema documents it at 100% coverage as 'Path to the resource pack directory'. The description adds no format, relative-vs-absolute, or existence requirements beyond the schema, so 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?
States a specific verb (validate) and resource (textures in a resource pack) and even enumerates the three rules checked: size limit, naming conventions, pack icon size. It is clearly distinct from list/compare/search siblings, though it does not explicitly contrast with the closest sibling validate_rp_structure.
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 statement of when to call this versus validate_rp_structure or the other validation/inspection tools, and no prerequisites such as requiring an extracted pack directory. Usage is only inferable from the tool name and the enumerated checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.