max_create_object

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

With no annotations, the description carries the full behavioral burden and does not state whether the operation is undoable, what happens if 'name' collides with an existing node, whether the object is created in the active scene or origin, or what the call returns. The only behavioral nugget is that 'name' is ignored for import, which is useful but thin for a mutation 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 purpose is front-loaded in the first sentence and the rest is a compact, tabular mapping of kinds to size keys with zero filler. Every line contributes callable information.

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 4-parameter mutation tool with no annotations and no output schema, the description covers the inputs well but leaves the agent without any statement of return value, error modes, or effect on existing scene state. Adequate to invoke, incomplete for predicting outcomes.

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, and it largely does: it defines the kind enumeration, the per-kind size keys (box{w,l,h}, torus{r,r2}, etc.), the [x,y,z] format of pos, and the import payload shape. Remaining gaps are defaults for pos/params when omitted and behavior when params keys mismatch the kind.

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?

States a specific verb and resource ('Create a primitive, or import geometry from disk') and enumerates the kind values, so the scope is unambiguous. No sibling in the list performs creation, so the tool is trivially distinguishable from max_delete_objects, max_query_objects, and max_set_property.

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?

There is no guidance on when to use this versus alternatives such as max_file_io for disk operations, nor any prerequisite (scene open, selection state, units). The note about 'import' is a parameter format hint rather than a when-to-use rule, so the agent must infer all routing decisions.

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