Skip to main content
Glama

PerfuMate

by app.perfumate
OverviewDiscussionsAdmin

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.

Input Schema

TableJSON 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 / 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"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare the mutation/non-idempotent/non-destructive profile. The description adds substantial context beyond that: in-place editing of the working copy, no version creation, the behavior when a batch was made from the working copy, app update timing, and the percentage-solving rules for weighed targets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary use case and packs multiple high-value distinctions into dense but purposeful sentences. Every sentence (unit semantics, version behavior, percentage solving, line naming) earns its place for a tool with nine operations.

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 complex, multi-operation mutation tool with no output schema, the description covers workflow, versioning, and percentage semantics well. It could go further by mapping which fields each operation requires (e.g., swap needs newMaterial, set_flag needs flag/line), which would reduce reliance on schema inference.

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 50%, so the description must compensate. It gives critical semantics for the unit field (g as weighed amount vs. % as final weighed share including solvent, not the pure aromatic relative/absolute percent), warns never to copy relativePct/absolutePct as grams, and tells the agent to use weighedPct from get_formula for percentage edits.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('change a formula on their bench') and enumerates supported line operations, so the agent understands the scope. It names alternatives like undo_last_change and save_version, but does not distinguish from the sibling update_formula, leaving a potential routing ambiguity.

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?

Explicitly says 'Use this when the user wants to change a formula on their bench' and lists the qualifying operations. It names undo_last_change for reversal and save_version for keeping a version, and directs the agent to read get_formula first—clear when/when-not guidance.

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

All PerfuMate toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources