Skip to main content
Glama
truman-t3

KeyShot MCP

by truman-t3
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Render an Agent-visible preview

keyshot_preview_render
Read-onlyIdempotent

Render a bounded PNG preview from an existing KeyShot scene and return it as MCP image content; optionally save a copy.

Instructions

Render a bounded PNG preview from an existing scene and return it directly as MCP image content. Temporary previews are deleted after embedding; an optional safe output path preserves a copy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
widthNoPreview width in pixels. Defaults to 960; allowed range is 64 to 1920.
cameraNoOptional saved camera name to activate for the preview. Omit to use the scene's active camera.
heightNoPreview height in pixels. Defaults to 540; allowed range is 64 to 1080.
samplesNoPreview render samples. Defaults to 16 unless maxTimeSeconds is provided; maximum is 64.
scenePathYesAbsolute path to an existing KeyShot scene file to open. Input files may be outside the configured output directory.
outputPathNoOptional .png destination inside KEYSHOT_OUTPUT_DIR. Existing files are never overwritten. When omitted, a temporary preview is embedded and deleted.
maxTimeSecondsNoTime-based preview limit in seconds. Replaces the default sample mode and cannot be combined with an explicit samples value; maximum is 60.

Output Schema

TableJSON 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. 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"
+]
  2. Addedv0.10.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real lifecycle context beyond them — temporary previews are deleted after embedding, and an optional safe output path preserves a copy. It stops short of naming the 'never overwrites existing files' rule that lives in the schema.

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 dense sentences with no filler, front-loading what the tool produces before the lifecycle caveat. Every clause earns its place.

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?

An output schema exists, so return values need no explanation, and annotations plus schema cover safety and parameters. The only gap is prerequisites (e.g. scene must exist, KeyShot running), which an agent must infer from the required scenePath.

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 all seven parameters are already documented with defaults, ranges and constraints; the description only echoes outputPath preservation at a high level. Baseline 3 is appropriate since the schema does the heavy lifting.

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+resource ('Render a bounded PNG preview from an existing scene') and the delivery mechanism ('return it directly as MCP image content'). The word 'preview' plus 'bounded' separates it from full renders like keyshot_render, though it never names those siblings explicitly.

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 implied through 'preview' and the temporary-vs-persisted output choice, but the description never states when to prefer this over keyshot_render, keyshot_product_render, or keyshot_render_queue. No explicit when/when-not guidance is given.

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