Skip to main content
Glama
zinin

sketchup-mcp2

by zinin

boolean_operation

Apply boolean operations (union, difference, intersection) to two 3D solids for merging or cutting geometry.

Instructions

Perform a boolean operation (union/difference/intersection) on two solids.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
target_idYes
tool_idYes
operationNounion
delete_originalsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The 'boolean_operation' tool handler function (async). Uses @mcp.tool() decorator for registration. Accepts target_id, tool_id, operation (union/difference/intersection), and delete_originals. Delegates to _call() which sends the command to the SketchUp Ruby backend.
    @mcp.tool()
    async def boolean_operation(
        ctx: Context,
        target_id: Annotated[str, Field(min_length=1)],
        tool_id: Annotated[str, Field(min_length=1)],
        operation: Literal["union", "difference", "intersection"] = "union",
        delete_originals: bool = False,
    ) -> str:
        """Perform a boolean operation (union/difference/intersection) on two solids."""
        return await _call(
            ctx,
            "boolean_operation",
            target_id=target_id,
            tool_id=tool_id,
            operation=operation,
            delete_originals=delete_originals,
        )
  • Inline schema/type definitions for boolean_operation: target_id and tool_id are strings (min_length=1), operation is Literal['union','difference','intersection'] defaulting to 'union', delete_originals is bool defaulting to False.
    @mcp.tool()
    async def boolean_operation(
        ctx: Context,
        target_id: Annotated[str, Field(min_length=1)],
        tool_id: Annotated[str, Field(min_length=1)],
        operation: Literal["union", "difference", "intersection"] = "union",
        delete_originals: bool = False,
    ) -> str:
        """Perform a boolean operation (union/difference/intersection) on two solids."""
        return await _call(
            ctx,
            "boolean_operation",
            target_id=target_id,
            tool_id=tool_id,
            operation=operation,
            delete_originals=delete_originals,
        )
  • Registration via the @mcp.tool() decorator on line 228. The mcp instance is imported from sketchup_mcp.app (line 14), and tools.py is side-effect imported in app.py line 51 to register all tools.
    @mcp.tool()
    async def boolean_operation(
        ctx: Context,
        target_id: Annotated[str, Field(min_length=1)],
        tool_id: Annotated[str, Field(min_length=1)],
        operation: Literal["union", "difference", "intersection"] = "union",
        delete_originals: bool = False,
    ) -> str:
        """Perform a boolean operation (union/difference/intersection) on two solids."""
        return await _call(
            ctx,
            "boolean_operation",
            target_id=target_id,
            tool_id=tool_id,
            operation=operation,
            delete_originals=delete_originals,
        )
  • The FastMCP application instance 'mcp' that the @mcp.tool() decorator registers boolean_operation on. Created with FastMCP('SketchupMCP', ...).
    mcp = FastMCP(
        "SketchupMCP",
        instructions="Sketchup integration through the Model Context Protocol",
        lifespan=server_lifespan,
    )
    
    # Side-effect import: registers tool handlers on `mcp`. Must come AFTER `mcp`
    # is constructed (tools.py does `from sketchup_mcp.app import mcp`). Required
    # here so MCP hosts loading the published `[project.entry-points.mcp]` get a
    # FastMCP with tools registered, not an empty instance.
  • The _call() helper function that dispatches tool calls to the SketchUp Ruby backend via WebSocket connection. All tools (including boolean_operation) delegate to this function.
    async def _call(ctx: Context, name: str, **kwargs) -> str:
        """Dispatch a tool call to SketchUp and shape the response for Claude.
    
        - Connection errors → human-readable string, server keeps running.
        - SketchUpError → ``format_error`` string.
        - Successful MCP-shaped result ({content: [{text: "..."}]}) → just the text.
        - Any other dict result → ``json.dumps``.
        """
        try:
            sketchup = await get_connection()
        except ConnectionError as e:
            return f"SketchUp not running or extension not started: {e}"
        try:
            result = await sketchup.send_command(name, kwargs)
        except ConnectionError as e:
            # Cached connection was stale and reconnect inside send_command failed:
            # `_connect_or_raise` re-raises OSError as ConnectionError before the
            # send/recv try-block, so it escapes past the SketchUpError handler.
            return f"SketchUp not running or extension not started: {e}"
        except SketchUpError as e:
            return format_error(e, debug=config.LOG_LEVEL == "DEBUG")
        content = result.get("content") if isinstance(result, dict) else None
        if (
            isinstance(content, list)
            and content
            and isinstance(content[0], dict)
            and "text" in content[0]
        ):
            return content[0]["text"]
        return json.dumps(result)
Behavior3/5

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

No annotations are present, so the description carries the full burden. It mentions 'on two solids' but doesn't clarify whether the operation is destructive, where the result is stored, or requirements like solids must intersect. The parameter schema has an enum, but the description doesn't elaborate on behavior beyond the list.

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 a single short sentence that is front-loaded with key information. It is concise, but given the tool's complexity (4 parameters, multiple operations), slightly more context would be helpful without being verbose.

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

Completeness2/5

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

Considering the moderate complexity (4 params, boolean operation) and no annotations, the description is incomplete. It doesn't explain that target_id and tool_id reference solid components, fails to describe the result or output schema (which exists), and omits prerequisites like overlapping geometry.

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

Parameters2/5

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

With 0% schema description coverage, the description must explain parameters. It only mentions 'two solids' without clarifying target_id vs tool_id, doesn't describe the operation parameter beyond listing, and ignores delete_originals. The schema names are somewhat self-explanatory, but the description adds minimal value.

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 verb 'perform' on the resource 'boolean operation' and lists the three operation types (union/difference/intersection). It distinguishes this tool from siblings like chamfer_edge or fillet_edge by focusing on solid boolean operations.

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?

The description implies use for combining or subtracting solids but lacks explicit guidance on when to use vs. alternatives, when not to use, or prerequisites. Sibling tools exist but no contrasts are provided.

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/zinin/sketchup-mcp2'

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