Goxel-MCP

Overview Schema Source Related Servers Discussions Admin

Save project (.gox)

goxel_save_scene

Saves the current voxel scene in native .gox format, using the scene's existing file when no path is given and backing up earlier versions. Use overwrite=true to replace other existing files.

Instructions

Save the scene in Goxel's native format (.gox). Without 'path', the current file of the scene is used. Existing files are not replaced without overwrite=true (except the scene's own file); the previous version is always copied to .goxel-mcp/backups/. In live mode Goxel itself writes the file.

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_save_scene"
  }
}

Input Schema

Name	Required	Description
`path`	No	.gox destination relative to the workspace (for example output/car/car.gox)
`validate`	No	Validate the saved file (with Goxel's own parser when available)
`overwrite`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 25, 2026

TDQS

A3.9/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 well: it discloses overwrite protection, that prior versions are copied to .goxel-mcp/backups/, and that live mode delegates writing to Goxel. It doesn't describe the return/confirmation behavior, a minor remaining gap.

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?

Four tight sentences, front-loaded with the core action, then default behavior, then safety semantics. No redundancy.

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 mutation tool with no annotations and no output schema, it covers the critical safety and mode concerns well. A brief note on what a successful save returns or how validation failures surface would make it complete.

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?

At 67% schema coverage, the description adds real meaning: it explains the default behavior when 'path' is omitted and the exact overwrite semantics including the scene's-own-file exception. Only the 'validate' flag is left entirely to the schema.

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 ('Save the scene') plus the target format (.gox), which clearly distinguishes it from goxel_export in spirit. It doesn't explicitly name the sibling, but the format qualifier makes the intent unambiguous.

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?

Explains the path-omitted case and overwrite condition, giving useful conditional guidance. It never states when to prefer this over goxel_export or goxel_validate_scene, so routing between siblings is left to inference.

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

Deploy Server