Generate 3D meshes in Godot from vertex data with ArrayMesh, defining positions, normals, UVs, and triangle indices for custom geometry.
Generate meshes via ArrayMesh from vertex data
| Name | Required | Description | Default |
|---|---|---|---|
| uvs | No | UV coordinates [[u,v],...] | |
| name | No | Node name | |
| indices | No | Triangle indices [i0,i1,i2,...] | |
| normals | No | Vertex normals [[x,y,z],...] | |
| vertices | Yes | Vertex positions [[x,y,z],...] | |
| parentPath | Yes | Parent node path |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full disclosure burden. It reveals only the core generation action and does not say whether a node is created in the scene tree, what the returned result is, or how invalid index/UV data is handled.
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 concise sentence front-loads the action, resource, and method without filler. It earns its place despite being terse.
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 mesh-creation tool with no output schema and no annotations, the description is too thin. It omits the scene-tree effect implied by parentPath, what the tool returns, and how it should be chosen among the many mesh/scene sibling tools, so an agent has only partial context for invoking 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?
All six parameters already have schema descriptions, so the baseline is 3. The phrase 'from vertex data' adds little beyond the schema's vertices parameter, and the description does not explain relationships among vertices, indices, normals, and uvs.
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 concrete action ('generate meshes'), the engine mechanism ('ArrayMesh'), and the data source ('vertex data'). It is clear but does not explicitly differentiate from sibling tools like game_multimesh or game_mesh_instance, so it stops short of a top score.
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 guidance is given on when to choose this tool over sibling geometry tools such as game_multimesh, game_mesh_instance, or game_csg. There are no prerequisites or exclusions; the implied use case is only that vertex data is needed, which is already visible from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.