Skip to main content
Glama

Save a KeyShot scene copy

keyshot_save_scene
Destructive

Open an existing scene and save a copy to a requested path inside the configured safe output directory.

Instructions

Open an existing scene and save a copy to a requested path inside the configured safe output directory.

Input Schema

NameRequiredDescriptionDefault
overwriteNoAllow replacing an existing output file. Defaults to false. Input files can never be replaced, even when true.
scenePathYesAbsolute path to an existing KeyShot scene file to open. Input files may be outside the configured output directory.
outputScenePathYesDestination path for a saved scene copy, never an input file. Existing files are rejected unless overwrite=true. Must stay inside KEYSHOT_OUTPUT_DIR unless external outputs are explicitly enabled.

Output Schema

NameRequiredDescriptionDefault
okYesTrue when the requested operation completed successfully.
dataYesOperation-specific structured result data, or null when unavailable.
errorYesHuman-readable failure reason, or null after success.
warningsYesNon-fatal conditions the user or agent should review.
errorCodeNoStable error category for common failures.
outputFilesYesAbsolute paths of images or scene files created by the operation.
suggestionsNoActionable recovery steps for the user or agent.
keyshotStdoutTailYesTruncated tail of KeyShot headless output for diagnostics.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.13.5
    • changedInput schema / properties / outputScenePath / description
      Previous value: -"Destination path for the saved KeyShot scene. The path must stay inside KEYSHOT_OUTPUT_DIR unless external outputs are explicitly enabled."New value: +"Destination path for a saved scene copy, never an input file. Existing files are rejected unless overwrite=true. Must stay inside KEYSHOT_OUTPUT_DIR unless external outputs are explicitly enabled."
    • addedInput schema / properties / overwrite
      Added value: +{
      +  "description": "Allow replacing an existing output file. Defaults to false. Input files can never be replaced, even when true.",
      +  "type": "boolean"
      +}
  2. Changed4 schema fields changedv0.13.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / required
      Previous value: -[
      -  "ok",
      -  "outputFiles",
      -  "warnings",
      -  "keyshotStdoutTail",
      -  "error"
      -]New value: +[
      +  "ok",
      +  "data",
      +  "outputFiles",
      +  "warnings",
      +  "keyshotStdoutTail",
      +  "error"
      +]
  3. Changed3 schema fields changedv0.10.0
    • addedInput schema / properties / outputScenePath / description
      Added value: +"Destination path for the saved KeyShot scene. The path must stay inside KEYSHOT_OUTPUT_DIR unless external outputs are explicitly enabled."
    • addedInput schema / properties / scenePath / description
      Added value: +"Absolute path to an existing KeyShot scene file to open. Input files may be outside the configured output directory."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "data": {
      +      "anyOf": [
      +        {},
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "description": "Operation-specific structured result data, or null when unavailable."
      +    },
      +    "error": {
      +      "description": "Human-readable failure reason, or null after success.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "errorCode": {
      +      "description": "Stable error category for common failures.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "keyshotStdoutTail": {
      +      "description": "Truncated tail of KeyShot headless output for diagnostics.",
      +      "type": "string"
      +    },
      +    "ok": {
      +      "description": "True when the requested operation completed successfully.",
      +      "type": "boolean"
      +    },
      +    "outputFiles": {
      +      "description": "Absolute paths of images or scene files created by the operation.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "suggestions": {
      +      "description": "Actionable recovery steps for the user or agent.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "warnings": {
      +      "description": "Non-fatal conditions the user or agent should review.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "ok",
      +    "outputFiles",
      +    "warnings",
      +    "keyshotStdoutTail",
      +    "error"
      +  ],
      +  "type": "object"
      +}
  4. First observedv0.2.1

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, consistent with the copy/overwrite behavior. The description adds the safe-output-directory constraint, but the more consequential behavioral detail (overwrite semantics, input files never replaced) lives in the schema rather than the description.

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?

A single lean sentence with the action and target front-loaded and no filler. It is efficient, though its brevity contributes to the missing alternative-routing guidance.

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?

With annotations, an output schema, and full schema coverage, the description need only frame the core action, which it does: open a scene and save a copy into the safe output directory. The safe-directory framing is the key contextual point and it is present.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents scenePath, outputScenePath, and overwrite. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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?

The description states specific verbs (open, save a copy) and the resource (an existing scene, written to a requested path), which is far better than tautology. It does not, however, differentiate from the related sibling keyshot_sync_saved_scene or keyshot_inspect_scene, so an agent must infer the distinction from the name alone.

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?

Usage is only implied: 'open an existing scene and save a copy' suggests the copy workflow, but it never says when to choose this tool over keyshot_sync_saved_scene or other scene siblings, nor any prerequisites or exclusions. No explicit alternatives are named.

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