Skip to main content
Glama

Edit a formula's lines

edit_formula

Use this when the user wants to change a formula on their bench: add or remove a material, set an amount or a bottle strength, swap a material, flag or note a line, reorder, or scale the whole formula. Changes the working copy in place, as one hand edit in the editor does. No version is made; undo_last_change reverses the change, save_version keeps a version when the user asks. Only when a batch was made from the working copy does the first change start one new working version (the result says so). A formula open in the app updates within seconds. Lines are named by material or id. For add/set_amount always specify unit: g is a weighed amount; % is the final weighed share of the whole formula (including solvent, not the pure aromatic relative/absolute percent). Other weighed lines are held fixed; several % targets are solved together. Never copy relativePct or absolutePct as grams. Read get_formula first and use weighedPct for this kind of percentage edit. Whole-formula scale changes weight while preserving the recipe ratios; use scale_to_concentration to change finished concentration. Adding a specified solvent amount preserves existing ingredient amounts and increases the total weight.

Input Schema

NameRequiredDescriptionDefault
formulaYesThe formula: its id (from list_formulas) or its exact name.
operationsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / operations / items / properties / dilutionPct / description
      Added value: +"Strength of the stock bottle used by this line, not the finished formula concentration. This does not make a physical stock dilution."
    • addedInput schema / properties / operations / items / properties / factor / description
      Added value: +"For scale: the explicitly requested multiplier of all weighed amounts, not a concentration percentage."
    • addedInput schema / properties / operations / items / properties / totalGrams / description
      Added value: +"For scale: the explicitly requested final total weight in grams, preserving recipe ratios. Not a concentration percentage."
  2. Changed3 schema fields changed
    • addedInput schema / properties / operations / items / additionalProperties
      Added value: +false
    • addedInput schema / properties / operations / items / properties / amount / description
      Added value: +"Amount in the explicit unit; never infer grams from a percentage."
    • addedInput schema / properties / operations / items / properties / unit
      Added value: +{
      +  "description": "For add/set_amount: g or % for a weighed formula, part/drop only for a line already in that native unit. Legacy omission keeps its native unit, never percent.",
      +  "enum": [
      +    "g",
      +    "%",
      +    "part",
      +    "drop"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say it is a non-read-only, non-destructive, non-idempotent mutation. The description goes well past that: it edits a working copy in place, makes no version, is reversible only via undo_last_change, may start one new working version when a batch exists, and propagates to the open app within seconds. It also warns that % targets are solved jointly while other weighed lines stay fixed.

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 when-to-use clause and the operation list are front-loaded, and nearly every sentence carries an operational rule. It is a dense wall of text, however, with versioning, unit semantics, and scaling rules interleaved rather than separated, which costs a small amount of scannability.

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 mutation tool with no output schema and a 50%-documented schema, the description covers reversibility, versioning side effects, UI propagation timing, unit semantics, and the scaling-versus-concentration boundary. An agent has enough to invoke it correctly and to route adjacent requests elsewhere.

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 only 50%, but the prose compensates on exactly the ambiguous fields: 'unit' semantics (g weighed vs % final weighed share including solvent, not the aromatic relative/absolute percent), 'factor'/'totalGrams' meaning for scale, dilutionPct as bottle strength, and lines addressable by material name or id. It explicitly warns never to copy relativePct/absolutePct as grams.

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 description opens with a specific verb and resource ('change a formula on their bench') and then enumerates the concrete edits: add/remove a material, set amount or bottle strength, swap, flag, note, reorder, scale. An agent can distinguish it from update_formula, save_version, undo_last_change, and scale_to_concentration without opening any schema.

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?

It gives an explicit trigger ('Use this when the user wants to change a formula'), an explicit prerequisite ('Read get_formula first and use weighedPct for this kind of percentage edit'), and names the alternatives for adjacent jobs: undo_last_change to reverse, save_version to persist, scale_to_concentration to change finished concentration.

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