Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

trace_upstream

Read-onlyIdempotent

Trace what feeds a machine, factory, or building—or what it feeds—through save connections from a seed to reveal upstream/downstream dependencies before repiping or rerouting.

Instructions

What feeds a machine, factory or building type, or what it feeds, walked on the save's connections.

factory_query show=links answers this between named factories; this walks from one seed, e.g. which feed can be repiped without dropping the generators behind it. Direction is read from connector roles or the machine's nature; an edge with neither is walked both ways, so a feeder may be over-reported, never missed. Belts and pipes are walked through, not listed; a note names the runs crossed by the chain:/pipe: ids search_conduits takes.

Input Schema

NameRequiredDescriptionDefault
saveNo
seedYesmachine:<instance> (or the bare instance), a factory name, or a building name
as_ofNopin to one save: the sav:… token an earlier answer printed
limitNo
worldNo
directionNoup (what feeds it) | down (what it feeds)up

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 / direction / title
      Removed value: -"Direction"
    • removedInput schema / properties / limit / description
      Removed value: -"max rows (hard cap 25)"
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • 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"
+]
    • changedInput schema / properties / seed / description
      Previous value: -"a machine instance, a factory label, or a building name"New value: +"machine:<instance> (or the bare instance), a factory name, or a building name"
    • removedInput schema / properties / seed / title
      Removed value: -"Seed"
    • 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: -"trace_upstreamArguments"
  2. Changed1 schema field 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"
+}
  3. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, so the description needn't restate safety. It instead contributes real behavior: direction is inferred from connector roles or machine nature, ambiguous edges are walked both ways so results may over-report but never miss, and belts/pipes are traversed rather than listed. The only shortfall is that result shape (per-node fields, truncation behavior) is only partially implied by the 'note' sentence.

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 before the sibling comparison and caveats, and there is no filler. The closing sentences are compressed to the point of being cryptic ('the runs crossed by the chain:/pipe: ids'), costing a little readability.

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?

With 6 parameters, no output schema, and a traversal that can over-report, the description does well on direction semantics, the over-report caveat, and the conduit-id note. But it never says how `limit` truncates a walk or what `save`/`world` scope to, which matter for calling a graph walk correctly.

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%: `seed` and `as_of` are documented, and `direction` is documented in the schema while the description adds real meaning about how direction is inferred. However `save`, `world`, and `limit` are undocumented in both places, and the description never explains what the limit cap does to a traversal. Adequate but leaves the 3 dark parameters unaddressed.

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 states a specific action-resource pair: traverse the save's connection graph from a seed to find what feeds a machine/factory/building, or what it feeds. It also explicitly distinguishes itself from the sibling `factory_query show=links` (named-factory pairs vs. a single-seed walk), so an agent can pick correctly. The phrasing ('walked on the save's connections') is slightly dense but the scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the alternative (factory_query show=links for queries between named factories) and the condition that selects this tool instead (walking from one seed). It adds a concrete motivating scenario ('which feed can be repiped without dropping the generators behind it') and points to search_conduits for the conduit ids the note prints.

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