Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

factory_map

Map factories in a Satisfactory save by combining power islands, belt topology, and foundation slabs to propose named and candidate locations, with selectors to resolve overlaps.

Instructions

Proposed factories, from power islands and belt topology, plus what is named.

Three independent signals are reported rather than one answer, because none is right alone: power islands separate outposts but leave a grown-together base as one 476-machine blob; belt components shatter that blob into fragments; foundation slabs are the sharpest of the three but say nothing about the ground-built parts of a factory. Where they disagree, carve the difference with name_factory and a product:, near: or slab: selector.

show=slabs also lists BARE platforms -- poured foundations carrying no machine yet -- with tile count, extent, bounding box and elevation, because a freshly built platform is a real place a build plan refers to. Pads under a stated tile threshold are summarised in one line.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
saveNo
showNocandidates | named | slabs | unlabelled | allall
as_ofNopin to one world state: a sav:… token from an earlier answer
limitNomax rows (hard cap 25)
worldNo
offsetNo

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

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose real behavior: three signals are reported rather than one merged answer, each with known failure modes (476-machine blob, shattered fragments, no coverage of ground-built parts). It also states that show=slabs includes bare platforms with tile count, extent, bbox and elevation, and that small pads are collapsed to one line – useful return-shape context.

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?

Purpose is front-loaded, which is correct, but the second sentence is a long unpacked clause chain ('because none is right alone: … blob; … fragments; … slab') that costs the reader effort for the information delivered. The show=slabs paragraph earns its place; the signal-disagreement sentence is bloated relative to its content.

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 and no annotations, the description has to describe both behavior and returns, and it partly does: the three-signal model, the slabs listing detail, and the bare-platform fields. It leaves the `save`/`world`/`offset` parameters and the overall response shape of the candidates/named modes unexplained, so it is solid but not fully complete for a 6-parameter tool.

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 50%, with `show` and `as_of`/`limit` already documented in the schema. The description expands meaning for `show=slabs` beyond the bare enum list, which is real added value, but says nothing about `save`, `world`, or `offset`, leaving half of the parameter surface to the schema alone. Baseline 3 is appropriate.

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 first sentence names a specific resource – proposed factories – and the mechanism (power islands and belt topology) plus the naming overlay, which is more than a restatement of the name. It implicitly separates this from list_factories/propose_factories, but never names a sibling outright, so an agent must infer the boundary.

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 one actionable route – when the three signals disagree, use `name_factory` with a product:/near:/slab: selector – which is genuine usage guidance. However, it never says when to reach for factory_map rather than factory_query, factory_sites, or list_factories, all of which sit adjacent in the sibling set.

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