Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

report_issue

Destructive

Report bugs, ideas, printer-profile details, or questions to the Kiln team, optionally attaching app context, logs, and a structured workaround note so issues get diagnosed and fixed.

Instructions

Tell the Kiln team something — a bug, an idea, printer details, or a question.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "description": "<description>"
    },
    "name": "report_issue"
  }
}

Input Schema

NameRequiredDescriptionDefault
contextNoOptional machine context captured by the app — ``{tool_calls, app_version, os, printer_state, recent_events, conversation_snippet, suggested_fix, log_tail, field_note}``. ``log_tail`` is the last few KB of the local Kiln log (a local server attaches its own automatically; a remote client can capture one with ``kiln.log_config.read_log_tail()``). Secrets, private IPs, and home-directory usernames are stripped server-side before storage. ``field_note`` is the structured workaround, and it needs ALL FOUR of these or it is filed as an ordinary report instead: observed — what Kiln did, concretely. The tool you called and what came back, including any error code the machine reported. tried — what you tested. Change ONE thing at a time; a trial that moved two variables cannot say which one mattered, and we cannot ship it. worked — the thing that actually fixed it. evidence — how you know it worked. The error code cleared, the print started, the file matched. Say plainly when something is uncertain — an honest "this worked once and I changed two settings" is worth more than a confident guess, because we can ask for the missing trial instead of shipping a fix that was a coin flip. Do not send the user's designs, files, or geometry. What Kiln needs is what its own tools got wrong.
categoryNoWhat kind of message this is. The four standard values are "bug" (something misbehaved), "idea" (a wish for something Kiln can't do yet), "printer-profile" (details on a machine Kiln doesn't deeply support), and "question" (something for the team that no tool answers — account, billing, plans). Free-form text is also accepted and Kiln refines it automatically; defaults to "other". Set automatically to "field_note" when a complete workaround note is supplied. Default: "other".
contact_okNoSet True to let the team follow up with you about this report. Only honoured if you're signed in; anonymous reports always stay anonymous. Default: false.
descriptionYesWhat went wrong, in plain English. Required. Keep it to the key details (a few sentences).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • changedInput schema / properties / category / description
      Previous value: -"Default: \"other\"."New value: +"What kind of message this is. The four standard values are \"bug\" (something misbehaved), \"idea\" (a wish for something Kiln can't do yet), \"printer-profile\" (details on a machine Kiln doesn't deeply support), and \"question\" (something for the team that no tool answers — account, billing, plans). Free-form text is also accepted and Kiln refines it automatically; defaults to \"other\". Set automatically to \"field_note\" when a complete workaround note is supplied. Default: \"other\"."
    • changedInput schema / properties / contact_ok / description
      Previous value: -"Default: false."New value: +"Set True to let the team follow up with you about this report. Only honoured if you're signed in; anonymous reports always stay anonymous. Default: false."
    • addedInput schema / properties / context / description
      Added value: +"Optional machine context captured by the app — ``{tool_calls, app_version, os, printer_state, recent_events, conversation_snippet, suggested_fix, log_tail, field_note}``. ``log_tail`` is the last few KB of the local Kiln log (a local server attaches its own automatically; a remote client can capture one with ``kiln.log_config.read_log_tail()``). Secrets, private IPs, and home-directory usernames are stripped server-side before storage. ``field_note`` is the structured workaround, and it needs ALL FOUR of these or it is filed as an ordinary report instead: observed — what Kiln did, concretely. The tool you called and what came back, including any error code the machine reported. tried    — what you tested. Change ONE thing at a time; a trial that moved two variables cannot say which one mattered, and we cannot ship it. worked   — the thing that actually fixed it. evidence — how you know it worked. The error code cleared, the print started, the file matched. Say plainly when something is uncertain — an honest \"this worked once and I changed two settings\" is worth more than a confident guess, because we can ask for the missing trial instead of shipping a fix that was a coin flip. Do not send the user's designs, files, or geometry. What Kiln needs is what its own tools got wrong."
    • addedInput schema / properties / description / description
      Added value: +"What went wrong, in plain English. Required. Keep it to the key details (a few sentences)."
  2. Addedv1.5.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=false, so the agent knows this is a non-idempotent write rather than a read. The description adds nothing about what actually happens to the message, whether the team responds, or that anything leaves the local machine — the privacy/redaction guarantees live only in the schema's context field, not in the description.

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, appropriate for a tool whose real complexity is carried by the schema. It could have been marginally sharper about the report being filed to the team rather than stored locally, but nothing is wasted.

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

Completeness3/5

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

There is no output schema, so the description should convey what the agent gets back or what happens next, and it does neither. The four documented parameters are self-explanatory from the schema, but a mutation tool that ships user data off-device warrants at least a line about confirmation or outcome.

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 parameters are unusually well documented in-schema, including the category enum values, the contact_ok sign-in caveat, and the full field_note structure. The description therefore adds no meaning beyond the schema, which is the expected baseline of 3 here.

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?

The description names a specific verb ('Tell the Kiln team') plus a concrete set of message classes ('a bug, an idea, printer details, or a question'), which maps directly onto the category parameter. It is clearly distinct from the surrounding printer/design-mesh tools in the sibling list, though it never explicitly names any sibling or boundary case.

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?

The enumerated message types imply when to reach for this tool (something is wrong, wanted, unsupported, or unanswerable by other tools), but there is no explicit when-to-use/when-not statement or pointer to alternatives such as troubleshoot_printer or answer_printer_question. Usage is inferable rather than stated.

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