KeyShot MCP

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

Annotations declare destructiveHint=true and non-idempotent, and the description partially supports this by disclosing that the edited scene is saved as a side effect. It does not, however, say what the destructive aspect is, whether the input scene is touched, or that re-applying is not idempotent — the schema's overwrite note is doing that work.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with the write-and-save side effect front-loaded alongside the action. No filler, no repetition of schema detail.

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

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

An output schema exists and the schema documents parameters thoroughly, so the remaining burden is behavioral: whether unsaved scene changes are discarded, and how this fits the list-presets workflow. Those are absent, which matters for a tool flagged destructive.

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

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

Schema description coverage is 100%, so parameter meaning is already fully documented, including overwrite semantics, path constraints, and the cameraName default. The description only adds the notion of 'standard-view or absolute' preset types, which is minor added value over the schema.

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

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

States a specific verb and resource: create or update a saved camera from a preset, then save the scene. The 'from a preset' qualifier distinguishes it from the plain keyshot_set_camera sibling, though that distinction is left implicit rather than named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use, when-not, or alternative is given. An agent must infer from the name that this is the preset-driven path versus keyshot_set_camera or the list/inspect workflow; neither the preset-listing prerequisite nor the choice against siblings appears in the description.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false; the description adds the key behavioral fact that the call does not just mutate but also writes a saved scene, which explains the destructive flag. It stops short of saying whether the input scene file is left untouched (the schema says so, the description does not) or how overwrite conflicts are surfaced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action, names both material sources, identifies the target, and closes with the write side effect. No filler and nothing an agent must read past to find the core behavior.

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

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

With 100% schema coverage and an output schema, the description only needs to carry the action and side effect, which it does. The remaining gap is routing: for a tool sitting next to keyshot_apply_material_preset, an agent gets no help choosing between them.

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

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

Schema description coverage is 100%, so the either/or pairings (materialName vs materialPath, objectName vs objectPath) and the overwrite semantics are already fully documented in the schema. The description only says a material may come from a library or a local file, which restates rather than extends the schema.

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

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

States a specific verb and resource ("Apply a KeyShot library material or local material file to a specific object") plus the resulting side effect ("then save the edited scene"). It distinguishes library/local-file materials from presets implicitly, but never names keyshot_apply_material_preset, so the differentiation from that closest sibling is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance, and keyshot_apply_material_preset (the obvious alternative for preset-based material application) is never mentioned. The only usage signal is the implicit framing that this operates on an existing scene file and an existing object.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false. The description's 'save a new scene' adds useful context that the source scene is written to a separate output rather than mutated in place, but it does not disclose the overwrite hazard on the destination, permission/auth requirements, or what happens when preset resolution fails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence covering all three phases of the operation with zero filler. Nothing repeats the tool name or title verbatim.

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

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

With a rich 6-parameter schema, full description coverage, an output schema, and annotations carrying the safety profile, minimal prose is defensible. Still, for a destructive multi-step operation the description omits any mention that the input scene is never replaced and that an existing output requires overwrite=true, both of which are decision-relevant for an agent.

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

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

Schema description coverage is 100%, so the schema already explains objectName vs objectPath, the overwrite semantics, and the output-directory constraint. The description contributes nothing about parameters beyond the schema; baseline 3 applies.

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

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

The description gives a concrete three-step verb chain: resolve a configured preset, apply it to one scene object, save a new scene. That is specific and distinguishes it implicitly from keyshot_apply_material (raw material) and keyshot_apply_camera_preset, but it never names those siblings, so an agent must infer the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to choose this over keyshot_apply_material or keyshot_apply_camera_preset, and no prerequisites (such as needing a preset name from keyshot_list_material_presets, which only appears in the schema). Usage is implied by the verb chain rather than stated.

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

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

Annotations already flag destructiveHint=true, non-idempotent, non-read-only, so the description should explain *how* it's destructive (overwriting existing files). It only implies writing into a directory and never mentions overwrite behavior, side effects, or that it is a heavy/long operation, adding little beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single efficient sentence front-loads the verb and output. It is appropriately short, though slightly thin given the tool's complexity.

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

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

