Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

diff_assembly_manuals

Compare two assembly manual revisions to generate a PDF showing what changed, or return a JSON changelog when PDF inputs are omitted.

Instructions

Compute a "what changed" PDF between two manual revisions (Business+).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "diff_assembly_manuals"
  }
}

Input Schema

NameRequiredDescriptionDefault
design_idNoThe design whose history the version and release labels are resolved against.
manual_id_newNoThe newer manual revision id, likewise.
manual_id_oldNoThe older manual revision id from manual history. Overridden when a version or release label for the old side is given.
spec_new_pathNoPath to the new manual's ``spec.json``; used when no history id is resolved for the new side.
spec_old_pathNoPath to the old manual's ``spec.json``; used when no history id is resolved for the old side.
release_id_newNoResolve the new side as the manual signed under this release id.
release_id_oldNoResolve the old side as the manual signed under this release id.
version_id_newNoResolve the new side as the manual recorded for this design version.
version_id_oldNoResolve the old side as the manual recorded for this design version.
include_retiredNoWhen ``True``, retired revisions count when resolving labels and building the changelog. Defaults to ``False``. Default: false.
output_pdf_pathNoWhere to write the diff PDF. Without it (or without both assembly states) only the JSON summary is returned.
release_name_newNoResolve the new side by the release's buyer-facing name.
release_name_oldNoResolve the old side by the release's buyer-facing name.
assembly_new_jsonNoThe new assembly state (JSON string or object). Needed for the PDF.
assembly_old_jsonNoThe old assembly state (JSON string or object). Needed, with the other two render inputs, for the PDF.
include_intermediateNoWhen ``True``, also return the cumulative changelog of every manual between the two. Both sides must resolve to manual history revisions; spec paths are refused. Defaults to ``False``. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changedv1.5.1
    • addedInput schema / properties / assembly_new_json / description
      Added value: +"The new assembly state (JSON string or object). Needed for the PDF."
    • addedInput schema / properties / assembly_old_json / description
      Added value: +"The old assembly state (JSON string or object). Needed, with the other two render inputs, for the PDF."
    • addedInput schema / properties / design_id / description
      Added value: +"The design whose history the version and release labels are resolved against."
    • changedInput schema / properties / include_intermediate / description
      Previous value: -"Default: false."New value: +"When ``True``, also return the cumulative changelog of every manual between the two. Both sides must resolve to manual history revisions; spec paths are refused. Defaults to ``False``. Default: false."
    • changedInput schema / properties / include_retired / description
      Previous value: -"Default: false."New value: +"When ``True``, retired revisions count when resolving labels and building the changelog. Defaults to ``False``. Default: false."
    • addedInput schema / properties / manual_id_new / description
      Added value: +"The newer manual revision id, likewise."
    • addedInput schema / properties / manual_id_old / description
      Added value: +"The older manual revision id from manual history. Overridden when a version or release label for the old side is given."
    • addedInput schema / properties / output_pdf_path / description
      Added value: +"Where to write the diff PDF. Without it (or without both assembly states) only the JSON summary is returned."
    • addedInput schema / properties / release_id_new / description
      Added value: +"Resolve the new side as the manual signed under this release id."
    • addedInput schema / properties / release_id_old / description
      Added value: +"Resolve the old side as the manual signed under this release id."
    • addedInput schema / properties / release_name_new / description
      Added value: +"Resolve the new side by the release's buyer-facing name."
    • addedInput schema / properties / release_name_old / description
      Added value: +"Resolve the old side by the release's buyer-facing name."
    • addedInput schema / properties / spec_new_path / description
      Added value: +"Path to the new manual's ``spec.json``; used when no history id is resolved for the new side."
    • addedInput schema / properties / spec_old_path / description
      Added value: +"Path to the old manual's ``spec.json``; used when no history id is resolved for the old side."
    • addedInput schema / properties / version_id_new / description
      Added value: +"Resolve the new side as the manual recorded for this design version."
    • addedInput schema / properties / version_id_old / description
      Added value: +"Resolve the old side as the manual recorded for this design version."
  2. Addedv1.5.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, and the description is consistent with them since it writes a PDF artifact. The description adds the Business+ entitlement requirement, which is real context not present in the structured fields, but says nothing about overwriting an existing output_pdf_path or how side resolution precedence works.

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 front-loaded sentence with no filler; the artifact and the entitlement gate come first. It is efficient, though it is arguably terse relative to the tool's complexity.

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?

For a 16-parameter, zero-required tool, the schema carries the heavy lifting on side resolution and the PDF-vs-JSON return behavior (via output_pdf_path), so the description need not repeat it. The main gap is the absence of any sibling differentiation or tier-scope elaboration, which is modest against a fully documented 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 coverage is 100% across 16 parameters, and the schema descriptions already explain the resolution rules (history id, version, release id/name, spec path) and the include_retired/include_intermediate semantics. 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.

Purpose4/5

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

States a specific verb and artifact ('Compute a "what changed" PDF') plus the exact inputs it compares (two manual revisions), which is unambiguous. It does not name or distinguish itself from nearby siblings such as diff_design_versions or generate_assembly_manual, so it stops short of a 5.

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

Usage Guidelines2/5

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

The only usage signal is the '(Business+)' entitlement note. There is no guidance on when to pick this over diff_design_versions or get_manual_revision, and no explanation of when a diff is appropriate versus regenerating a manual.

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