Skip to main content
Glama

Save a filament profile

save_material
DestructiveIdempotent

Adds a missing filament and its sourced datasheet values to topopt-filaments.yaml so topology optimization runs can use it.

Instructions

Keep a filament that is not in the catalog, with its facts and their sources, in topopt-filaments.yaml in the work folder. It writes only that file.

Use it after find_material says "none": look up the data sheet of the maker (web search), show the user the values with the page address, and call this tool after the user agrees. A value that you cannot find stays null (unknown): ask the user for it, and leave it null if they do not know; a guess would look like a fact. The server reads the file at each call, so the filament is live at once. profile: one filament as a dict. Needed: id (lower-case slug, for example "acme-pla-plus"), maker, product, family (PLA, PETG, ABS, PA6-CF, ...), and a source: source_url (the data sheet) or source "user" (the user said the values). A run needs a modulus (the tensile E_xy_mpa or E_z_mpa, MPa; a sheet that gives only a bending modulus gives bending_modulus_xy_mpa or bending_modulus_z_mpa, and E is taken from it) and a density (density_g_cm3, g/cm3) from it, or from the YAML. Optional (null or left out = unknown): aliases (list), sheet_version, E_xy_mpa, E_z_mpa, bending_modulus_xy_mpa, bending_modulus_z_mpa, strength_xy_mpa, strength_z_mpa, strength_kind ("yield", "peak", "not stated"), elongation_xy_pct, density_range_g_cm3 ([min, max] of a sheet that gives a range, with density_g_cm3 null), hdt_18_c, hdt_045_c, nu, nozzle_c ([min, max] in C), bed_c ([min, max]), enclosure ("no", "recommended", "required"), chamber_c_min, hardened_nozzle (true or false), drying (text), direct_drive (true), abrasive (true for fibre), soft (true for TPU), conditioned (wet values of a polyamide: condition, strength_xy_mpa, strength_z_mpa, E_xy_mpa, E_z_mpa), opened (YYYY-MM-DD, the day the page was read), tag ("maker TDS", "maker page", "third party", "user"), field_sources ({field: page address or "user"}), enclosed_note (what the sheet says about printing in an enclosed printer), note. The entry is checked like the shipped catalog. The same id replaces a user entry; the id of a shipped filament is refused with another id to use, and a name or alias of a shipped filament with another product name or alias. Other entries stay. Returns: ok, path, profile, created, replaced, note, problems (of the rest of the file). A wrong argument name or value gives {"ok": false, "error": ...}; nothing is written. A file that is not valid YAML is not changed. There is no CLI command: edit the file.

Input Schema

NameRequiredDescriptionDefault
profileYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.7/5.0
Behavior4/5

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

Goes well past the annotations: it discloses that only that file is written, that the file is re-read on each call so entries are live immediately, that the same id replaces a user entry while shipped ids/aliases are refused with a suggested alternative, and that other entries are untouched. It also specifies the success payload (ok, path, profile, created, replaced, note, problems) and the error contract (`{"ok": false, ...}` writes nothing, invalid YAML is left unchanged) — consistent with destructiveHint=true and idempotentHint=true rather than contradicting them.

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 purpose, usage ordering, and the unknown-value policy before the field specification, and almost every sentence earns its place given the empty schema. The optional-field enumeration is a dense run-on list, which hurts scanability but is unavoidable without machine-readable property descriptions.

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?

For a write tool with a single untyped nested object, no output schema, and annotations that only flag destructiveness, the description supplies everything needed: trigger, user-consent step, full field contract, source-provenance rules, validation behavior, replacement/refusal semantics, and return shape. Nothing material is missing.

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 description coverage is 0% and the single `profile` parameter is a free-form object with no property documentation, so the description carries the entire burden — and does: required keys (id slug format with example, maker, product, family, source_url or source "user"), run-required quantities (modulus via E_xy/E_z or bending modulus, density in g/cm3), and an enumerated optional set with units, ranges, enums, and semantics for every field.

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 opening states a specific verb, resource, and destination: keep a filament absent from the catalog, with facts and sources, in `topopt-filaments.yaml` in the work folder, and scope-limits it to that one file. It is clearly distinguishable from the sibling `find_material` (which is the lookup it follows) and from `save_printer`/`save_preferences`.

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?

Explicit trigger and precondition: "Use it after `find_material` says 'none'", plus a prescribed procedure (look up the maker's data sheet, show values with the page address, call after the user agrees). It also names the alternative path for unknown values and the refusal cases (shipped id / shipped alias) with the required remedy.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.