With an output schema present, return values needn't be explained, and the schema covers parameters fully. However, for a destructive batch render tool with many configurable options, the description omits overwrite/destructive behavior and alternative-tool routing, leaving notable gaps.

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

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

Schema description coverage is 100%, so all 10 parameters (cameras, outputDir, qualityPreset, samples, maxTimeSeconds, etc.) are fully documented in the schema. The description adds no parameter semantics beyond what the schema provides, so baseline 3 applies.

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

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

States a clear verb (render) and resource (explicit list of saved cameras) plus the destination (output directory). It distinguishes itself somewhat from siblings like keyshot_render_all_cameras (all vs. explicit list), though it does not name that distinction explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'explicit list' implies you must already know camera names, and the schema notes to call keyshot_list_cameras first. But the description itself gives no when-to-use vs. keyshot_render_all_cameras or keyshot_render guidance.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false; the description adds that a new scene is written, reinforcing the write outcome. However, it does not warn about overwriting an existing output file or about the KEYSHOT_OUTPUT_DIR containment rule, both of which affect whether a call is safe. The description does not contradict the annotations, but it adds only modest context to a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action and sequences the outcome in the order the agent cares about. No filler and no repetition of schema content.

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

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

With annotations, a fully documented 8-parameter schema, and an output schema, the remaining burden on the description is low. It covers the import-to-save flow but omits what the returned scene contains and any failure behavior for unsupported formats. The environment is well specified, so it is sufficient for calling the tool correctly.

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

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

Schema description coverage is 100%, so all 8 parameters are already documented, including overwrite rules and output path constraints. The description's 'apply requested composition options' only gestures vaguely at the boolean flags (snapToGround, centerGeometry, adjustEnvironment, adjustCameraLookAt) without adding meaning. This meets the baseline for high-coverage schemas.

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

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

States a specific verb and resource ('Import a supported local model') plus the three-stage outcome: base scene, composition options, save a new scene. This separates it from keyshot_save_scene, which saves without import. It stops short of naming a sibling, so it lands at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'into an empty or base scene' implies the preparation context, but there is no explicit when-to-use or when-not-to-use guidance. Nothing tells the agent how this differs from keyshot_sync_saved_scene or keyshot_save_scene in a workflow. Usage 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.

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's 'read-only' merely restates that, but it does add useful behavioral detail about what gets returned (including external references), which is more than the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the action and scope, with the return contents enumerated compactly. Nothing is wasted or buried.

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

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

With a rich annotation set, a fully documented single parameter, and an output schema present, the description need not explain return values or safety. The only shortfall is the absence of routing guidance relative to sibling inspection tools.

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

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

Schema coverage is 100% and the single parameter's description is thorough, including that input files may lie outside the configured output directory. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description pairs a specific verb ('Open ... read-only') with the resource ('a KeyShot scene') and enumerates the returned payload (metadata, objects, cameras, material assignments, model sets, external references). This is clearly distinct from siblings like keyshot_list_cameras or keyshot_status, though it never explicitly names those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by 'read-only' — an agent can infer this is for non-mutating inspection. There is no statement of when to prefer this over keyshot_list_cameras, keyshot_status, or keyshot_sync_saved_scene, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world. The description adds real value beyond them by stating it reads a pre-configured preset JSON file and requires no KeyShot session — a meaningful operational precondition. It stops short of describing failure modes (malformed/missing JSON) or how 'valid' is determined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler: the action, the source, the output, and the offline constraint are all packed in without redundancy.

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

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

With an output schema present and rich annotations, the description need not explain return values, and it covers the read-only, offline nature of the call. The remaining ambiguity is the source/configuration of the preset JSON, which leaves a minor gap for an agent deciding whether results will be current.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no inputs are needed, though it does not explain where the 'configured camera preset JSON' comes from or whether it is user-supplied configuration.

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

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

