Skip to main content
Glama

restart_server

Destructive

Replaces the running Kiln MCP server process with a fresh instance to apply plugin installs, environment variable changes, or server code updates without reconnecting the MCP client.

Instructions

Restart the Kiln MCP server process.

Replaces the current process with a fresh instance using
``os.execve``.  The exec keeps the stdio pipe, so the MCP client sees
no disconnect and repeats no ``initialize`` handshake; the fresh
process takes up the handshake this connection already made, so the
client's next call simply works.  The client keeps the tool list it
cached when it connected: tools the new code adds reach it when it
reconnects.  The result's ``keeps_connection`` says whether the
handshake was handed on.

WHAT A RESTART REFRESHES depends on how this server was launched,
and the result says which happened.  A launcher script that
exported ``KILN_SERVE_WRAPPER`` is re-entered whole, so whatever
that script does before serving — syncing code, healing installs —
runs again.  Without it the restart re-execs ``python -m kiln
serve`` in place: a fresh process over however this interpreter
resolves ``kiln``, which picks up edits to those files but runs no
launcher logic.  (Measured 2026-08-19: an operator launcher synced
two runtime clones on every start, and a restart through this tool
silently skipped the sync — the served code was two revisions
stale while the restart reported success.)

Use after installing or updating kiln-pro plugins, changing
environment variables, or modifying server code — avoids the
need to fully restart the MCP client application.

:param clean_env: When ``True`` (default), strips ``KILN_PRINTER_*``
    environment variables from the child process if
    ``~/.kiln/config.yaml`` has a printer configured.  This defeats
    the "ghost env" footgun where a stale ``KILN_PRINTER_API_KEY``
    inherited from a past shell session silently shadows config.yaml
    edits for the lifetime of the MCP parent process.  Without this,
    every edit to config.yaml looks like it does nothing and the
    printer rejects MQTT auth with no hint why.  Set to ``False`` to
    preserve the full env (useful for CI or pure env-driven workflows
    where config.yaml is absent or deliberately overridden).
:returns: Confirmation that the restart is imminent, plus the list
    of env vars that were stripped (for debugging transparency).
    The exec happens ~0.5 seconds after this returns.

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

Input Schema

NameRequiredDescriptionDefault
clean_envNoWhen ``True`` (default), strips ``KILN_PRINTER_*`` environment variables from the child process if ``~/.kiln/config.yaml`` has a printer configured. This defeats the "ghost env" footgun where a stale ``KILN_PRINTER_API_KEY`` inherited from a past shell session silently shadows config.yaml edits for the lifetime of the MCP parent process. Without this, every edit to config.yaml looks like it does nothing and the printer rejects MQTT auth with no hint why. Set to ``False`` to preserve the full env (useful for CI or pure env-driven workflows where config.yaml is absent or deliberately overridden). Default: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • changedInput schema / properties / clean_env / description
      Previous value: -"Default: true."New value: +"When ``True`` (default), strips ``KILN_PRINTER_*`` environment variables from the child process if ``~/.kiln/config.yaml`` has a printer configured.  This defeats the \"ghost env\" footgun where a stale ``KILN_PRINTER_API_KEY`` inherited from a past shell session silently shadows config.yaml edits for the lifetime of the MCP parent process.  Without this, every edit to config.yaml looks like it does nothing and the printer rejects MQTT auth with no hint why.  Set to ``False`` to preserve the full env (useful for CI or pure env-driven workflows where config.yaml is absent or deliberately overridden). Default: true."
  2. Changed2 schema fields changedv1.5.0
    • removedInput schema / properties / clean_env / default
      Removed value: -true
    • addedInput schema / properties / clean_env / description
      Added value: +"Default: true."
  3. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the destructiveHint=true annotation: it explains that the stdio pipe survives, no re-initialize handshake occurs, the client's cached tool list persists until reconnect, and that the restart returns before the exec actually happens (~0.5s). The launcher-vs-python -m distinction and the stale-code warning are precisely the kind of failure mode annotations cannot convey.

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?

Front-loads purpose well, but the body is long for a one-parameter tool: the :param block duplicates the schema verbatim and the 'Measured 2026-08-19' anecdote runs several sentences. Each piece is informative, yet the total is more than the agent needs to select and call it.

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, and the description compensates by explaining the return value, including the keeps_connection flag and the stripped-env list. With destructive annotations, one optional parameter, and the connection-survival claim all covered, nothing an agent needs is missing.

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% and the single clean_env parameter is documented with identical prose in both places, so the description adds no meaning beyond the schema. Baseline 3 applies when the schema already carries the parameter documentation.

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?

First sentence states a specific verb and resource (restart the Kiln MCP server process) and the mechanism (os.execve replacement) immediately distinguishes it from siblings like trim_serve_processes or health_check.

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

Usage Guidelines4/5

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

Explicitly names the triggering situations — installing/updating kiln-pro plugins, changing environment variables, modifying server code — and the benefit (avoiding a full client restart). It does not point to any alternative tool such as trim_serve_processes or health_check when restarting is not the right remedy.

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