Create deterministic environmental variants like rain, night, or earthquake for multiple asset library IDs in one request. Set item IDs, variants, and output prefix to produce consistent pixel art variations.
Generate deterministic environmental variants for multiple asset library ids with one compact request.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| frames | No | ||
| delay_ms | No | ||
| item_ids | Yes | ||
| variants | Yes | ||
| output_prefix | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description alone must disclose behavior. It reveals one important trait, determinism, and that variants are environmental, but says nothing about side effects, whether files or artifacts are created, output destination/output_prefix behavior, or limits. For a generation-style tool this is a material 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?
One sentence with no filler; the main function and key traits (deterministic, multiple IDs, compact request) are front-loaded. It earns its place, though the brevity is bought at the cost of completeness scored elsewhere.
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, and with 0% schema description coverage, a single high-level sentence is insufficient for a 6-parameter tool. Missing return/output behavior, parameter meaning, and sibling-selection guidance leave an agent guessing before 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 0%, so the text must compensate for six undocumented parameters. It only loosely maps 'multiple asset library ids' to item_ids and 'environmental variants' to variants; it does not explain seed, frames, delay_ms, output_prefix, or allowed variant values, so most parameters remain opaque.
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?
Uses a specific verb ('generate') and resource ('environmental variants for multiple asset library ids'), and the phrase 'one compact request' signals a batching capability. It is clear enough to avoid obvious confusion with single-effect generators, but it does not explicitly name sibling distinctions such as generate_environment_pack or generate_source_variant_pack.
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 implies a batching use case ('multiple asset library ids', 'one compact request'), but it never states when to prefer this tool over single-variant generators or generate_environment_pack, nor what conditions make it inappropriate. No exclusions or alternative routing are given, so the agent must infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.