The description states a specific verb and resource — reads the configured camera preset JSON and returns valid standard or absolute camera presets — which is distinct from siblings like keyshot_list_cameras and keyshot_apply_camera_preset. It is clear, though it never explicitly names which sibling to prefer when an agent wants live camera data rather than stored presets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is a discovery step before keyshot_apply_camera_preset, and the 'without opening KeyShot' clause hints at the offline precondition. There is no explicit when-to-use or when-not-to-use guidance versus keyshot_list_cameras or keyshot_inspect_scene.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description's 'without saving changes' merely restates that, and it adds no other behavioral detail (no note that the scene file is opened, no output/ordering info).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no padding. The clause 'without saving changes' is slightly redundant against the annotations, costing it the top score.

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

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

For a single-parameter read-only list tool with a full output schema and complete annotations, the description supplies what it does and when to use it. Minor gap: it does not mention that the scene is opened as a side effect of passing scenePath.

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

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

Only one parameter with 100% schema description coverage, so the baseline is 4. The description adds nothing about scenePath, but the schema already explains it as an absolute path to an existing scene file.

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

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

States a specific verb and resource ('Return saved camera names') and implicitly distinguishes scene cameras from the sibling keyshot_list_camera_presets by saying 'saved camera names'. Clear to an agent, though it never explicitly names the preset-list sibling as the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete when-to-use condition: 'Use this before selected-camera rendering when names are unknown.' That is actionable context, but there is no when-not guidance and no mention of the camera-preset alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the source of truth (local preset JSON config) and that no KeyShot instance is required, which the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. The verb comes first and the offline constraint is packed into the same clause, so every word earns its place.

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

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

With an output schema present, the description need not document return values, and it still summarizes them ('valid preset names and material sources'). For a zero-parameter read tool this is essentially complete; only an explicit alternative-tool pointer is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly does not invent or omit any parameter detail.

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

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

States a specific verb ('Read') and resource ('configured local material preset JSON') with the output scope ('valid preset names and material sources'). This clearly separates it from the mutation-oriented siblings like keyshot_apply_material_preset, though it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'...without opening KeyShot' implies the usage context (offline, no live app needed), which is a real hint. However, it gives no explicit when-to-use vs the apply_material_preset or other list_* siblings, so the agent must infer the routing.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=false, lowering the bar. The description adds that the run is headless and that a scene copy is saved, but it does not disclose what the destructive behavior actually overwrites despite the 'overwrite' option – a notable gap for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that enumerates the workflow stages in order and wastes nothing. Given the complexity of 32 parameters, this is admirably tight.

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

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 not be explained, and the schema fully covers the 32 parameters. The description adequately conveys the workflow scope, though it could say more about when this tool supersedes the granular siblings.

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

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

Schema description coverage is 100%, so the schema already documents all 32 parameters, including enums and cross-parameter constraints. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

The description names a specific composite verb set (open/import, assign materials, configure camera and environment, save, render) and the resource (a product workflow). It clearly positions itself as the one-shot orchestrator versus the granular siblings, though it never explicitly states that contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'in one headless process' implies batch/automated usage and contrasts implicitly with calling the individual sibling tools, but there is no explicit when-to-use / when-not-to-use guidance or named alternative. Usage is only inferable.

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

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

Annotations already declare destructiveHint=true and non-idempotent writes, so the description should add file-safety context, but it says nothing about how output paths are resolved, that existing files require overwrite, or that a scene is opened as a side effect. It only restates that an image file is produced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted words. It is efficient, though arguably under-specified for a ten-parameter destructive tool rather than genuinely complete.

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

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

An output schema exists and the parameter schema is fully documented, so the essentials for calling are present. However, for a destructive, non-idempotent render with interacting options, one sentence leaves the mutation and file-overwrite behavior entirely to the schema.

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

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

