Skip to main content
Glama
HoldMyBeer-gg

blend-ai

by HoldMyBeer-gg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

create_object

Create a primitive object in the scene.

Instructions

Create a primitive object in the scene.

Args: type: Primitive type. One of: CUBE, SPHERE, UV_SPHERE, ICO_SPHERE, CYLINDER, CONE, TORUS, PLANE, CIRCLE, MONKEY, EMPTY. name: Optional name for the object. Auto-generated if empty. location: XYZ position as a 3-element list/tuple. Defaults to origin. rotation: XYZ Euler rotation in radians as a 3-element list/tuple. scale: XYZ scale as a 3-element list/tuple. Defaults to (1,1,1). Use positive values; a negative component on a symmetric primitive is applied as the equivalent rotation and noted in the result.

Returns: Dict with the created object's name, type, location, dimensions, and world-space bounds (min and max corner). Place the next part from the bounds: a nose cone sits at bounds.max z plus half its own height.

Input Schema

NameRequiredDescriptionDefault
nameNo
typeYes
scaleNo
locationNo
rotationNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.7.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / type / enum
      Added value: +[
+  "CIRCLE",
+  "CONE",
+  "CUBE",
+  "CYLINDER",
+  "EMPTY",
+  "ICO_SPHERE",
+  "MONKEY",
+  "PLANE",
+  "SPHERE",
+  "TORUS",
+  "UV_SPHERE"
+]
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It does disclose two genuinely non-obvious behaviors: an empty name is auto-generated, and negative scale components are applied as an equivalent rotation and reported in the result. It says nothing about undo, error handling, or whether the object is selected/active after creation, which matters for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The structure is front-loaded and scannable: purpose sentence, args, returns. Every line in the Args block adds information. The closing example about a nose cone is slightly decorative but justifies itself by showing how to consume the returned bounds.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter creation tool with an output schema, the description covers inputs, defaults, the return payload, and a usage note for the returned bounds. The only gap is post-creation side effects (selection state, whether the object becomes active), which an agent composing a scene may need.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates: it enumerates the valid enum values, states defaults for name, location, and scale, gives the unit for rotation (radians), and constrains scale to positive values with an explanation of what happens otherwise. This is meaningfully more than the bare schema conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb and resource ('Create a primitive object in the scene') and qualifies it with 'primitive', which separates it from mesh-generating siblings like create_polygon_prism or create_threaded_shaft. It does not name any sibling directly, so the differentiation is implicit rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: create a primitive when you need a base shape in the scene. There is no explicit statement of when to prefer this over create_polygon_prism, create_text, or execute_blender_code, and no prerequisites are listed. The bounds hint ('Place the next part from the bounds') is a useful procedural guideline even if it is about follow-up rather than tool selection.

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

Deploy Server

Other Tools