Skip to main content
Glama
cacack

mcp-server-brewfather

by cacack

update_inventory_item

Edit details of a Brewfather inventory item such as name, type, supplier, or origin without changing stock levels; use set_inventory for stock adjustments.

Instructions

Edit an inventory item's details (not its stock — use set_inventory).

``kind`` is fermentables, hops, miscs, or yeasts. Only the given ``fields``
are written. Keys, all kinds: name, type, supplier, origin; plus
- fermentables: color (SRM), potential (SG, e.g. 1.037);
- hops: alpha (percent);
- miscs: unit, use;
- yeasts: attenuation (percent), laboratory, productId, form.

Returns {item_id, result}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
fieldsYes
item_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.1/5.0
Behavior3/5

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

No annotations, so the description carries the burden. It usefully discloses partial-update semantics ('Only the given fields are written') and the return shape, but says nothing about permissions, reversibility, error behavior, or whether omitted fields are preserved vs cleared.

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-loads the core action and the sibling distinction, then uses a compact per-kind bullet list. Dense but every line earns its place; the nested list is slightly heavy but appropriate for the parameter space.

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 3-param mutation with a nested object and a declared output schema, the description covers the important unknowns (partial write, kind-scoped field keys). Missing auth/reversibility context is a minor gap; output schema already covers return values.

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?

Schema coverage is 0%, so the description must compensate, and it largely does: it enumerates the 'kind' values and lists the valid 'fields' keys per kind with units and formats (SRM, SG, percent). Only item_id is left undescribed, which is intuitive from the name.

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+resource ('Edit an inventory item's details') and explicitly disambiguates from the sibling set_inventory ('not its stock — use set_inventory'). An agent can tell this apart from set_inventory and create_inventory_item without opening a schema.

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?

Names the alternative tool (set_inventory) and the exact condition that routes to it (updating stock). It gives clear context for when this tool applies, though it does not state exclusions relative to create_inventory_item or update_batch.

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