Enables two-way communication with SketchUp, allowing component creation, manipulation, and transformation; material application; scene inspection; selection handling; and execution of Ruby code for 3D modeling and scene management.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SketchupMCP create a simple house model with a roof and windows"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SketchupMCP connects Sketchup to Claude AI through the Model Context Protocol (MCP), allowing Claude to directly interact with and control Sketchup. This integration enables prompt-assisted 3D modeling, scene creation, and manipulation in Sketchup.
Big Shoutout to Blender MCP for the inspiration and structure.
Two-way communication: Connect Claude AI to Sketchup through a TCP socket connection
Component manipulation: Create, modify, delete, and transform components in Sketchup
Material control: Apply and modify materials and colors
Scene inspection: Get detailed information about the current Sketchup scene
Selection handling: Get and manipulate selected components
Ruby code evaluation: Execute arbitrary Ruby code directly in SketchUp for advanced operations
Related MCP server: RhinoMCP
The system consists of two main components:
Sketchup Extension: A Sketchup extension that creates a TCP server within Sketchup to receive and execute commands
MCP Server (sketchup_mcp/server.py): A Python server that implements the Model Context Protocol and connects to the Sketchup extension
We're using uv so you'll need to brew install uv
Download or build the latest .rbz file
In Sketchup, go to Window > Extension Manager
Click "Install Extension" and select the downloaded .rbz file
Restart Sketchup
In Sketchup, go to Extensions > SketchupMCP > Start Server
The server will start on the default port (9876)
Make sure the MCP server is running in your terminal
Configure Claude to use the MCP server by adding the following to your Claude configuration:
"mcpServers": {
"sketchup": {
"command": "uvx",
"args": [
"sketchup-mcp"
]
}
}This will pull the latest from PyPI
Once connected, Claude can interact with Sketchup using the following capabilities:
get_scene_info - Gets information about the current Sketchup scene
get_selected_components - Gets information about currently selected components
create_component - Create a new component with specified parameters
delete_component - Remove a component from the scene
transform_component - Move, rotate, or scale a component
set_material - Apply materials to components
export_scene - Export the current scene to various formats
eval_ruby - Execute arbitrary Ruby code in SketchUp for advanced operations
Here are some examples of what you can ask Claude to do:
"Create a simple house model with a roof and windows"
"Select all components and get their information"
"Make the selected component red"
"Move the selected component 10 units up"
"Export the current scene as a 3D model"
"Create a complex arts and crafts cabinet using Ruby code"
Connection issues: Make sure both the Sketchup extension server and the MCP server are running
Command failures: Check the Ruby Console in Sketchup for error messages
Timeout errors: Try simplifying your requests or breaking them into smaller steps
The system uses a simple JSON-based protocol over TCP sockets:
Commands are sent as JSON objects with a type and optional params
Responses are JSON objects with a status and result or message
Contributions are welcome! Please feel free to submit a Pull Request.
MIT
Average 2.9/5 across 10 of 10 tools scored.
Most tools have distinct purposes, such as creating specific joint types or managing components. However, create_component and transform_component could be slightly ambiguous if an agent needs to modify a component's geometry versus its transformation, but descriptions clarify their roles.
All tool names follow a consistent verb_noun pattern, using snake_case throughout. Examples include create_component, delete_component, and export_scene, making them predictable and easy to parse.
With 10 tools, this server is well-scoped for Sketchup automation, covering joint creation, component management, scene export, and Ruby evaluation. Each tool serves a clear purpose without redundancy.
The toolset provides good coverage for basic Sketchup operations, including CRUD for components and specific joint types. Minor gaps exist, such as no tool for listing all components or updating joint properties, but core workflows are supported.
Create a new component in Sketchup
| Name | Required | Description | Default |
|---|---|---|---|
| dimensions | No | ||
| position | No | ||
| type | No | cube |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the tool creates something but doesn't mention whether this requires specific permissions, what happens on success/failure, whether the component becomes part of the current model, or any side effects. For a creation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single sentence that states exactly what the tool does without any wasted words. It's appropriately sized for a basic creation tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description doesn't need to explain return values. However, for a creation tool with 3 parameters and no annotations, the description is too minimal - it doesn't provide enough context about how the tool behaves, what the parameters mean, or when to use it versus sibling creation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description provides no information about what 'dimensions', 'position', or 'type' mean or how they should be used. The schema shows 'type' has a default of 'cube' but the description doesn't explain this or what other types might be available. The description fails to compensate for the complete lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new component') and the target system ('in Sketchup'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'create_dovetail', 'create_finger_joint', or 'create_mortise_tenon' which likely create specific types of components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus other creation tools, or any exclusions. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a dovetail joint between two components
| Name | Required | Description | Default |
|---|---|---|---|
| angle | No | ||
| depth | No | ||
| height | No | ||
| num_tails | No | ||
| offset_x | No | ||
| offset_y | No | ||
| offset_z | No | ||
| pin_id | Yes | ||
| tail_id | Yes | ||
| width | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the tool creates a joint, implying a write/mutation operation, but doesn't disclose any behavioral traits such as permissions needed, whether it modifies existing components, error conditions, or what the output contains. This leaves significant gaps for an agent to understand how to use it safely and effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste—it directly states the tool's purpose without fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no annotations, but an output schema exists), the description is minimal. It states the basic purpose but lacks guidance, parameter explanations, and behavioral context. The presence of an output schema means return values are documented elsewhere, but the description doesn't compensate for other gaps, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters, but it adds no meaning beyond the schema. It doesn't clarify what 'tail_id' and 'pin_id' refer to, the units for measurements like 'angle' or 'depth', or the purpose of offsets. With 10 parameters and no schema descriptions, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create a dovetail joint') and the target ('between two components'), which is specific and actionable. However, it doesn't distinguish this tool from similar sibling tools like 'create_finger_joint' or 'create_mortise_tenon', which would require mentioning unique characteristics of dovetail joints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_finger_joint' or 'create_mortise_tenon', nor does it mention prerequisites, context, or exclusions. It's a bare statement of function without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a finger joint (box joint) between two components
| Name | Required | Description | Default |
|---|---|---|---|
| board1_id | Yes | ||
| board2_id | Yes | ||
| depth | No | ||
| height | No | ||
| num_fingers | No | ||
| offset_x | No | ||
| offset_y | No | ||
| offset_z | No | ||
| width | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states this is a creation tool, implying mutation, but doesn't address critical aspects like whether this operation is destructive to existing components, requires specific permissions, has side effects, or how it handles errors. The description is too minimal for a tool with 9 parameters and no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately front-loaded with the core action and resource, making it easy to parse quickly despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, creation operation) and complete lack of annotations, the description is insufficient. While an output schema exists (which reduces the need to describe return values), the description doesn't address behavioral aspects, parameter meanings, or usage context that would help an agent understand when and how to invoke this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 9 parameters have descriptions in the schema. The tool description doesn't mention any parameters, failing to compensate for this gap. It doesn't explain what board1_id/board2_id refer to, what units depth/height/width use, or how offsets affect joint placement, leaving parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a finger joint (box joint) between two components'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling woodworking tools like create_dovetail or create_mortise_tenon, which would require specifying what makes finger joints distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_dovetail or create_mortise_tenon. It also lacks information about prerequisites (e.g., whether components must exist) or typical use cases, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a mortise and tenon joint between two components
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| height | No | ||
| mortise_id | Yes | ||
| offset_x | No | ||
| offset_y | No | ||
| offset_z | No | ||
| tenon_id | Yes | ||
| width | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create' which implies a write/mutation operation, but it doesn't describe what happens upon creation (e.g., whether it modifies existing components, requires specific permissions, or has side effects). This leaves significant gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, 0% schema coverage, no annotations, but with an output schema), the description is incomplete. It doesn't address parameter meanings, usage context, or behavioral details, relying solely on the output schema for return values. For a mutation tool with many undocumented parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The tool description doesn't mention any parameters, failing to compensate for this gap. It doesn't explain what 'mortise_id' or 'tenon_id' refer to, or the purpose of dimensions like 'depth' and offsets, leaving parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the specific resource ('a mortise and tenon joint between two components'), which is more specific than just restating the tool name. However, it doesn't explicitly differentiate from sibling joint creation tools like 'create_dovetail' or 'create_finger_joint' beyond naming the joint type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_dovetail' or 'create_finger_joint', nor does it mention prerequisites such as needing existing components or specific contexts. It simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a component by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the destructive action ('Delete') but lacks critical details: whether deletion is permanent, if it requires specific permissions, what happens to dependent elements, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations, 0% schema description coverage, and sibling tools present, the description is inadequate. It doesn't address safety, permissions, or error handling, and while an output schema exists, the description provides no context on what 'delete' entails operationally. The agent lacks critical information to use this tool responsibly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds minimal parameter context by specifying 'by ID'. It doesn't explain the ID format, source, or validation rules. With only one parameter, the baseline is higher, but the description doesn't fully compensate for the schema's lack of descriptions, leaving the agent to guess ID semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a component by ID'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'create_component' or 'transform_component' beyond the obvious verb difference, but the verb+resource combination is specific enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing component), consequences (e.g., irreversible deletion), or relationships to sibling tools like 'create_component' or 'get_selection'. The agent must infer usage purely from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate arbitrary Ruby code in Sketchup
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool evaluates Ruby code but doesn't describe safety implications (e.g., potential for destructive operations, security risks, or performance impacts), execution context (e.g., sandboxed or full access), or error handling. This is inadequate for a tool that executes arbitrary code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (executing arbitrary code) and lack of annotations, the description is insufficient. It doesn't address critical aspects like safety, permissions, or output format, even though an output schema exists. This leaves significant gaps for an agent to understand how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It mentions 'Ruby code' but doesn't elaborate on the parameter 'code' beyond that, such as expected syntax, examples, or constraints. This adds minimal value over the schema, which only indicates a required string parameter named 'code'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Evaluate arbitrary Ruby code in Sketchup'. It specifies the action ('evaluate') and the resource ('Ruby code'), and indicates the context ('in Sketchup'). However, it doesn't differentiate from siblings like 'create_component' or 'export_scene', which are more specific operations rather than general code execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, limitations, or scenarios where other tools might be more appropriate, such as using 'create_component' for specific modeling tasks instead of writing custom Ruby code. This leaves the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the current scene
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | skp |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the action ('Export') but doesn't reveal critical traits: whether this creates files (potentially destructive), requires specific permissions, has rate limits, or what the output entails. The description is minimal and lacks behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just four words—and front-loaded with the core action. There's no wasted language or unnecessary elaboration, making it efficient for quick comprehension, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (export operation with 1 parameter), no annotations, and an output schema present (which likely covers return values), the description is minimally adequate. It states the purpose but lacks details on behavior, usage, or parameters. The output schema reduces the need to explain returns, but more context would improve completeness for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage (no schema descriptions), and the tool description doesn't mention parameters at all. However, since there's only one optional parameter ('format'), the baseline is high. The description doesn't add semantic value, but the low parameter count mitigates the impact, warranting a score above the minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export the current scene' clearly states the action (export) and resource (current scene), but it's somewhat vague about what 'export' entails (file creation, format conversion, etc.) and doesn't differentiate from sibling tools like 'create_component' or 'get_selection'. It's not tautological but lacks specificity about the export operation's nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an open scene), exclusions, or related tools. It's a standalone statement with no contextual usage information, leaving the agent to infer based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currently selected components
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the tool retrieves selections but doesn't explain what 'currently selected components' means in this context (e.g., in a UI, from a scene), whether it's read-only (implied by 'Get'), or what happens if nothing is selected. This leaves significant gaps for a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core functionality. It's appropriately sized for a simple tool with no parameters, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and siblings that interact with components, it lacks context on behavior (e.g., error handling, selection scope) and usage guidelines, leaving some gaps despite the structured fields covering inputs and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could briefly note the lack of inputs. A baseline of 4 is applied for zero-parameter tools, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the target ('currently selected components'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'transform_component' or 'delete_component' that might also operate on selections, leaving room for minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether components must be selected first), exclusions, or how it relates to siblings like 'transform_component' that might manipulate selections, offering only basic functional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set material for a component
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| material | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Set material' implies a mutation operation, but it doesn't disclose behavioral traits such as whether it overwrites existing material, requires specific permissions, has side effects, or returns confirmation. This is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded and appropriately sized for the tool's apparent simplicity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and low complexity (2 parameters, no nested objects), the description is minimally adequate. However, as a mutation tool with no annotations and 0% schema coverage, it should provide more context on behavior and parameters to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'material' and implies 'component' via 'id', but doesn't explain what 'id' refers to (e.g., component identifier) or what 'material' entails (e.g., string format, allowed values). With two undocumented parameters, the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Set') and target ('material for a component'), which provides a basic purpose. However, it lacks specificity about what 'material' means in this context (e.g., physical properties, appearance, type) and doesn't distinguish from siblings like 'transform_component' or 'create_component' that might also affect components. It's vague but not tautological or missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., component must exist), exclusions, or compare to sibling tools like 'create_component' or 'transform_component'. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transform a component's position, rotation, or scale
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| position | No | ||
| rotation | No | ||
| scale | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the tool performs a 'transform' operation, implying mutation, but doesn't clarify if this is destructive (e.g., overwrites existing values), requires specific permissions, has side effects, or how it interacts with other tools. The mention of 'position, rotation, or scale' hints at 3D transformations but lacks details on coordinate systems or units.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('transform a component') and key parameters. There is no wasted text, making it easy to parse quickly. It appropriately sized for conveying the basic purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with 4 parameters, 0% schema coverage, and no annotations, the description is incomplete. It lacks crucial details like error conditions, output format (though an output schema exists, the description doesn't reference it), and how transformations affect the component in context with siblings (e.g., 'get_selection'). This leaves significant gaps for an agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It lists the parameters ('position, rotation, or scale') but doesn't explain their semantics beyond naming them. For example, it doesn't specify what 'id' refers to, the format of arrays (e.g., 3D vectors), default behaviors when parameters are null, or constraints. This adds minimal value beyond the schema's property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('transform') and the resource ('a component's position, rotation, or scale'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from potential sibling operations like 'create_component' or 'delete_component', which would require more specific context about what transformation entails versus creation or deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the component must exist), exclusions (e.g., cannot transform deleted components), or comparisons to siblings like 'create_component' or 'set_material'. This leaves the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect Claude AI to UluP Spaces via MCP — create projects, nodes, and tasks with OAuth 2.0.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Connect AI agents to Replynodes over the Model Context Protocol.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mhyrr/sketchup-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
