Skip to main content
Glama
chartergroup

topopt

by chartergroup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List filaments for a printer

printer_materials
Read-onlyIdempotent

Check which catalog and user filaments a given printer can use, grouped by ok, care, no, and unknown states with reasons for each mismatch.

Instructions

Which filaments can this printer print? Every current filament of the catalog and the user file, grouped by state, with the reasons (older sheets of a listed product are counted in note). It reads; it changes nothing.

printer: a printer as the user says it (a name or id; see find_printer). Without it, the printer of the preferences file (print.printer_model) is used; if there is none, the reply is {"ok": false, "error": ...} that says how to name one. States (facts about the stated values, not a stop; no run is refused because of them): ok (every stated value fits), care (it can work, and the person has to do or know something: fit a hardened nozzle or a chamber heater, take the lower part of a temperature range), no (a stated need is above a stated limit of the printer as it ships, for example an enclosed printer, a nozzle temperature or a bed temperature; the user may have changed the printer), unknown (a value is missing on one side; the reason names it). Returns: ok, printer (id, name, origin, from), catalog_version, counts, groups, available, user_file, note.

  • groups: ok, care, no, unknown, each a list of {id, name, family, origin, available, source, reasons}. reasons lists the checks that are not ok (check, state, text); the text names both values that it compares. source is the data sheet of the filament; the source of the printer is printer.from. The reply is long (about 70 filaments): read the groups that matter and name the few that the user asked for.

  • available: the filaments of filaments.available of the preferences, each with its state; they are also marked in the groups. An id that is not found now is left out and named in not_used; an older sheet has its state and a note with the newer id. Say it as a fact with the reason ("PLA Basic: ok on a P1S", "ABS on an A1 mini: no, the maker asks for an enclosed printer"). The user decides. A filament that is not listed: find_material, then save_material.

Input Schema

NameRequiredDescriptionDefault
printerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent, but the description adds real value beyond them: the error shape {"ok": false, "error": ...} when no printer can be resolved, the fact that no run is refused because of a state, the ~70-item reply size with advice to read only relevant groups, and the not_used / older-sheet handling. Nothing contradicts the annotations.

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?

Front-loaded with the purpose, then parameter, then state definitions, then return shape — a sensible order. It is dense and long, with heavy backtick notation and parentheticals, but nearly every sentence carries decision-relevant information.

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?

There is no output schema, yet the description enumerates the return fields (ok, printer, catalog_version, counts, groups, available, user_file, note) and the per-item shape (id, name, family, origin, available, source, reasons). Combined with annotations covering the safety profile and the state taxonomy, an agent has everything needed to call and interpret it.

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

Parameters5/5

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

Schema coverage is 0% and the single parameter is undocumented in the schema, so the description carries the full burden — and it does: accepts a name or id, points to find_printer for naming, and defines the fallback to print.printer_model in the preferences file with the resulting error behavior.

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?

Opens with a specific user question ('Which filaments can this printer print?') and states the resource and scope precisely: every catalog and user-file filament, grouped by state, with reasons. It is clearly distinguishable from catalog-search siblings like find_material, which it explicitly routes to for unlisted filaments.

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?

Gives clear usage context and alternatives: use find_material then save_material for a filament that is not listed, and see find_printer for how to name a printer. It also defines the default behavior when the printer argument is omitted. It does not state an explicit 'do not use this when...' case, so it stops short of a 5.

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