Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

whereami

Locate the player's position and nearby surroundings from a Satisfactory save, then use near:me@ as a source selector in planning tools to focus work on that area.

Instructions

Where the player is standing, and what is around them.

Position comes from the Char_Player_C pawn in the save, so it is wherever you were when it was written -- an autosave can be several minutes stale. Use near:me@<radius> as a source selector in the planning tools to scope work to here.

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
radius_mNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the data source (Char_Player_C pawn) and a real behavioral caveat (autosave can be minutes stale), which is genuinely valuable. However, it says nothing about the shape or fields of what is returned, leaving the read behavior half-described.

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 tight sentences, front-loaded with the core purpose followed by caveat and cross-tool usage. Little waste, though the second sentence is slightly run-on.

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

Completeness2/5

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

No annotations and no output schema, with 5 parameters at 40% coverage, mean the description must do more. It covers staleness and the near:me idiom well but never describes return contents or the save/world/radius_m parameters, leaving an agent unable to predict the output.

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 coverage is only 40%: as_of and limit are documented in the schema, but save, world, and radius_m are not. The description hints at a radius concept via 'near:me@<radius>' but does not explain save, world, or how radius_m maps to 'what is around them', so it fails to compensate for the coverage gap.

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+resource: reporting the player's position and surroundings. It is clearly distinguishable from siblings like describe_location or world_summary, though it never explicitly names an alternative to disambiguate.

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 gives clear context for use (staleness of the pawn-derived position) and even steers the agent toward 'near:me@<radius>' as a source selector in the planning tools. It stops short of explicit when-not-to-use guidance versus e.g. ui_context or describe_location.

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