Skip to main content
Glama
Sign In
Goxel-MCP

Goxel-MCP

by yberudev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Preview

goxel_render_preview
Read-only

Render a PNG preview of a voxel scene to visually check your model and optionally save it, using either an internal orthographic renderer or the live Goxel editor view.

Instructions

Render a PNG image of the scene to check the model visually, and optionally save it. The internal renderer is orthographic and needs no OpenGL; engine='goxel' asks the running Goxel editor (live mode) to render its current view.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "goxel_render_preview"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeNo
viewNoiso
engineNointernal = built-in orthographic renderer; goxel = the Goxel editor itself (live mode) renders its current viewinternal
save_toNoAlso save the image as a .png file in the workspace
overwriteNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior4/5

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

Adds real context beyond readOnlyHint=true: the internal renderer is orthographic and requires no OpenGL, and engine='goxel' depends on a running editor in live mode — a genuine prerequisite disclosure. It is silent on the return payload (file path vs. image data) and on what happens when 'goxel' is requested outside live mode; also worth noting the optional save/overwrite path does write to the workspace despite readOnlyHint=true, though the description discloses this rather than hiding it.

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?

Two dense but front-loaded sentences: the action comes first, the engine caveat second. No wasted preamble; only minor cost is packing the engine distinction into the same breath as the core action.

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

Completeness3/5

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

For a 5-parameter tool with 40% schema coverage and no output schema, the description omits the most decision-relevant facts an agent needs: what is returned (path, image bytes, dimensions) and failure behavior when engine='goxel' without an active session. The renderer/no-OpenGL note is helpful, but the definition is only minimally sufficient.

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?

Schema description coverage is only 40%, so the description needs to compensate — and it does not. It restates the engine semantics that are already in the schema, and leaves size, view (which iso/front/top angle means), and overwrite undocumented in both places; 'optionally save it' adds nothing to save_to's own description.

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

Purpose4/5

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

States a specific verb and resource ('Render a PNG image of the scene') plus the visual-check intent, which is more than a restatement of the name 'Preview'. It does not differentiate itself from plausible siblings such as goxel_export or goxel_open_in_app, so an agent must infer that this is the snapshot tool and those are file-level alternatives.

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 gives an implied use case ('to check the model visually') and a conditional choice between engines (internal vs. running Goxel editor in live mode). It never says when to prefer this over goxel_export or goxel_open_in_app, nor that engine='goxel' fails outside live mode — the agent has to infer that.

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

Deploy Server

Other Tools