game_multimesh

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

With no annotations provided, the description must carry the full behavioral burden, but it only states the resource and purpose. It does not disclose whether 'create' adds a node to the scene tree, whether 'set_instance' mutates an existing multimesh, what 'get_info' returns, or any side effects like overwriting existing configuration. This is a significant transparency gap for a mutation-capable 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?

The description is a single short sentence with no filler or repetition, making it easy to scan. It is concise to the point of being terse, but it does every word count is minimal and focused.

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 8 parameters, a nested transform object, no annotations, no output schema, and a large sibling set, the description is too thin. It leaves the action semantics, parameter combinations, and return behavior of get_info undocumented. An agent would need to infer too much from the schema alone to invoke this tool reliably.

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 covers 100% of the parameters with descriptions, so the baseline is 3. The tool description adds no extra semantic detail beyond the schema—for example, it does not explain how the transform object relates to a multimesh instance, what units are expected, or how count and index interact with the actions.

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-resource pair: 'Create/configure MultiMeshInstance3D for instancing', identifying both the node type and its intended purpose. It is not a tautology and provides enough specificity to distinguish the tool's domain from generic scene tools, though it does not explicitly name sibling 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?

The phrase 'for instancing' implies the intended use case, but the description offers no comparison with alternative tools like game_mesh_instance or game_spawn_node, and no guidance on when to choose this tool over them. It also does not clarify when to use each action value (create, set_instance, get_info), leaving usage partially implied.

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