SketchUp MCP untuk Windows

Overview Schema Source Related Servers Discussions Admin

eval_ruby

Execute Ruby code inside SketchUp to create or edit 3D geometry and return the last expression as a string.

Instructions

Run Ruby code inside SketchUp (full SketchUp Ruby API) and return the value of the last expression as a string.

This is the main modelling tool. Rules that avoid the usual mistakes:
- Lengths are inches internally. Write 3.m, 150.mm, 15.cm, never bare numbers.
- model = Sketchup.active_model; wrap edits in
  model.start_operation('name', true) ... model.commit_operation.
- A face on the ground plane (z=0) has its normal pointing down, so
  pushpull(+h) would go underground: face.reverse! if face.normal.z < 0.
- Create each element with SU_MCP.element(name, kind, parent) { |ents| ... }
  so it gets the standard tag and material; parent = SU_MCP.container('Rumah A').
- End with SU_MCP.audit_model; the work is done only when it says AUDIT OK.
- Make the last expression a short summary string (counts, bounds) so you
  can verify the result. Calls time out after about 15 seconds, so split
  very large jobs into several calls.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`code`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Oct 1, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and discloses useful behavioral traits: it returns the last expression as a string, warns of a ~15-second timeout, and requires transaction wrapping and an audit check. It does not explicitly warn that arbitrary Ruby code executes with full model privileges and can be destructive, which is a notable omission for a code-execution tool.

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 front-loaded with the core action and return format, followed by a structured bullet list of rules. It is somewhat long but every bullet addresses a real failure mode, so the length is largely earned.

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 high-complexity code-execution tool, the description covers return value, timeout, required transaction pattern, geometric pitfalls, element creation, and completion criteria. With an output schema present, return values need not be explained further, though error behavior and security implications are omitted.

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

Parameters4/5

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

The single 'code' parameter has 0% schema description coverage, so the description must compensate, and it does so richly: units must be written as 3.m, 150.mm, etc., edits must be wrapped in operations, and the last expression should be a short summary string. This adds substantial domain-specific meaning beyond the bare string schema.

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?

States a specific verb, resource, and environment: 'Run Ruby code inside SketchUp (full SketchUp Ruby API)' and return the last expression. It explicitly identifies itself as 'the main modelling tool,' distinguishing its role from siblings like build_floor_plan or create_component.

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

Usage Guidelines4/5

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

It gives clear usage context by calling itself the main modelling tool and provides several required patterns such as wrapping edits in start_operation/commit_operation and ending with SU_MCP.audit_model. However, it does not explicitly compare itself to sibling tools or state when an agent should prefer a specialized tool over raw Ruby.

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

Deploy Server