Schema description coverage is 100% and the schema itself explains presets, enum formats, the samples vs maxTimeSeconds conflict, and overwrite rules. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (render) and resource (camera/view of a scene) plus the output (image file). It implies a single-view render, which distinguishes it softly from keyshot_render_all_cameras and keyshot_batch_render, but 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this instead of keyshot_preview_render, keyshot_product_render, keyshot_batch_render, or keyshot_render_queue. The agent must infer the choice purely from the name and the one-line description.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the mutation/safety profile is covered. The description still adds non-obvious behavior beyond that: collision-safe file naming, a single headless process, and per-camera results. It does not explain the overwrite semantics tied to the destructive hint, which is the one notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence, front-loaded with the verb and resource, that carries the batch scope, execution model, and output behavior without filler. Nothing is redundant with the title or schema.

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

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 (per-camera results) need not be re-explained, and annotations cover the safety profile. What remains thin is routing guidance among the many sibling render tools and the destructive-overwrite relationship, so the definition is adequate but not complete for a 10-parameter tool.

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

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

Schema description coverage is 100%, so the schema already documents width, height, samples, maxTimeSeconds, overwrite, continueOnError, and the rest. The description adds no parameter-level semantics (no default format, no preset/sample interaction), so it sits at the baseline for fully documented schemas.

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

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

States a specific verb (render) and resource (every saved camera in the scene), scoping it as a whole-scene operation. This distinguishes it from keyshot_render (single render), keyshot_list_cameras (discovery only), and keyshot_batch_render without needing to open any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'render each view in one headless process' implies the batch/campaign use case, but there is no explicit when-to-use vs. keyshot_render, keyshot_preview_render, or keyshot_batch_render, and no stated prerequisites or exclusions. Usage is left to inference from the name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and non-read-only, so the write profile is covered structurally. The description contributes the real behavioral trait beyond that — strict sequential execution and the reason (license and output-file contention) — but says nothing about whether the call blocks until the whole queue finishes, what partial results look like, or that a failure aborts subsequent jobs by default.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the action and the reason, zero redundancy. Nothing to trim.

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

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 the nested job schema is fully self-documenting. The remaining gap is operational rather than structural: for a destructive, license-consuming render queue the description never says whether invocation is blocking or returns job handles, which an agent needs before deciding to queue a heavy render.

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

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

Schema description coverage is 100% and every nested job field (scenePath, camera, qualityPreset, samples vs maxTimeSeconds, overwrite, outputPath) is documented in the schema. The description adds no parameter-level meaning beyond the array being an ordered sequential queue, so baseline 3 applies.

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

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

