Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

show_on_map

Generate map links centered on any factory, node, or resource to view your own save or the vanilla world map.

Instructions

Map links centred on something: this project's own map, and the public one.

Two links for every place. The LOCAL one opens this project's web map, which draws the reader's own save -- their machines, their belts, their siting. The satisfactory-calculator.com one opens a third-party map of the vanilla world, which knows the terrain and the nodes and nothing the player built.

at is the same place vocabulary every other tool takes (see docs/selectors.md), plus one kind of its own: resource:<name> centres on the centroid of EVERY node of that resource and switches its overlays on, which is a viewport rather than a place and is why no other tool accepts it.

Only the Crude Oil layer tokens are confirmed; the rest follow the same pattern and are flagged. A wrong token still opens the map in the right place, just without that overlay.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atYesany place -- 'x,y' in metres, 'me', a factory label, 'node:<id>', 'slab:<n>', 'chain:<n>'/'pipe:<n>', 'plan:<name>' -- or 'resource:Crude Oil' for every node of one resource
saveNo
zoomNo
as_ofNopin to one world state: a sav:… token from an earlier answer
worldNo
layersNoexplicit sublayer tokens, overriding the guess

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 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 / at
      Added value: +{
+  "description": "any place -- 'x,y' in metres, 'me', a factory label, 'node:<id>', 'slab:<n>', 'chain:<n>'/'pipe:<n>', 'plan:<name>' -- or 'resource:Crude Oil' for every node of one resource",
+  "title": "At",
+  "type": "string"
+}
    • removedInput schema / properties / target
      Removed value: -{
-  "description": "'x,y' in metres, 'me', a factory label, a node id, or a resource name like 'Crude Oil'",
-  "title": "Target",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "target"
-]New value: +[
+  "at"
+]
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does so well: it discloses that two links are returned, what each exposes (saved base vs vanilla world), that `resource:` switches overlays, and that only Crude Oil layer tokens are confirmed while a wrong token still opens the map at the right place. Missing only auth/side-effect framing, though this is plainly a read-only link generator.

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?

Front-loaded with the two-link purpose, then scoped to the `at` vocabulary and token caveats. It is prose-heavy and a touch long, but each paragraph adds decision-relevant detail rather than filler.

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?

For a 6-parameter tool with no annotations and no output schema, the description adequately covers what the tool does, its return shape, and the key `at` semantics. The gaps are the undocumented save/zoom/world parameters, but the core invocation surface is well explained.

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%. The description adds real meaning for `at` (the `resource:<name>` kind, docs pointer) and for layer tokens/overrides, but `save`, `zoom`, and `world` are undocumented in both the schema and the description, leaving half the surface unaddressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: it produces two map links (local project map and the public satisfactory-calculator.com one) centred on a place. It clearly distinguishes what each link shows and names the sibling vocabulary it reuses, so an agent immediately knows what the tool yields.

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 explains the place vocabulary shared with other tools (docs/selectors.md) and the one `resource:<name>` exception, which implies usage. However it never states when to pick this tool over siblings like describe_location, whereami, or factory_map, nor any when-not condition.

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