Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

factory_map

Read-onlyIdempotent

Map factories in a Satisfactory save by combining power islands, belt components, and foundation slabs into candidate and named factories, then refine disagreeing boundaries with edit_factory.

Instructions

Raw factory signals: power islands (base:), belt components (line:), foundation slabs (slab:).

Also the named factories. Islands merge a grown-together base, belt components fragment it, slabs are sharpest but miss ground-built machines; propose_factories combines them. Where they disagree, carve with edit_factory and a product:, near: or slab: term. show=slabs also lists bare platforms (foundations with no machine) with tile count, extent and elevation.

Input Schema

NameRequiredDescriptionDefault
saveNo
showNocandidates | named | slabs | unlabelled | allall
as_ofNopin to one save: the sav:… token an earlier answer printed
limitNo
worldNo
offsetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changedv0.3.0
    • 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"
+]
    • 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 / show / title
      Removed value: -"Show"
    • 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_mapArguments"
  2. 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"
+}
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real substance: islands over-merge grown-together bases, belt components fragment, slabs are sharpest but miss ground-built machines, and show=slabs returns tile count, extent and elevation. That is meaningful disclosure about data quality and return shape beyond the annotations.

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?

Three short paragraphs, signal definitions front-loaded before the comparison guidance and the show=slabs detail. Dense jargon, but every clause carries information; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, no-output-schema tool the conceptual model is well conveyed, but half the parameters are unexplained and the description never indicates what the result looks like (e.g. how signals are grouped or paginated by limit/offset). Adequate, with clear gaps remaining.

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 coverage is only 33% across 6 parameters, so the description must compensate. It does explain show's slabs mode and implicitly maps candidates to the three signal types and named to named factories, but save, world, limit and offset are left entirely to the (sparse) schema. Partial compensation only.

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 description names the concrete signals returned (power islands base:<n>, belt components line:<n>, foundation slabs slab:<n>) plus named factories, which is far more specific than the tool name alone. It implicitly distinguishes itself from propose_factories by framing itself as the raw-signal source rather than the synthesizer.

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 routes the agent: propose_factories combines the signals, and when sources disagree you carve with edit_factory using a product:, near: or slab: term. It also flags a specific mode (show=slabs lists bare platforms). It does not cover when to prefer list_factories or factory_query, so not a full 5.

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