Skip to main content
Glama

remove_spool

Destructive

Remove a used-up or finished filament spool from Kiln inventory so it is no longer treated as available filament.

Instructions

Remove a filament spool from inventory.

When the person says a spool is used up, finished or gone, remove it
here (``list_spools`` gives its id) so Kiln stops treating it as
filament they have.  If they have more or less left than Kiln shows,
correct the figure with ``add_spool(spool_id=..., remaining_grams=...)``
instead.  A used-up spool is not a reason to suggest buying filament:
say nothing about that unless the person asks.

Args:
    spool_id: The spool's unique identifier.

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": {
      "spool_id": "<spool_id>"
    },
    "name": "remove_spool"
  }
}

Input Schema

NameRequiredDescriptionDefault
spool_idYesThe spool's unique identifier.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / spool_id / description
      Added value: +"The spool's unique identifier."
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

The annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: removal means Kiln stops counting the spool as filament the user owns, and it constrains the agent's follow-up conversation. It does not say whether the removal is recoverable or what happens if the spool is currently loaded, which keeps it short of a 5.

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?

The core instruction and the routing sentence are front-loaded and waste no words. The final conversational rule about not pitching filament purchases is arguably tangential to the tool's mechanics, and the Args block duplicates the schema verbatim, so it is efficient but not perfectly lean.

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

Completeness4/5

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

For a one-parameter destructive mutation with no output schema, the definition covers the key gaps: what the tool does to Kiln's inventory state, how to find the id, and which sibling handles the adjacent case. It stops short of stating irreversibility or the effect on an in-progress print that references the spool.

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?

There is a single parameter with 100% schema description coverage, so the baseline is 3. The description only repeats the schema text ('The spool's unique identifier') and adds one operational hint that the id comes from list_spools, but no format or constraint details beyond 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?

The description states a specific verb and resource ('Remove a filament spool from inventory') and distinguishes the tool from its two nearest siblings: 'list_spools' for obtaining the id and 'add_spool(spool_id=..., remaining_grams=...)' for correcting a remaining amount. An agent can pick between remove_spool, add_spool and list_spools without opening the schemas.

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?

It gives an explicit trigger ('When the person says a spool is used up, finished or gone'), an explicit exclusion with the alternative named ('If they have more or less left than Kiln shows, correct the figure with add_spool... instead'), and even a downstream behavior constraint about not suggesting filament purchases. When-to-use, when-not-to-use and the alternative are all present.

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