Skip to main content
Glama

analyze_mid_print_impact

Read-only

Analyze carved G-code before committing a mid-print edit to identify which layers will actually change and flag any shortfall versus the requested carve depth.

Instructions

Pre-commit truth gate: which layers will actually change (Pro).

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": "analyze_mid_print_impact"
  }
}

Input Schema

NameRequiredDescriptionDefault
session_idNoSession key from a prior ``decorate_during_print`` / ``add_feature_during_print`` call. Resolved under ~/.kiln/mid_print_sessions/ and the legacy tempdir fallbacks that ``get_print_before_edit`` uses. Default: "".
carved_gcode_pathNoExplicit path to a carved gcode, bypassing session lookup entirely. Useful for analysing a carved artifact that isn't in a standard session directory. Default: "".
engine_output_dirNoDirect path to the session directory. Higher priority if both supplied. Default: "".
requested_depth_mmNoThe decoration depth the originating tool call asked for. Used to compute the ``depth_gap_mm`` and fire ``DEPTH_SHY`` when the achievable depth falls short. Pass 0.0 (default) to skip depth warnings — the per-layer breakdown + carve metrics still populate. Default: 0.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • changedInput schema / properties / carved_gcode_path / description
      Previous value: -"Default: \"\"."New value: +"Explicit path to a carved gcode, bypassing session lookup entirely.  Useful for analysing a carved artifact that isn't in a standard session directory. Default: \"\"."
    • changedInput schema / properties / engine_output_dir / description
      Previous value: -"Default: \"\"."New value: +"Direct path to the session directory.  Higher priority if both supplied. Default: \"\"."
    • changedInput schema / properties / requested_depth_mm / description
      Previous value: -"Default: 0.0."New value: +"The decoration depth the originating tool call asked for.  Used to compute the ``depth_gap_mm`` and fire ``DEPTH_SHY`` when the achievable depth falls short.  Pass 0.0 (default) to skip depth warnings — the per-layer breakdown + carve metrics still populate. Default: 0.0."
    • changedInput schema / properties / session_id / description
      Previous value: -"Default: \"\"."New value: +"Session key from a prior ``decorate_during_print`` / ``add_feature_during_print`` call.  Resolved under ~/.kiln/mid_print_sessions/ and the legacy tempdir fallbacks that ``get_print_before_edit`` uses. Default: \"\"."
  2. Addedv1.5.0

TDQS

C2.9/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 the safety profile is covered. The description adds two things annotations do not: the "(Pro)" tier gate (an entitlement constraint the agent would otherwise hit as a surprise) and the notion that results are advisory before a commit. It does not disclose that warnings such as DEPTH_SHY can fire or that empty session paths fall back silently — those live only 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.

Conciseness3/5

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

It is a single front-loaded sentence fragment with no filler, which is good structurally. But the brevity comes at the cost of clarity rather than from efficiency: "truth gate" and "actually change" are compressed metaphors that leave the agent guessing at the concrete semantics.

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

Completeness2/5

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

Four parameters, session/path resolution precedence, depth-gap warning behavior and a Pro entitlement gate make this a non-trivial tool, and there is no output schema to explain results. The description accounts for none of that: it does not say what the analysis returns (layer breakdown, carve metrics) or what a caller should do with a negative result.

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%, and the schema already explains session_id resolution, carved_gcode_path bypass, engine_output_dir precedence and requested_depth_mm's role in depth_gap_mm/DEPTH_SHY. The description adds nothing about parameters, so the baseline 3 applies — the schema does all the work.

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

Purpose3/5

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

The phrase "which layers will actually change" does tell the agent this is a predictive/impact analysis, and "Pre-commit truth gate" frames it as a verification step. But the description never names the actual resource being analyzed (a mid-print decoration session, a carved gcode artifact) and uses jargon ("truth gate") that an agent cannot map to a concrete operation without reading the schema.

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?

"Pre-commit" implies the tool belongs before a commit/finalize step, which is genuine timing guidance. However, no alternative is named — not the sibling decorate_during_print / add_feature_during_print that produce the sessions this consumes, nor get_print_before_edit which is explicitly referenced in the schema. The agent must infer the workflow position.

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