States a concrete verb and resource (render independent scene/camera jobs as a sequential queue) and explains the mechanism, which is more than the title restates. It does not, however, name the siblings it must be distinguished from — keyshot_batch_render, keyshot_render_all_cameras, and keyshot_render all overlap on 'render multiple things', and the agent is left to infer which one takes an arbitrary heterogeneous job list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The stated rationale ('so KeyShot processes do not compete for a license or output files') implies the usage context — several independent renders queued up rather than one. But there is no explicit when-not guidance and no named alternative, which matters in a sibling set containing three other render tools.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds useful context by noting it 'save[s] the edited scene,' clarifying the write side effect, but it does not itself surface the overwrite/path-constraint behavior (which 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the action and its inputs front-loaded and no wasted text. It could be marginally stronger by adding one routing clause, but nothing is superfluous.

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

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

With 10 params, an output schema, and annotations present, the description covers the core action, but for a destructive, non-idempotent scene-writing tool it omits when-to-use guidance and any pointer to overwrite/path semantics. Adequate minimum-viable coverage with clear gaps.

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

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

Schema description coverage is 100%, so every parameter and its constraints (mutual exclusion of fieldOfView/focalLength, up requires position+lookAt, overwrite defaults) are already documented. The description only names the input dimensions and adds no syntax or constraint detail beyond the schema — baseline 3 is appropriate.

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

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

States a specific verb pair (create or update) and resource (named camera), and lists the geometric inputs used. It is clear what the tool does, though it never names a sibling (e.g. keyshot_apply_camera_preset or keyshot_list_cameras) to sharpen the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: 'create or update a named camera' hints at when it applies but gives no explicit when/when-not or guidance on choosing it over keyshot_apply_camera_preset or preset-based camera workflows. The agent must infer the selection criteria.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the agent knows this is a non-idempotent write. The description adds only that brightness and rotation are optional. It omits important behavioral context: that the input scene is never modified and that output goes to a separate destination copy — a key reassurance given destructiveHint=true — and says nothing about overwrite behavior beyond what the schema states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with three clauses and no filler. It is efficient, though packing environment selection, brightness, rotation, and saving into a single clause makes the save behavior easy to skim past.

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

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 not be explained. However, for a 7-parameter destructive write tool, the description omits that the source scene stays untouched, that outputScenePath must live inside the output directory, and the overwrite interaction. Adequate but not complete for the risk profile.

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

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

Schema description coverage is 100%, so parameter meaning is already fully carried by structured data. The description reinforces only the name-or-path choice and the optional brightness/rotation, adding no format, range, or constraint detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource (select an environment, by library name or local file) plus the follow-on mutations of brightness/rotation and saving. It is distinguishable from siblings like keyshot_apply_material or keyshot_set_camera. The trailing 'save the edited scene' overlaps with keyshot_save_scene without clarifying the difference, which keeps it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'By library name or local file' implies the two selection modes, but the description never states they are mutually exclusive (the schema does) nor when to prefer this tool over keyshot_save_scene despite both saving a scene. No explicit when-not guidance or prerequisites are given. Usage is inferable from the sentence but not spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious context beyond those: it performs a 'minimal KeyShot headless startup' yet does so 'without modifying a user scene', which tells the agent a process launch occurs as part of a supposedly read-only check.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the verb first and the checked areas enumerated compactly. No filler, no restatement of the title.

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

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 the description fully covers what is probed and confirms the non-destructive guarantee. The only gap is the absence of guidance on when this check should be triggered relative to the render siblings.

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

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

The tool takes zero parameters, so the schema imposes no semantic burden and the baseline of 4 applies. Nothing in the description conflicts with the empty parameter object.

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

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

States a specific verb (diagnose) and enumerates the exact resources checked: installation, output access, presets, bridge files, and headless startup. This clearly separates it from every sibling, which are render/scene/material/camera operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The diagnostic framing implies this is a pre-flight/health-check tool, but the description never states when to run it (before renders? on failure?) or names any alternative. Usage must be inferred from the name and scope.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is partly covered. The description adds useful behavioral context (change detection, collision-safe naming, Agent-visible preview), but it never explains what is actually written or mutated on disk or where KEYSHOT_OUTPUT_DIR fits, which is exactly the gap the destructive hint raises.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both front-loaded and free of filler: the first gives the operation pipeline, the second gives the positioning rationale. It is well sized for a 9-parameter tool, though the first sentence is a fairly dense compound clause.

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

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

With a full output schema and 100% parameter coverage, the description need not explain return values, and it correctly covers the core flow plus fingerprint-based skipping. It is nearly complete, missing only explicit guidance on the destructive/write side effects the annotations imply.

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

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

Schema description coverage is 100%, so the parameters are already fully documented; baseline is 3. The description only restates the sourcePath dual behavior (file vs. newest .bip in a folder), adding no syntax or format detail beyond the schema.

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

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

The description names a specific verb (sync) and resource (saved .bip scene) and enumerates the operation's concrete steps: locate the file, detect change, copy to a collision-safe path, optionally preview. It is clear what the tool does, though it does not name any sibling tool (e.g. keyshot_save_scene or keyshot_inspect_scene) to sharpen differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"This is the stable alternative to unsupported persistent GUI control" implies when to reach for it, but there is no explicit when-not guidance and no sibling is named as the alternative. The agent must infer selection from the phrasing alone.

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