Skip to main content
Glama
codeofaxel

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

publish_print_twin

Upload the current print's sliced file so the web Monitor can show the object and scrub its layers.

Instructions

Upload the current print's sliced file so the web Monitor can show the object and scrub its layers.

        The web Monitor at kiln3d.com calls this through the Kiln bridge
        while a print is running; there is normally no reason to call it
        by hand.  It reads the engine's own retained copy of the file it
        last sent to the printer (kept per printer under
        ``~/.kiln/monitor_twin``), uploads it — gzipped — to YOUR Kiln
        account, and returns a short-lived artifact token the browser
        uses to fetch the mesh and toolpath.  Nothing is uploaded except
        by this explicit call, and nothing crosses tenants: the token is
        IDOR-checked against your own account on every fetch.

        Honest refusals: prints Kiln did not slice on this machine (a
        pre-sliced upload, a job started at the printer's screen) have
        no retained file, and the response says so rather than guessing.

        Args:
            printer_name: Which printer's active print to publish.  Omit
                for the machine's single/default printer.

        Returns:
            ``{"success": True, "artifact_token", "stl_url"|null,
            "gcode_url"|null, "file_name", "expires_in"}`` on success;
            ``{"success": False, "code", "message"}`` otherwise.

Input Schema

NameRequiredDescriptionDefault
printer_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.0
    • removedInput schema / properties / printer_name / default
      Removed value: -null
  2. Addedv1.3.1

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the source path (~/.kiln/monitor_twin), gzip upload, short-lived artifact token, per-fetch IDOR/tenant checks, and that nothing is uploaded except via this explicit call. It also states what happens when no retained file exists instead of guessing.

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?

Well front-loaded with purpose first, then context, refusal behavior, Args, and Returns. It is somewhat verbose — the docstring Args/Returns block partly restates what the parameter/return shape conveys — but no sentence is wasted and structure is clear.

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

Completeness5/5

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

No output schema exists, but the description documents the success and failure response shapes ({success, artifact_token, stl_url|gcode_url, file_name, expires_in} vs {success, code, message}). Combined with the single-param explanation, an agent has everything needed to call it correctly or decide not to.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate, and it does by explaining printer_name selects which printer's active print to publish and that omitting it targets the single/default printer. That is meaningfully more than the bare 'Printer Name' title in the schema.

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

Purpose5/5

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

States a specific verb (upload/publish) and resource (current print's sliced file / print twin) plus its consumer (web Monitor showing the object and layer scrubbing). This is clearly distinguishable from siblings like list_snapshots or issue_preview_token.

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

Usage Guidelines5/5

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

Explicitly says the web Monitor invokes it through the Kiln bridge during a print and that 'there is normally no reason to call it by hand', which is a clear when/when-not signal. It also names the failure case (pre-sliced uploads, jobs started at the printer screen) that yields an honest refusal.

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