Skip to main content
Glama

diff_vs_save

Compare your current save against a planned factory to see exactly what to change. Get ordered actions: unpause idle machines, set recipes, and build missing ones.

Instructions

What to change to get from the factory you have to the one plan_factory plans.

Takes exactly plan_factory's arguments and re-solves, because the server keeps no state. Both tools print a plan id hashed over the arguments AND the save-derived solve inputs, so two responses carrying the same id are provably the same plan.

Machines are matched by IDENTITY, never by position: a manufacturer on (building, recipe), a generator on its building alone since its fuel is piped in rather than set on the machine, an extractor on the node it occupies. A Refinery running some other recipe is busy, not spare, so it never counts toward the plan.

Actions are ordered free-first -- UNPAUSE, then SETRECIPE on machines that produce nothing today, then BUILD. Stages follow the plan's own chain depth and the power arithmetic is INCREMENTAL, charging only the machines you have yet to place. Where a machine cannot be identified at all (Water Extractors have no recipe and no resolvable node) the answer is a RANGE, never a number.

Recall a stored plan with plan= and the diff is also grouped by STARTUP STAGE -- the same partition commission_plan emits -- so it answers "which stage am I in". stage=<n> narrows to one stage's delta; stage=0 asks for the overview without a stored plan, at the cost that the numbering moves when the arguments do.

Built and energised are DIFFERENT states and the save separates them in one direction only: a machine that produced in the last 300s window certainly had power, while one that did not may be unpowered, starved, blocked or idle. Grid membership is not persisted at all, so a stage is never reported as "unpowered" -- only as built with nothing proven running, which is exactly what a finished but not-yet-energised block looks like.

Saves are read-only: this never proposes writing one, and there is no dismantle action. Machines standing among the plan but not in it are listed for you to judge.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNorecall a saved plan by name
saveNo
limitNomax rows (hard cap 25)
stageNoone startup stage's delta; 0 for the stage overview
worldNo
clocksNo
exportsNo
factoryNoonly count this factory's machines as already built
sourcesNo
objectiveNomax_mw
show_costNo
allow_sinksNo
target_itemNo
only_recipesNo
exclude_recipesNo
export_minimumsNo
machine_cost_mwNo
only_free_nodesNo
extractor_clocksNo
Behavior5/5

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

The description is exceptionally transparent: it states the server keeps no state, actions are ordered free-first, power arithmetic is incremental, and machines are matched by identity rather than position. It also discloses that saves are read-only and there is no dismantle action, plus the limitation that built vs energized states are one-directional.

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 long but information-dense; each sentence adds a distinct behavioral detail. It could benefit from bullet points, but the prose is organized around matching, ordering, and state semantics, and contains little fluff.

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?

Given 19 parameters, no annotations, and no output schema, the description covers a great deal of behavior: identity matching, action ordering, incremental power, ranges for unidentifiable machines, stage grouping, and state semantics. It stops short of describing the full response structure, but within its scope it is largely complete.

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?

It says 'takes exactly plan_factory's arguments and re-solves', which orients users to borrow parameter knowledge from plan_factory. It also clarifies `plan=` and `stage=` beyond the schema (hash identity, stage numbering movement). However, it does not individually describe most of the other 17 parameters.

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 phrase 'What to change to get from the factory you have to the one plan_factory plans' clearly identifies a diff operation between the current factory/save and a planned factory. It references plan_factory as the source of the target plan, distinguishing it from sibling tools.

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?

It explicitly instructs how to recall a stored plan with `plan=` and how to narrow to a stage with `stage=<n>`, including special meaning of `stage=0`. It relates the stage grouping to commission_plan's partition, giving cross-tool context, though it does not state when not to use this tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lukszi/SatisfactoryMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server