Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

factory_health

Measure per-machine uptime and diagnose why each halted machine halted: starved, blocked, stalled, paused, dead node, or unreachable by wire.

Instructions

Measured uptime per machine, and WHY each stopped one is stopped.

The only measured numbers in this MCP. Every manufacturing building keeps a fixed 300-second productivity window; uptime is seconds-producing over that window.

States, worst first: paused, dead node (extractor bound to no resource -- a game update removed it), no recipe, blocked (output stack full), starved (input empty), stalled (has input, output has room, still not running), intermittent, saturated, unmonitored.

A stalled machine no generator can reach over the wires says so in its cause, and every such machine is named in a note whatever state it is in -- separately for "no wire at all" and "wired to a circuit no generator stands on", which are different builds to finish. The save records no "has power" flag, so a machine a generator CAN reach is never called unpowered here whatever the grid is doing: the wire is the only electrical fact the file carries.

For a STARVED machine it also says what physically feeds the input it lacks: the run that arrives, what stands at its far end and that feeder's own state, ONE hop back -- trace_upstream walks the rest. "No conduit of that medium arrives" and "one arrives and the save joins its far end to nothing" are different rows and are never merged.

A missing FLUID is diagnosed on the plumbing manual's own ladder -- (1) connection, (2) head lift, (3) flow rate -- and the cause names the FIRST rung that fires, so a line that cannot climb to the machine is never answered with its supply rates. Solids have no head-lift rung and read exactly as before.

Blocked counts as needing action, alongside dead node, no recipe, starved and stalled: a full output box means nothing is taking what the machine makes. The sweep's todo column counts those five.

The sweep over every factory also reports three plumbing faults that belong to no machine set: fluid buffers holding too little to output at their intake rate, pipeline pumps no wire reaches, and points where a line climbs above the head lift pushing it. All three are world-wide there, not scoped to a factory.

offset pages every table in the answer at once, worst first throughout.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
saveNo
as_ofNopin to one world state: a sav:… token from an earlier answer
limitNomax rows (hard cap 25)
worldNo
offsetNo
factoryNoa label name, any selector, or 'all' for every named factoryall

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

A4/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 behavioral burden and does so richly: it enumerates the state taxonomy worst-first, defines the `cause` semantics, explains that blocked/dead node/no recipe/starved/stalled feed the `todo` count, and describes how `offset` pages every table at once. It also discloses a genuine data limitation (the save records no 'has power' flag, so the wire is the only electrical fact) and that fluid diagnosis follows a fixed ladder. This is unusually complete behavioral disclosure.

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

Conciseness3/5

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

The key purpose sentence is correctly front-loaded, but the body is dense, jargon-heavy prose with long dependent clauses ('A stalled machine no generator can reach over the wires says so in its `cause`…') that is hard to parse quickly. Most content relates to real behavior, but the length-to-clarity ratio is poor for an agent scanning for a decision.

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 diagnostic with no output schema, no annotations, and only 50% schema coverage, the description does describe the returned shape (per-machine states and causes, the sweep's `todo` column, world-wide plumbing faults). It is nearly complete, with the only real gap being the unexplained `save` and `world` inputs.

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 50%, so the description must compensate for undocumented params. It does explain `offset` meaningfully ('pages every table in the answer at once, worst first'), which the schema leaves bare, and it implies the sweep semantics behind `factory`='all'. However, `save` and `world` receive no explanation, and `as_of`/`limit` are already covered by the schema. Partial compensation lands at the baseline 3.

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 thing measured (uptime per machine) and the diagnostic question it answers (why each stopped machine stopped), which is a clear verb+resource for an inspection tool. It also scopes itself against the sibling `trace_upstream` ('walks the rest'), so an agent can tell where this tool ends. It does not explicitly differentiate itself from adjacent reporting siblings such as `power_report` or `factory_query`, which keeps it at 4 rather than 5.

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?

Usage context is clear: reach for this to find why machines stopped, and use `trace_upstream` to walk beyond the one hop this tool provides. It also explains that the world-wide sweep surfaces three plumbing faults not scoped to a factory. There is no explicit when-NOT-to-use statement or comparison to `power_report`/`factory_query`, so no exclusions are drawn.

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

Deploy Server

Other Tools