---
import BlogPostLayout from '../../layouts/BlogPostLayout.astro';

const contentHtml = "<p>Kiln 1.0 is here.</p>\n<p>Since our last release and blog post, Kiln kept moving. We kept building, day in and day out: printer control, safety, slicing, recovery, design intelligence, command-line coverage, and a much larger MCP surface for agents.</p>\n<figure class=\"post-hero-inline\"><img src=\"/blog/kiln-v1-hero.png\" alt=\"Two printed objects made with Kiln\" loading=\"eager\" /><figcaption>Real objects, generated and iterated through Kiln&#39;s MCP workflow.</figcaption></figure>\n<p>One important context note: kiln-pro did not formally exist when v0.2.1 came out. Back then, Kiln was effectively one public open-source project. v1.0 is also the release where the boundary became explicit. Public Kiln stays local-first, inspectable, and agent-facing. kiln-pro is the paid layer for people who want deeper workflows around their printer: Git for 3D branching and signed releases, the full decoration and texture engine, automated assembly manuals, recovery, hosted execution, fleet, billing, team, and enterprise controls.</p>\n<p>v1.0 is not a pivot into a browser-first printer app. Kiln is still infrastructure: an MCP server and CLI that let AI agents work with physical printers through typed, inspectable, safety-checked tools.</p>\n<p>The web app has one job right now: the Git-for-3D experience. It is a repository-style surface for 3D objects, not an agent conversation UI. You push designs from the CLI or an MCP client, then use the web workshop to browse designs, branch, review mesh diffs, approve pull requests, sign releases, and trace object history.</p>\n<p>The core loop stays local and agent-native:</p>\n<p>In your MCP client or terminal: describe the part, generate or import geometry, check material and printer constraints, slice, preflight, print, monitor, and recover when the real world interrupts.</p>\n<h2>The numbers</h2>\n<table>\n<thead>\n<tr>\n<th>Surface</th>\n<th>v0.2.1</th>\n<th>v1.0</th>\n<th>Delta</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>MCP tools</td>\n<td>273</td>\n<td><strong>756</strong></td>\n<td>+483</td>\n</tr>\n<tr>\n<td>Total MCP capabilities</td>\n<td>273+</td>\n<td><strong>763</strong></td>\n<td>tools, prompts, and resources</td>\n</tr>\n<tr>\n<td>CLI commands</td>\n<td>107</td>\n<td><strong>215</strong></td>\n<td>+108</td>\n</tr>\n<tr>\n<td>Collected tests</td>\n<td>~5,900</td>\n<td><strong>13,252</strong></td>\n<td>+7,352</td>\n</tr>\n<tr>\n<td>Design intelligence</td>\n<td>early catalog</td>\n<td><strong>25 FDM materials, 45 brand filament profiles, 20 patterns</strong></td>\n<td>production-grade recommendations</td>\n</tr>\n<tr>\n<td>Printer safety profiles</td>\n<td>9</td>\n<td><strong>44 named model profiles</strong></td>\n<td>broader hardware-specific limits</td>\n</tr>\n</tbody></table>\n<p>The important part is not just that Kiln got bigger. It is that the surface is now usable at that size.</p>\n<p>Agents do not need to load every schema up front. Kiln exposes manifests and discovery tools so an agent can search for the right capability when it needs it: printer status, slicing, AMS, filament, preflight, recovery, semantic diffs, fulfillment, fleet routing, or release signing.</p>\n<p>The catalog is large because physical manufacturing has a lot of edge cases. The interaction stays small.</p>\n<h2>What ships in v1.0</h2>\n<h3>1. A much larger MCP surface</h3>\n<p>Kiln&#39;s primary interface is MCP:</p>\n<pre><code class=\"language-bash\">python3 -m pip install kiln3d\nkiln install-mcp\nkiln serve\n</code></pre>\n<p>Any MCP-compatible agent can discover and call Kiln tools. The tools are typed, scoped, and designed around physical actions rather than generic API endpoints.</p>\n<p>That distinction matters. A printer is not a database. A model should not be allowed to improvise around heater limits, bed bounds, material constraints, or preflight checks. Kiln gives agents enough surface area to be useful without letting them treat hardware like text.</p>\n<h3>2. A CLI that can carry the whole workflow</h3>\n<p>The CLI is not a thin wrapper around a demo. v1.0 exposes 215 commands for people who want terminal-first control or scriptable automation:</p>\n<pre><code class=\"language-bash\">kiln whoami\nkiln tools\nkiln install-mcp\nkiln serve\n</code></pre>\n<p>The CLI also makes Kiln easier to debug. When an MCP client behaves strangely, the same underlying action can usually be checked directly from the terminal. That keeps the system inspectable.</p>\n<h3>3. A repository-style web workshop for 3D objects</h3>\n<p>The web app exists, but it is not where users converse with agents and it is not trying to replace the MCP/CLI workflow.</p>\n<p>The current web app is a repository-style workshop for artifacts that come from Kiln&#39;s agent and CLI surfaces. The code path is intentionally mirror-like: UI actions call the same MCP tools through <code>POST /api/tools/&lt;tool_name&gt;</code> instead of inventing a separate browser-only product.</p>\n<p>What it does today:</p>\n<ul>\n<li><strong>Workshop dashboard</strong> - a private contribution-style view of your designs, branches, signed releases, contribution heatmap, pinned designs, and recent activity.</li>\n<li><strong>Designs</strong> - list design repositories, create an empty design slot, and then push the first mesh from your AI agent or CLI.</li>\n<li><strong>Branches</strong> - create and inspect branches for a design, with branch trees and per-branch history.</li>\n<li><strong>Compare</strong> - compare two branches and inspect the mesh diff; added geometry, removed geometry, and unchanged geometry are shown distinctly.</li>\n<li><strong>Pull requests</strong> - review proposed design changes with conversation, mesh diff, approval gate, files, and actions for approve, request changes, merge, or close.</li>\n<li><strong>Releases</strong> - sign a specific design version with provenance so downstream users can verify what was shipped.</li>\n<li><strong>Ancestry and reflog</strong> - trace a design&#39;s version chain and head-mutating operation history.</li>\n<li><strong>Remotes</strong> - manage Kiln Cloud remotes for pushing branches, pulling releases, and syncing print outcomes.</li>\n<li><strong>Connect</strong> - mint a pairing code so your local CLI/MCP server can attach this machine to your account and tier.</li>\n</ul>\n<p>That is the right web app shape for v1.0: a place to review and govern physical design history after the work comes in from MCP or the terminal. The web app will keep growing from here, but this release is intentionally scoped around design history, review, releases, and pairing.</p>\n<pre><code class=\"language-bash\">kiln pair KLN-...\nkiln whoami\n</code></pre>\n<p>Pairing writes local auth state so the CLI and MCP server can resolve your account and tier. After that, the agent still works through Kiln&#39;s local command and tool surface.</p>\n<h3>4. Git for 3D printing</h3>\n<p>3D files should not behave like anonymous blobs.</p>\n<p>Kiln 1.0 gives physical designs a versioning layer: branches, merges, signed releases, external mesh imports with provenance reconstruction, semantic diffs, and outcome-aware review.</p>\n<p>A change is not just &quot;some bytes changed.&quot; Kiln can track manufacturing-relevant differences: bounding boxes, Z-level contours, pockets, decorations, feature records, and recorded print outcomes.</p>\n<p>That lets you ask better questions before making a part real:</p>\n<ul>\n<li>Did this change alter the geometry in a way that matters?</li>\n<li>Did similar changes improve or regress past prints?</li>\n<li>Is this release the same mesh that was signed?</li>\n<li>Which version produced the object on the table?</li>\n</ul>\n<p>Software teams take those guarantees for granted. Physical design needs them more, not less.</p>\n<h3>5. Design intelligence before geometry</h3>\n<p>Kiln&#39;s design intelligence layer now includes 25 FDM materials, 45 brand-specific filament profiles, 18 design templates, load tables, environment compatibility rules, post-processing guidance, and material troubleshooting.</p>\n<p>That means an agent can reason before it generates or prints:</p>\n<ul>\n<li>indoor cosmetic print or outdoor functional part</li>\n<li>rigid bracket or flexible component</li>\n<li>heat exposure, moisture, creep, impact, or UV</li>\n<li>snap fit, living hinge, press fit, threaded insert, or reinforced beam</li>\n<li>printer capability and loaded material</li>\n</ul>\n<p>The point is simple: stop treating generation as the first step. In physical manufacturing, constraints come first.</p>\n<h3>6. Safety as a protocol requirement</h3>\n<p>Kiln 1.0 treats safety as part of the interface, not a warning in the docs.</p>\n<p>The safety stack includes:</p>\n<ul>\n<li>44 named printer-model safety profiles</li>\n<li>G-code validation before dangerous commands reach hardware</li>\n<li>temperature, feedrate, flow, and build-volume checks</li>\n<li>preview-confirmed print starts</li>\n<li>non-optional preflight checks</li>\n<li>emergency stop and heater watchdog paths</li>\n<li>audit events for tool calls and production actions</li>\n</ul>\n<p>An AI agent can be useful around hardware only if the safety layer is stronger than the prompt.</p>\n<h3>7. Recovery for real printer behavior</h3>\n<p>Printers do not fail politely.</p>\n<p>Networks drop. Firmware pauses. Nozzles cool. A bed that was clear at upload time may not be clear when a retry starts. Startup G-code that is safe for a fresh print can be unsafe for a same-bed resume.</p>\n<p>v1.0 adds recovery work for that reality:</p>\n<ul>\n<li>resume paused jobs that cooled below extrusion temperature</li>\n<li>preserve safe printer state before continuing</li>\n<li>validate same-bed retry against bed clearance and startup safety</li>\n<li>rewrite or quarantine unsafe startup sequences instead of trusting them blindly</li>\n<li>retry on the same build plate only when Kiln can place the new attempt in a clear zone, away from the failed remnant, objects already on the plate, purge/wipe/probe paths, and calibration regions</li>\n<li>decide whether fleet recovery should rerun the job on another idle, compatible printer, with material, build-volume, progress, cooldown, attempt-limit, and safety-critical checks attached to the decision</li>\n<li>fail closed when the printer state is ambiguous</li>\n</ul>\n<p>The goal is not to make printers magical. The goal is to make recovery boring enough that an agent can do the right thing without guessing.</p>\n<h3>8. Texture and decoration engines</h3>\n<p>Texture and decoration deserve their own place in the release because they are where Kiln starts feeling less like &quot;printer control&quot; and more like physical object editing.</p>\n<p>The texture engine applies procedural and image-based surface treatments to arbitrary meshes and exports print-ready multicolor 3MF. The details matter:</p>\n<ul>\n<li>procedural patterns such as alligator, wood grain, tiger stripe, camo, digital camo, ocean, galaxy, tie-dye, glitch, cells, noise, and stripes</li>\n<li>mesh subdivision so a low-face-count STL has enough surface samples to carry the pattern</li>\n<li>seamless cylindrical mapping for mugs, vases, and curved walls</li>\n<li>shared preview/output mapping so the preview and exported 3MF agree</li>\n<li>pure-Python 3MF composition for slicer-ready multicolor output</li>\n<li>image-based heightmaps for photos, logos, and other visual sources</li>\n</ul>\n<p>The decoration engine sits one level above that. Users and agents should not need to memorize whether a logo needs image deboss, heightmap texture, QR generation, text emboss, or a template-specific placement rule. v1.0 moves toward a declarative surface:</p>\n<pre><code class=\"language-python\">decorate_surface(\n    model_path=&quot;mug.stl&quot;,\n    face=&quot;front&quot;,\n    decoration={&quot;type&quot;: &quot;image&quot;, &quot;source&quot;: &quot;logo.png&quot;}\n)\n</code></pre>\n<p>Kiln handles the technique selection, depth, face geometry, posterization, material interaction, and safety checks. It can discover decoratable faces, apply different decorations to different faces, register reusable brand assets, auto-thicken thin floors when front/back decorations would collide, and record successful decoration settings so future prints can reuse proven parameters.</p>\n<p>Some of these workflows are paid or quota-gated through kiln-pro. The public MCP and CLI surfaces remain the way agents discover, request, and reason about them. Hosted execution handles tier checks and server-side implementation where needed.</p>\n<h3>9. Assembly manuals for printed objects</h3>\n<p>Multi-part prints need instructions as much as they need geometry.</p>\n<p>kiln-pro can generate printable assembly manual PDFs for multi-part objects, with an exploded cover, bill of materials, step-by-step isometric renders, tool and fastener context, confidence calibration, and sidecar proof artifacts. The manual stack can also keep revision history, load a previous manual spec, compare manual revisions, render a &quot;what changed&quot; PDF, and embed the manual plus a signed manifest into a 3MF.</p>\n<p>The tier boundary matters here too. Pro covers personal single-language manuals with Kiln attribution. Business adds the commercial workflow: co-branding, multilingual PDFs, change-only manuals for shipped revisions, and buyer-side authenticity checks.</p>\n<p>This is the same product thesis as Git for 3D: a physical object should not be a loose file. It should carry instructions, provenance, and review history with it.</p>\n<h3>10. Fleet and fulfillment foundations</h3>\n<p>Kiln 1.0 is FDM-first because that is where the product is real today.</p>\n<p>Inside that scope, the release expands the foundation for:</p>\n<ul>\n<li>mixed local printer fleets</li>\n<li>material-aware routing</li>\n<li>recovery and reroute planning</li>\n<li>per-part economics for quoted plates</li>\n<li>third-party fulfillment routing through providers such as Craftcloud</li>\n<li>team, audit, SSO, and access-control surfaces in paid tiers</li>\n</ul>\n<p>Kiln does not operate its own manufacturing marketplace. It orchestrates local printers and connected third-party providers while keeping the agent-facing control layer consistent.</p>\n<h2>The open and paid boundary</h2>\n<p>Kiln has two sides:</p>\n<ul>\n<li><strong>Kiln</strong> - the public AGPL-3.0 package installed with <code>pip install kiln3d</code></li>\n<li><strong>kiln-pro</strong> - the private paid companion behind deeper printer workflows, hosted execution, and commercial operations</li>\n</ul>\n<p>That split is new since the last public blog post. It is not a rewrite of what Kiln is; it is the boundary that lets the open tool stay useful while the business-grade operations have a real home.</p>\n<p>The public side should stay inspectable, local-first, and safe. The paid side should pay for the parts that took real product work and give users more leverage around their own printer: the full decoration and texture engine, Git for 3D branching and signed releases, versioned decoration presets, automated assembly manuals, recovery and resume, print-outcome learning, hosted execution, and higher quotas.</p>\n<p>Then Business and Enterprise add the operational layer: commercial use, team workflows, fleet operations, co-branded and multilingual manuals, auditability, SSO, access control, custom safety profiles, and support.</p>\n<p>Free users do not need proprietary code copied into the public repo to try paid workflows. The hosted tool path exists so pro tools can run server-side with quota and tier checks while the implementation stays private.</p>\n<h2>Patent-pending work</h2>\n<p>Parts of the Kiln v1.0 stack are patent-pending.</p>\n<p>The goal is simple: keep the public infrastructure open while protecting the parts of physical-agent manufacturing that took real work to build.</p>\n<h2>Install</h2>\n<pre><code class=\"language-bash\">python3 -m pip install kiln3d\nkiln install-mcp\nkiln signin\nkiln whoami\nkiln serve\n</code></pre>\n<p>Or pair from the web app:</p>\n<pre><code class=\"language-bash\">kiln pair KLN-...\nkiln whoami\n</code></pre>\n<p>Links:</p>\n<ul>\n<li>GitHub: <a href=\"https://github.com/codeofaxel/Kiln\">github.com/codeofaxel/Kiln</a></li>\n<li>Docs: <a href=\"https://kiln3d.com/docs\">kiln3d.com/docs</a></li>\n<li>Pricing: <a href=\"https://kiln3d.com/pricing\">kiln3d.com/pricing</a></li>\n</ul>\n<h2>What is next</h2>\n<p>v1.0 is real infrastructure, not an experiment.</p>\n<p>There is lots more to come.</p>\n<p>For now: Kiln 1.0 is live.</p>\n<p>The quiet part is over. Let&#39;s build.</p>\n";
---

<BlogPostLayout
  title="Kiln 1.0: The Agent-Native Manufacturing Layer"
  description="Kiln 1.0 is the release where the MCP and CLI surfaces become a real agent-native manufacturing layer: 756 MCP tools, 763 total MCP capabilities, 215 CLI commands, 13,252 collected tests, and a repository-style web workshop for iterating on 3D objects."
  date="April 29, 2026"
  tags={["release", "mcp", "cli", "v1.0", "git-for-3d"]}
>
  <Fragment set:html={contentHtml} />
</BlogPostLayout>

<style is:global>
  .post-body .post-hero-inline {
    margin: 30px 0 38px;
  }

  .post-body .post-hero-inline img {
    display: block;
    width: 100%;
    height: auto;
    border-radius: 10px;
    border: 1px solid var(--border);
    background: #111;
  }

  .post-body .post-hero-inline figcaption {
    font-size: 13px;
    line-height: 1.5;
    color: var(--text-muted);
    margin-top: 10px;
    text-align: center;
  }

  .post-body table {
    width: 100%;
    border-collapse: collapse;
    font-size: 13px;
    line-height: 1.45;
    margin: 24px 0;
    border: 1px solid var(--border);
    border-radius: 10px;
    overflow: hidden;
    display: block;
  }

  .post-body thead,
  .post-body tbody,
  .post-body tr {
    width: 100%;
  }

  .post-body th,
  .post-body td {
    padding: 12px 14px;
    border-bottom: 1px solid var(--border);
    text-align: left;
    vertical-align: top;
  }

  .post-body th {
    color: var(--text);
    font-weight: 600;
    background: #191919;
    font-size: 11px;
    text-transform: uppercase;
    letter-spacing: 0.06em;
  }

  .post-body td {
    color: var(--text-muted);
  }

  .post-body td strong {
    color: #fff;
  }

  .post-body tr:last-child td {
    border-bottom: 0;
  }
</style>
