SatisfactoryMCP

Overview Schema Source Related Servers Discussions Admin

diff_vs_save

Compare a Satisfactory save against a planned factory and list required changes by startup stage, with incremental power costs.

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

Name	Required	Description	Default
`plan`	No	recall a saved plan by name
`save`	No
`as_of`	No	pin to one world state: a sav:… token from an earlier answer
`limit`	No	max rows (hard cap 25)
`stage`	No	one startup stage's delta; 0 for the stage overview
`world`	No
`clocks`	No
`exports`	No
`factory`	No	only count this factory's machines as already built
`sources`	No
`objective`	No		max_mw
`show_cost`	No
`allow_sinks`	No
`target_item`	No
`only_recipes`	No
`exclude_recipes`	No
`export_minimums`	No
`machine_cost_mw`	No
`only_free_nodes`	No
`extractor_clocks`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 27, 2026

addedInput schema / properties / as_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "pin to one world state: a sav:… token from an earlier answer",
+  "title": "As Of"
+}

First observedv0.1.0Aug 2, 2026

TDQS

A3.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and discharges it richly: identity-based matching rules, action ordering (UNPAUSE then SETRECIPE then BUILD), incremental power accounting, RANGE vs number for unidentifiable machines, the built-vs-energised asymmetry, non-persisted grid membership, and read-only saves with no dismantle action. This is exactly the kind of behavioral disclosure an agent needs.

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?

It is long, but the length is largely earned given the tool's conceptual complexity, and the first sentence leads with purpose. Paragraphing separates related concerns, though several sentences are dense enough that a skimming agent could lose the thread.

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?

There is no output schema and no annotations, yet the description explains the return shape well: plan-id hashing, stage-grouped diffs, RANGE answers, and provenance of sa: tokens. It is strong on concept but leaves many of the 20 parameters unexplained, which leaves the invocation surface incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25% across 20 parameters, so the description must compensate. It explains plan=, stage=, and factory= in prose and notes save handling, but leaves the majority of parameters (clocks, exports, sources, objective, show_cost, allow_sinks, target_item, recipe filters, machine_cost_mw, only_free_nodes, extractor_clocks, limit, world) unaddressed, so it only partially fills the gap.

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?

The opening line states a specific purpose: computing what to change to turn the current factory into the one plan_factory plans. It distinguishes itself conceptually from plan_factory (it re-solves using that tool's arguments) and from commission_plan (whose stage partition it reuses), but the verb 'diff' is never stated plainly and the purpose is embedded in dense prose rather than front-loaded as a one-line statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete usage cues: recall a stored plan with plan=, narrow with stage=<n>, use stage=0 for an overview without a stored plan. However it never frames when to reach for this tool versus plan_factory or commission_plan, and gives no exclusions or prerequisites beyond the read-only note.

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

diff_vs_save

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools