Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

collected_from_world

Track which Satisfactory collectibles exist, which you collected, what remains, and the closest ones using map and save data.

Instructions

Map collectibles: how many exist, how many you took, what is left and what is closest.

Slugs, somersloops, Mercer spheres and their shrines, mushrooms, drop pods and the loot caches around them. Two sources, and neither is asked the other's question:

  • the map says what exists and where, read from the installed game's own cooked packages, so placed is exact and every coordinate is exact;

  • the save says what is gone. The world is not saved -- a save never mentions a slug still lying there -- so its destroyed-actor list is the collected list, and it is exact too. remaining is the subtraction of the two.

Views: census (default) counts every category; collected and remaining list individual placements with coordinates; nearest lists the remaining ones by distance from near, defaulting to the player.

A placement in a cell no save has ever loaded is counted as remaining and reported as never_streamed. It is never called present -- the map says where it is and nothing on disk says whether it is still there.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoretired -- write show= instead
nearNoorigin for show=nearest: 'x,y' in metres, 'me', or a factory name. Defaults to where the player is standing
saveNo
showNocensus | collected | remaining | nearestcensus
as_ofNopin to one world state: a sav:… token from an earlier answer
groupNoone category, e.g. 'power_slug_blue'. Omit to see them all
limitNomax rows (hard cap 25)
worldNo
offsetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 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 / mode / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / mode / default
      Previous value: -"census"New value: +null
    • changedInput schema / properties / mode / description
      Previous value: -"census | collected | remaining | nearest"New value: +"retired -- write show= instead"
    • removedInput schema / properties / mode / type
      Removed value: -"string"
    • changedInput schema / properties / near / description
      Previous value: -"origin for mode=nearest: 'x,y' in metres, 'me', or a factory name. Defaults to where the player is standing"New value: +"origin for show=nearest: 'x,y' in metres, 'me', or a factory name. Defaults to where the player is standing"
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
    • addedInput schema / properties / show
      Added value: +{
+  "default": "census",
+  "description": "census | collected | remaining | nearest",
+  "title": "Show",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A3.7/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: the two data sources, that the save's destroyed-actor list *is* the collected list, that 'remaining' is a subtraction, and the important never_streamed caveat. It stops short of stating read-only status explicitly or any permission/rate context.

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 summary followed by a well-structured explanation of the two sources and the view modes using bullets. Most sentences carry information; the source/never_streamed prose is slightly long but each part earns its place for a tool this nuanced.

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 9-parameter, annotation-free tool with no output schema, the description supplies the hard part: the conceptual model of where counts come from and what the views return. It is still incomplete on several parameters (save, world, offset) and does not indicate result shape for census.

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 67%, so the schema documents most parameters. The description adds meaning for 'show' (what each view returns), 'near' (origin defaulting to the player) and 'as_of' (pinning a world state), but leaves 'save', 'world' and 'offset' entirely unexplained in both description and schema.

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 opening line states a specific verb+resource and scope: a census of map collectibles covering slugs, somersloops, Mercer spheres, mushrooms and drop pods. It is clearly readable as 'count/list collectibles in the world'. It never differentiates itself from closely related siblings such as somersloops and power_shards, so it falls short of a 5.

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?

The description explains each view (census/collected/remaining/nearest) and when 'near' applies, which implies usage. However it never names an alternative tool or an explicit when-not-to-use condition, so the choice between this and the somersloops/power_shards siblings is left to inference.

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