Skip to main content
Glama

place_ifc_object

Position IFC building model elements at specific coordinates with optional rotation to construct or modify architectural designs.

Instructions

Place an IFC object at a specified location with optional rotation.

This tool allows you to create and position IFC elements in the model.
The object is placed using the specified IFC type and positioned
at the given coordinates with optional rotation around the Z axis.

Args:
    type_name: Name of the IFC element type to place (must exist in the model)
    x: X-coordinate in model space
    y: Y-coordinate in model space
    z: Z-coordinate in model space
    rotation: Rotation angle in degrees around the Z axis (default: 0)
    
Returns:
    A message with the result of the placement operation

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
type_nameYes
xYes
yYes
zYes
rotationNo
ctxNo

Implementation Reference

  • The main handler function for the 'place_ifc_object' MCP tool. It connects to Blender via socket, sends the placement parameters (type_name, location [x,y,z], rotation) using the 'place_ifc_object' command, and processes the response into a user-friendly message including the new object's Blender name and Global ID if successful.
    @mcp.tool()
    def place_ifc_object(
        type_name: str, 
        x: float, 
        y: float, 
        z: float, 
        rotation: float = 0.0,
        ctx: Context| None = None
    ) -> str:
        """
        Place an IFC object at a specified location with optional rotation.
        
        This tool allows you to create and position IFC elements in the model.
        The object is placed using the specified IFC type and positioned
        at the given coordinates with optional rotation around the Z axis.
        
        Args:
            type_name: Name of the IFC element type to place (must exist in the model)
            x: X-coordinate in model space
            y: Y-coordinate in model space
            z: Z-coordinate in model space
            rotation: Rotation angle in degrees around the Z axis (default: 0)
            
        Returns:
            A message with the result of the placement operation
        """
        try:
            # Get Blender connection
            blender = get_blender_connection()
            
            # Send command to place the object
            result = blender.send_command("place_ifc_object", {
                "type_name": type_name,
                "location": [x, y, z],
                "rotation": rotation
            })
            
            # Check for errors
            if isinstance(result, dict) and "error" in result:
                return f"Error placing object: {result['error']}"
            
            # Format success message
            if isinstance(result, dict) and result.get("success"):
                return (f"Successfully placed '{type_name}' object at ({x}, {y}, {z}) "
                       f"with {rotation}° rotation.\nObject name: {result.get('blender_name')}, "
                       f"Global ID: {result.get('global_id')}")
            
            # Return the raw result as string if it's not a success or error dict
            return f"Placement result: {json.dumps(result, indent=2)}"
        
        except Exception as e:
            logger.error(f"Error placing IFC object: {str(e)}")
            return f"Error placing IFC object: {str(e)}"
Behavior2/5

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 describes a write operation ('create and position IFC elements'), which implies mutation, but doesn't address critical behavioral aspects like permissions required, whether the operation is reversible, potential side effects on the model, or error handling. The return value description ('A message with the result') is vague about success/failure indicators.

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 description is well-structured and appropriately sized. It begins with a clear purpose statement, followed by elaboration, then provides a formatted parameter section with clear documentation. While efficient, the 'Returns' section could be more specific about what the message contains, but overall the structure is logical and front-loaded.

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

Completeness3/5

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

Given this is a mutation tool with no annotations and no output schema, the description is moderately complete. It adequately explains the core functionality and parameters but lacks important contextual information about behavioral traits, error conditions, and the structure of return values. The description covers the 'what' but insufficiently addresses the 'how' and 'what happens after' aspects.

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?

The description provides excellent parameter semantics beyond the input schema. With 0% schema description coverage, the description fully documents all 4 required parameters (type_name, x, y, z) and the optional rotation parameter, explaining what each represents, their data types, and default values. The 'ctx' parameter is not mentioned, but this appears to be an internal context parameter, so the description effectively covers all user-facing parameters.

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 description clearly states the tool's purpose: 'Place an IFC object at a specified location with optional rotation.' It specifies the verb ('place'), resource ('IFC object'), and key actions (positioning with coordinates and rotation). However, it doesn't explicitly distinguish this from potential sibling tools like 'get_selected_ifc_entities' or 'list_ifc_entities', which are read operations versus this write operation.

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

Usage Guidelines2/5

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

The description provides minimal usage guidance. It states that the object type 'must exist in the model,' which is a prerequisite, but offers no explicit guidance on when to use this tool versus alternatives. There's no mention of when not to use it or what other tools might be more appropriate for related tasks.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JotaDeRodriguez/Bonsai_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server