Add a geometry node to a Blender node group by type, with optional inputs, properties, and placement.
添加几何节点。type 可省略前缀（MeshCube = GeometryNodeMeshCube；FunctionNode* 也可）。
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| type | Yes | ||
| inputs | No | ||
| location | No | ||
| node_group | Yes | ||
| properties | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, and the description does not disclose side effects, required context, permissions, or side effects on the node tree. As a mutation tool, this lack of transparency is a significant 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?
The description is brief and to the point, but it is also minimal to the point of being sparse. It contains one useful tip but omits other essential context, so it is not optimally concise for a tool with six parameters.
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?
Given the complexity of geometry node operations and the presence of many related tools, the description is incomplete. It fails to mention required parameter relationships, expected input formats, or any interaction with the node tree, leaving the agent to infer most behavior.
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 the 'type' parameter is partially explained via the prefix rule. The other five parameters (name, inputs, location, node_group, properties) are left entirely to schema names, offering no semantic guidance. Schema coverage is zero, so the description adds minimal value.
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 clearly states the action ('add') and the resource ('geometry node'), making the primary purpose unambiguous. However, it doesn't differentiate this from other add operations (e.g., add_shader_node, add_modifier), though the resource type is specific enough.
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 provided on when to use this tool versus alternatives like create_geometry_nodes, build_geometry_node_tree, or link_geometry_nodes. The only additional hint about type prefix is not a usage guideline but a parameter tip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.