Skip to main content
Glama
using76
by using76

bulc_create_room

Destructive

Create rectangular rooms in building designs by specifying position, dimensions, and floor level for architectural planning and layout development.

Instructions

Create a new rectangular room at the specified position. All coordinates are in centimeters (cm). Use bulc_get_spatial_context first if you need to position relative to existing rooms. Example: To create a 5m x 4m room, use width=500, depth=400.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xYesX coordinate of bottom-left corner in centimeters
yYesY coordinate of bottom-left corner in centimeters
widthYesRoom width in centimeters (X direction). 1m = 100cm
depthYesRoom depth in centimeters (Y direction). 1m = 100cm
nameNoRoom name for display (e.g., 'Living Room', '거실')
levelNoFloor level index. 0 = ground floor, 1 = first floor. Default: current level

Implementation Reference

  • Core handler logic for the 'bulc_create_room' tool. Validates input using CreateRoomSchema and sends a 'create_room' command to the BULC client via sendCommand.
    case "bulc_create_room": {
      const validated = CreateRoomSchema.parse(args);
      result = await client.sendCommand({
        action: "create_room",
        params: validated,
      });
      break;
    }
  • Zod validation schema used in the handler to parse and validate parameters for creating a rectangular room (x, y, width, depth, optional name and level).
    const CreateRoomSchema = z.object({
      x: z.number(),
      y: z.number(),
      width: z.number().positive(),
      depth: z.number().positive(),
      name: z.string().optional(),
      level: z.number().int().optional(),
    });
  • src/tools/room.ts:8-49 (registration)
    Tool registration object defining name, description, input schema, and annotations for 'bulc_create_room' in the roomTools array, exposed to MCP ListTools.
    {
      name: "bulc_create_room",
      description:
        "Create a new rectangular room at the specified position. " +
        "All coordinates are in centimeters (cm). " +
        "Use bulc_get_spatial_context first if you need to position relative to existing rooms. " +
        "Example: To create a 5m x 4m room, use width=500, depth=400.",
      inputSchema: {
        type: "object" as const,
        properties: {
          x: {
            type: "number",
            description: "X coordinate of bottom-left corner in centimeters",
          },
          y: {
            type: "number",
            description: "Y coordinate of bottom-left corner in centimeters",
          },
          width: {
            type: "number",
            description: "Room width in centimeters (X direction). 1m = 100cm",
          },
          depth: {
            type: "number",
            description: "Room depth in centimeters (Y direction). 1m = 100cm",
          },
          name: {
            type: "string",
            description: "Room name for display (e.g., 'Living Room', '거실')",
          },
          level: {
            type: "integer",
            description: "Floor level index. 0 = ground floor, 1 = first floor. Default: current level",
          },
        },
        required: ["x", "y", "width", "depth"],
      },
      annotations: {
        readOnlyHint: false,
        destructiveHint: true,
      },
    },
  • src/index.ts:68-71 (registration)
    Routing logic in main MCP CallTool handler that dispatches 'bulc_*_room' tool calls to the specific handleRoomTool function.
    // Room tools
    if (name.startsWith("bulc_") && name.includes("room")) {
      return await handleRoomTool(name, safeArgs);
    }
  • src/index.ts:40-42 (registration)
    Includes roomTools (containing bulc_create_room) into the complete allTools list provided to MCP ListToolsRequestHandler.
    const allTools = [
      ...contextTools,      // 8 tools: spatial context, home info, levels, undo/redo, save
      ...roomTools,         // 5 tools: create, create_polygon, list, modify, delete
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, indicating this is a write operation that modifies state. The description adds valuable context beyond annotations by specifying the coordinate system ('All coordinates are in centimeters'), providing a unit conversion example, and mentioning the rectangular shape constraint. However, it doesn't describe what 'destructive' means in this context (e.g., whether it overwrites existing rooms at that position).

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

Conciseness5/5

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

The description is perfectly front-loaded with the core purpose, followed by critical context (coordinate system, prerequisite tool), and ends with a concrete example. Every sentence earns its place: the first states what the tool does, the second provides essential behavioral context, and the third illustrates usage with a realistic scenario.

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 creation tool with destructive annotations and no output schema, the description provides good context: it explains the coordinate system, suggests a positioning workflow, and gives an example. However, it doesn't clarify what 'destructive' means here (e.g., whether creation fails if overlapping existing rooms) or describe the creation result format, leaving some behavioral questions unanswered.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds minimal value beyond the schema: it reinforces the centimeter unit system and provides a width/depth example, but doesn't explain parameter relationships or constraints not already in the schema descriptions. This meets the baseline for high schema coverage.

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

Purpose5/5

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

The description clearly states the specific action ('Create a new rectangular room') and resource ('room'), distinguishing it from siblings like bulc_create_room_polygon (polygon-shaped) and bulc_create_walls_rectangle (walls only). It specifies the rectangular shape and coordinate system, providing precise differentiation.

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

Usage Guidelines5/5

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

The description explicitly provides when-to-use guidance by stating 'Use bulc_get_spatial_context first if you need to position relative to existing rooms.' This names a specific alternative tool for positioning context and establishes a clear prerequisite workflow for relative positioning scenarios.

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/using76/BULC_MCP'

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