Skip to main content
Glama

ShotPulled

Update a grinder

update_grinder
Idempotent

Correct a registered grinder — its name, burrs, collar scheme, nominal step, layout, range or notes. Only the keys you send in fields change; send null to clear an optional field (an empty string also clears a text field, but not a number or a closed list). Required fields can be changed but not cleared. fields may be omitted when only reason is sent. setting_scheme, nominal_step and components_spec describe the collar every recorded grind label is read through: call with dry_run first to see which recorded settings would read as a different position, and tell the user before saving. Saving records the change in the grinder's maintenance history; when a locked recipe's setting moves it also opens an unmeasured calibration epoch (set_maintenance_offset resolves it). The collar's current setting is marked assumed when it reads differently, or cleared when the new collar cannot read it, and measured offsets are converted when a click changes worth. Changing direction_convention is a correction — it moves no number, but every finer/coarser said about this grinder was the wrong way round.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNo
reasonNoOptional note, appended to this record's own notes as an ordinary line. Omit it and nothing is written.
dry_runNotrue: write nothing, and answer with what the edit would do to the settings already recorded (moved[], checked, epoch, position_moved, position_cleared, rescaled_offsets, resigned_offsets, step_ignored, direction_flipped, recipe_count)
grinder_idYesThis account's own grinder number, from list_grinders. Never guess one.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
epochYes
movedYes
statusYes
checkedYes
dry_runYes
messageYes
entry_idYes
grinder_idYes
unreadableYes
moved_countYes
changed_keysYes
recipe_countYes
step_ignoredYes
reads_changedYes
position_movedYes
untranslatableYes
position_clearedYes
rescaled_offsetsYes
resigned_offsetsYes
direction_flippedYes
untranslatable_recipesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses many non-obvious side effects beyond the annotations: partial-update semantics, null/empty-string clearing rules, maintenance history recording, calibration epochs for locked recipes, current-setting marking/clearing, offset conversion, and direction_convention correction behavior. No contradiction with the annotations was found.

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 description is dense and information-rich with no filler, and it front-loads the core purpose. However, it is a long wall of text with awkward phrasing such as 'fields may be omitted when only reason is sent' and minor punctuation issues that make it harder to parse quickly.

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?

Given the tool's complexity, nested fields, side effects, and existing output schema, the description covers the necessary behavioral context: dry_run guidance, what happens to recorded settings, maintenance history, locked recipes, offsets, and direction correction. An agent has enough information to use the tool responsibly.

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?

Even with 75% schema coverage, the description adds substantial parameter-level meaning: only keys in fields change, null clears optional fields, empty strings clear text but not numbers or closed lists, required fields cannot be cleared, and fields can be omitted when only reason is sent. This goes well beyond the schema's field descriptions.

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 'Correct a registered grinder' and enumerates the editable attributes: name, burrs, collar scheme, nominal step, layout, range, notes. This clearly distinguishes it from create/read/set siblings and uses a specific verb and resource.

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?

The description makes the usage workflow explicit: call with dry_run first, review what would change, and tell the user before saving. It does not explicitly name sibling alternatives or list when not to use update_grinder, but the context is clear enough for an agent to route to it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources