Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

compare_renders

Read-only

Render 2–4 3D models side by side at the same camera angle to compare textures, colors, design iterations, or parameter sweeps in one labeled image.

Instructions

Render 2-4 models side by side in a single comparison image.

General-purpose visual diff tool — compare any 3D models at the same
camera angle in one image.  Each model is rendered individually then
stitched together with labels.

**Use cases:**
- Texture or decoration variants (compare 3 pattern options)
- Design iterations (before vs after)
- Material color comparisons
- Parameter sweeps (small / medium / large)

Returns a single PNG image path that can be displayed inline.
Supports 2-4 models per comparison.  When 4 models are provided
they are arranged in a 2x2 grid; otherwise a single row.

Args:
    paths: 2-4 file paths (STL, 3MF, OBJ, or SCAD).
    labels: Custom labels for each model.  Defaults to A, B, C, D.
    angle: Camera angle for all renders.  One of ``isometric``,
        ``front``, ``right``, ``top``, ``bottom``, ``back``.
    width: Per-model image width in pixels (default 800).
    height: Per-model image height in pixels (default 600).
    colors: Optional hex color per model (e.g. ``["#F72323", "#2323F7"]``).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "paths": "<paths>"
    },
    "name": "compare_renders"
  }
}

Input Schema

NameRequiredDescriptionDefault
angleNoCamera angle for all renders. One of ``isometric``, ``front``, ``right``, ``top``, ``bottom``, ``back``. Default: "isometric".
pathsYes2-4 file paths (STL, 3MF, OBJ, or SCAD).
widthNoPer-model image width in pixels (default 800). Default: 800.
colorsNoOptional hex color per model (e.g. ``["#F72323", "#2323F7"]``).
heightNoPer-model image height in pixels (default 600). Default: 600.
labelsNoCustom labels for each model. Defaults to A, B, C, D.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.5.1
    • changedInput schema / properties / angle / description
      Previous value: -"Default: \"isometric\"."New value: +"Camera angle for all renders.  One of ``isometric``, ``front``, ``right``, ``top``, ``bottom``, ``back``. Default: \"isometric\"."
    • addedInput schema / properties / colors / description
      Added value: +"Optional hex color per model (e.g. ``[\"#F72323\", \"#2323F7\"]``)."
    • changedInput schema / properties / height / description
      Previous value: -"Default: 600."New value: +"Per-model image height in pixels (default 600). Default: 600."
    • addedInput schema / properties / labels / description
      Added value: +"Custom labels for each model.  Defaults to A, B, C, D."
    • addedInput schema / properties / paths / description
      Added value: +"2-4 file paths (STL, 3MF, OBJ, or SCAD)."
    • changedInput schema / properties / width / description
      Previous value: -"Default: 800."New value: +"Per-model image width in pixels (default 800). Default: 800."
  2. Changed8 schema fields changedv1.5.0
    • removedInput schema / properties / angle / default
      Removed value: -"isometric"
    • addedInput schema / properties / angle / description
      Added value: +"Default: \"isometric\"."
    • removedInput schema / properties / colors / default
      Removed value: -null
    • removedInput schema / properties / height / default
      Removed value: -600
    • addedInput schema / properties / height / description
      Added value: +"Default: 600."
    • removedInput schema / properties / labels / default
      Removed value: -null
    • removedInput schema / properties / width / default
      Removed value: -800
    • addedInput schema / properties / width / description
      Added value: +"Default: 800."
  3. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered structurally. The description adds genuinely useful mechanics — each model rendered individually then stitched with labels, and the 2x2 grid layout when four models are supplied. It stops short of covering failure modes (missing files, mixed formats, render time/cost) or whether the output image is written to disk or ephemeral.

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

Conciseness3/5

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

The first line and the layout/return statement are well front-loaded and earn their place. The trailing 'Args:' block duplicates a schema that already has full description coverage, which is dead weight in a description that should be adding value beyond structured fields.

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 no output schema, the description correctly compensates by stating the return value is a single PNG image path displayable inline. Combined with the layout rules and defaults, an agent has enough to call it correctly for a read-only rendering tool; only edge-case behavior around invalid or uneven inputs is missing.

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 every parameter is already documented with type, default, and enum values, which sets the baseline at 3. The prose 'Args' section largely restates the schema — the same angle enum, the same defaults, the same example hex colors — and adds no new semantics such as whether labels/colors must match the length of paths or how mismatched lengths are handled.

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 opening line names a specific verb and resource plus the exact scope: 'Render 2-4 models side by side in a single comparison image.' The follow-up sentence clarifies that it is a general-purpose visual diff at a shared camera angle. It never names a sibling (e.g., render_design_mesh, visualize_model, visual_diff_meshes), so an agent must infer the boundary itself.

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

Usage Guidelines4/5

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

The 'Use cases' block gives concrete triggering scenarios (texture/decoration variants, before-vs-after iterations, material color comparisons, parameter sweeps), which is clear context for when to call it. However, there are no exclusions and no named alternative for single-model rendering or for non-visual mesh diffing.

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