Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

visual_diff_meshes

Read-only

Render angle-by-angle diff images that compare before and after mesh files, letting you visually inspect 3D design changes. Requires Kiln Pro.

Instructions

Render a composited mesh-diff image per angle.

Needs Kiln Pro.

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": {
      "before_mesh_path": "<before_mesh_path>",
      "after_mesh_path": "<after_mesh_path>"
    },
    "name": "visual_diff_meshes"
  }
}

Input Schema

NameRequiredDescriptionDefault
widthNoEach picture's width in pixels (default 800); must be positive. Default: 800.
anglesNoThe views to render, one picture each, by name (``iso``, ``top``, ``front``, ``right``, ``back``). Omitted, ``iso`` alone.
heightNoEach picture's height in pixels (default 600); must be positive. Default: 600.
after_mesh_pathYesPath to the mesh as it is after the change. Required; a path that is not a file is refused.
before_mesh_pathYesPath to the mesh as it was before the change. Required; a path that is not a file is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.5.1
    • addedInput schema / properties / after_mesh_path / description
      Added value: +"Path to the mesh as it is after the change. Required; a path that is not a file is refused."
    • addedInput schema / properties / angles / description
      Added value: +"The views to render, one picture each, by name (``iso``, ``top``, ``front``, ``right``, ``back``).  Omitted, ``iso`` alone."
    • addedInput schema / properties / before_mesh_path / description
      Added value: +"Path to the mesh as it was before the change. Required; a path that is not a file is refused."
    • changedInput schema / properties / height / description
      Previous value: -"Default: 600."New value: +"Each picture's height in pixels (default 600); must be positive. Default: 600."
    • changedInput schema / properties / width / description
      Previous value: -"Default: 800."New value: +"Each picture's width in pixels (default 800); must be positive. Default: 800."
  2. Addedv1.5.0

TDQS

A3.5/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the Kiln Pro entitlement requirement, which is real behavioral context not present in structured fields. It does not disclose what the composited image actually shows, how images are returned, or whether the call is expensive/slow, so there is room left unfilled.

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?

Two short sentences, front-loaded with the action, with zero filler. The second sentence is terse to the point of ambiguity about whether 'Needs Kiln Pro' means a hard error, a paywall, or a capability check, which slightly undercuts the efficiency.

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 a fully documented schema and annotations carrying the safety profile, most of what an agent needs is present; the entitlement note closes the main practical gap. The remaining hole is what the rendered diff contains and what happens on entitlement failure, which matters more here because there is no output schema.

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 five parameters (width, height, angles, before_mesh_path, after_mesh_path) are already documented in detail. The phrase 'per angle' loosely ties to the angles parameter but adds no syntax or semantics beyond the schema, which is the expected baseline when the schema does the work.

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 uses a specific verb and resource: render a composited mesh-diff image, one per angle, from a before/after mesh pair. That is far more informative than the tool name alone. It does not, however, distinguish itself from nearby siblings such as compare_mesh_versions, compare_renders, or diff_design_versions, so an agent must infer the boundary.

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?

'Needs Kiln Pro' is a useful gating prerequisite that tells the agent the call will fail without an entitlement. Beyond that there is no when-to-use statement, no mention of when a textual/geometric compare is preferable to a visual diff, and no named alternative among the many compare_* siblings.

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