Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

propose_factories

Proposes factory groupings from your Satisfactory save by analyzing connectivity and shared resources, then use name_factory to label them. Helps identify unnamed builds.

Instructions

One coherence score over every signal, agglomerated into proposed factories.

Combines foundation slabs, proximity, belt connectivity, shared products and supply links. Validated leave-one-factory-out against the player's twelve hand-named factories: precision 1.000, recall 0.945, and precision was 1.000 on every fold -- it never merges two factories, it only ever splits one.

Use name_factory on what it proposes. unnamed_only=True answers "what have I built and not named". The # column is the proposal:<n> selector every other tool takes, and it counts over ALL proposals -- so it does not shift when you page.

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
max_span_mNocap on a proposal's diameter, metres
unnamed_onlyNo

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

B3.4/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 discloses several key traits: the signals combined, validation metrics, that it never merges factories but only splits them, and that the '#' column remains stable across pagination. It stops short of explicitly confirming read-only behavior or explaining whether any persistent state is modified.

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?

The purpose is front-loaded in the first sentence, and the rest is mostly useful behavioral context. The validation statistics are somewhat verbose, but they support trust in the proposal quality and do not bury the main point.

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 7-parameter tool with no annotations and no output schema, the description covers core behavior, follow-up action, and unnamed filtering adequately. It remains incomplete on several input parameters and does not fully describe output structure or side effects.

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

Parameters2/5

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

Schema description coverage is only 43%, so the description needs to compensate but largely does not. It explains unnamed_only and pagination stability, but leaves save, world, as_of, offset, and max_span_m without added meaning beyond the sparse schema descriptions.

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 states a specific verb and resource: it proposes factories by agglomerating a coherence score over signals. It is clearly not a general factory-list or query tool, but it does not explicitly differentiate itself from siblings like factory_query or list_factories.

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 follow-up guidance ('Use name_factory on what it proposes') and a use case for unnamed_only=True ('what have I built and not named'). However, it does not state when to call this tool instead of alternatives such as factory_query or list_factories.

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