Skip to main content
Glama

list_spools

Read-only

List tracked filament spools in inventory with remaining grams and the source of each estimate: inferred by Kiln, observed by the printer, or user-reported.

Instructions

List all tracked filament spools in inventory.

``remaining_grams`` is what Kiln believes is left on each spool, and
``remaining_determined_by`` says who set it: ``inferred`` is Kiln's own
count (what the spool held, less what the prints Kiln started were
sliced to use), ``observed`` is the printer's reading of a spool it can
measure, ``user_reported`` is what the person said.  A count misses
prints started outside Kiln, so report a counted figure as Kiln's
count, never as a measurement.  When the person says the figure is
wrong, correct it with ``add_spool(spool_id=..., remaining_grams=...)``;
when they say a spool is used up, ``remove_spool``.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and destructiveHint=false, but the description adds real substance beyond them: the provenance semantics of remaining_grams (inferred vs observed vs user_reported) and the caveat that a count misses prints started outside Kiln. That caveat directly affects how an agent should report the numbers, which no annotation conveys.

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?

Purpose is front-loaded in one sentence, then the field semantics and the correction path follow in a logical order. Slightly long for a list tool, but every clause (provenance, external-print caveat, corrective actions) carries information an agent needs.

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?

With no output schema, the description must explain return values, and it does cover the two most consequential fields and their enum meanings. It stops short of describing the full record (material, color, spool identity), leaving some uncertainty about what a spool object contains.

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

Parameters4/5

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

There are zero input parameters, so the baseline is 4; the description instead spends its words on the meaning of returned fields, which is appropriate for a no-arg tool.

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 and resource ('List all tracked filament spools in inventory'), and the body makes clear this is a read-only inventory listing distinct from the mutating add_spool and remove_spool siblings it names.

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 routes correction workflows to add_spool (with spool_id and remaining_grams) and deletion to remove_spool, so the agent knows this tool only reads. It doesn't spell out a when-not-to-call condition for listing itself, but the alternatives for the derived actions are named.

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