SatisfactoryMCP

by lukszi

Overview Schema Source Related Servers Discussions Admin

Python

Local

factory_health

Read-onlyIdempotent

Diagnose why machines are stopped: check measured uptime and each stopped machine's cause, with all-factory sweeps.

Instructions

Why machines are stopped: measured uptime per machine and each stopped one's cause; 'all' sweeps.

Uptime: share of the save's 300 s productivity window spent producing. States, worst first: paused, dead node (extractor on no resource), no recipe, blocked (output full), starved (input short), stalled (input and room, still not running), intermittent, saturated, unmonitored; todo counts the first five. A machine no generator reaches over the wires says so (no wire, or a circuit with no generator); a reachable one is never called unpowered. A starved machine names its missing input's feeder one hop back (the run, its far end, that feeder's state); trace_upstream walks further. A missing fluid is diagnosed on the plumbing ladder: connection, head lift, flow rate; the first failing rung is the cause. factory='all' adds world-wide plumbing faults: fluid buffers too low to output at intake rate, unwired pipeline pumps, lines above head lift. offset pages every table at once.

Input Schema

Name	Required	Description	Default
`save`	No
`as_of`	No	pin to one save: the sav:… token an earlier answer printed
`limit`	No
`world`	No
`offset`	No
`factory`	No	a factory name, one selector term, or 'all' for every named factory	all

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv0.3.0Oct 31, 2026

removedInput schema / properties / as_of / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

changedInput schema / properties / as_of / description

Previous value: -"pin to one world state: a sav:… token from an earlier answer"New value: +"pin to one save: the sav:… token an earlier answer printed"

removedInput schema / properties / as_of / title
```
Removed value: -"As Of"
```
addedInput schema / properties / as_of / type
```
Added value: +[
+  "string",
+  "null"
+]
```

changedInput schema / properties / factory / description

Previous value: -"a label name, any selector, or 'all' for every named factory"New value: +"a factory name, one selector term, or 'all' for every named factory"

removedInput schema / properties / factory / title
```
Removed value: -"Factory"
```
removedInput schema / properties / limit / description
```
Removed value: -"max rows (hard cap 25)"
```
removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
addedInput schema / properties / offset / minimum
```
Added value: +0
```
removedInput schema / properties / offset / title
```
Removed value: -"Offset"
```

removedInput schema / properties / save / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / save / title
```
Removed value: -"Save"
```

addedInput schema / properties / save / type

Added value: +[
+  "string",
+  "null"
+]

removedInput schema / properties / world / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / world / title
```
Removed value: -"World"
```
addedInput schema / properties / world / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / title

Removed value: -"factory_healthArguments"

Changed2 schema fields 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"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}

First observedv0.1.0Aug 2, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already establish a safe read-only, idempotent operation, and the description goes well beyond that: it defines uptime against the 300 s productivity window, enumerates the state taxonomy worst-first, explains the fluid diagnosis ladder, and describes offset paging across all tables. It does not mention cost, latency, or how 'save' vs 'as_of' select a world, which keeps it from a 5.

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 purpose is front-loaded in the first line, but the remainder is a dense block of domain jargon with no bullets or grouping, making the state taxonomy and fluid ladder slow to parse. Little text is wasted, yet the presentation is hard to scan.

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?

With no output schema, the description carries the return-value burden and does so thoroughly: uptime meaning, state ordering, starvation back-tracking, and fluid diagnosis rung. It is weaker on parameter-level completeness and on how save/as_of pin a snapshot, leaving some agent-facing questions open.

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?

With only 33% schema coverage across 6 parameters, the description must compensate. It meaningfully explains factory ('a name, a selector term, or all') and offset ('pages every table at once') but leaves save, world, and limit unexplained, and does not clarify when to use 'as_of' versus 'save'.

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 clause names a specific verb and resource: measuring uptime per machine and attributing each stopped machine's cause. That distinguishes it from siblings like power_report or factory_query. It never explicitly contrasts its own scope with those siblings, so it stops short of a 5.

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 hints at routing ('factory=all sweeps', 'trace_upstream walks further') but never states when to pick this tool over factory_query, power_report, or trace_upstream. Usage context is implied by the described outputs rather than declared.

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

factory_health

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools