Skip to main content
Glama
yonnayy

SketchUp MCP untuk Windows

by yonnayy

export_scene

Export the current SketchUp model to PNG, JPG, SKP, OBJ, DAE, or STL. Use PNG format to get a screenshot for visual inspection.

Instructions

Export the current model. format: png, jpg, skp, obj, dae, stl.

The file is written to the sketchup_exports folder inside %TEMP% and its full path is
returned in content[0].text. Use format='png' to get a screenshot of the
current view so you can check the model visually.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoskp

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.5/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 does disclose meaningful behavior: the file lands in sketchup_exports inside %TEMP% and the full path is returned in content[0].text. It omits overwrite behavior (does exporting to an existing name replace it?) and any permission constraints, keeping it from a 5.

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?

Two short sentences (plus the format list), front-loaded with the action, then the output location, then the png hint. Every clause carries distinct information and nothing is padded.

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

Completeness5/5

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

An output schema exists, yet the description still pinpoints where the return path appears (content[0].text), and it covers format selection and file destination. For a single-parameter export tool this is fully sufficient.

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?

Schema coverage is 0% and the schema defines format only as a bare string, so the description's list of valid values (png, jpg, skp, obj, dae, stl) is a real addition the schema lacks. It doesn't state the default skp that the schema declares, but the enum enumeration is the key information an agent needs.

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 and resource ('Export the current model') and enumerates the accepted formats, which lets an agent distinguish it immediately from the sibling manipulation tools (transform_component, set_material, etc.). No sibling does exporting, so the scope is unambiguous.

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?

Gives a concrete use case for one format ('Use format='png' to get a screenshot of the current view so you can check the model visually'), which tells the agent when PNG is the right choice. It stops short of naming when-not to export or which sibling to prefer for in-SketchUp inspection.

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