create_chop_node

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states "Create a new CHOP node," implying mutation but offering no details about potential errors, behavior on duplicate names, whether the tool validates chop_type, or what happens if parent_path is invalid. This leaves the agent with insufficient knowledge of side effects or failure modes.

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 well-structured: a one-sentence purpose, a focused usage note, and an args list. The list of CHOP node types is a bit lengthy but serves the usage guidance by illustrating alternatives. Overall, no redundant sentences are present, and the key information is front-loaded.

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 three-parameter creation tool with no output schema or annotations, the description covers the purpose, pre-call validation, and parameter meanings. However, it does not explain what the tool returns (e.g., node path) or error behavior, which is important for an agent to confirm successful creation. The pre-call guidance helps but the description remains incomplete for a mutation tool.

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 description must compensate. It does provide concise definitions for all three parameters: parent_path (parent network path), chop_type (CHOP node type to create), and name (node name override). This adds meaning beyond the raw schema, but the definitions are terse and lack constraints, examples, or format details, so compensation is only partial.

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 specific verb and resource: "Create a new CHOP node." This clearly differentiates it from siblings like create_cop_node, create_lop_node, and the generic create_node, because the CHOP context is explicit. The additional list of dedicated CHOP node types reinforces the tool's scope without ambiguity.

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 explicitly instructs the agent to call list_node_types(context='Chop', filter='<keyword>') before using this tool to verify the correct node type, and warns that many dedicated nodes already exist that may do what is needed. This provides clear when-to-use and when-not-to-use guidance, effectively steering the agent away from unnecessary creation.

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