Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

describe_location

Name the region, sample elevation and water depth, and count belts or pipes crossing a coordinate, factory, slab, or conduit run.

Instructions

Name the region at a place, sample its elevation, and count what runs through.

at= takes 'x,y' in metres, or anything else this project prints an id for: me, a named factory, slab:<n> from factory_map show=slabs -- including the bare platforms nothing else would take -- or a chain:/pipe: run from search_conduits.

Returns 'off-map or ocean' rather than guessing the nearest land region.

Elevation is answered two ways and the two are never averaged. Where this machine carries the extracted 1 m terrain field, terrain_m is one texel read at exactly this coordinate, with the layer that answered, that layer's measured accuracy, and the water surface and depth where water stands. Everything else is a SAMPLE population reported with its count and spread: resource nodes rest on terrain and are quoted as ground, foundations and buildings are quoted separately as built elevation because a platform is wherever the player put it, and the gap between the two is the fill already stacked there.

Belts and pipes are counted too, measured against the runs' drawn lines rather than their corner points, so a conduit crossing mid-span is seen. With a readable save, a zero here means nothing runs through -- absence in this output is absence in the world. search_conduits lists the runs themselves.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNothe place: 'x,y' in metres, 'me', a named factory, 'slab:<n>', or a run id like 'chain:7'
saveNo
as_ofNopin to one world state: a sav:… token from an earlier answer
worldNo
radius_mNohow far to look for known elevations, metres

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 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: +{
+  "default": "",
+  "description": "the place: 'x,y' in metres, 'me', a named factory, 'slab:<n>', or a run id like 'chain:7'",
+  "title": "At",
+  "type": "string"
+}
    • removedInput schema / properties / x_m
      Removed value: -{
-  "title": "X M",
-  "type": "number"
-}
    • removedInput schema / properties / y_m
      Removed value: -{
-  "title": "Y M",
-  "type": "number"
-}
    • removedInput schema / required
      Removed value: -[
-  "x_m",
-  "y_m"
-]
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: it states that off-map points return 'off-map or ocean' rather than a guessed region, explains that elevation is never averaged across two methods, describes the terrain_m texel read with layer/accuracy/water details, distinguishes ground vs built elevation for nodes vs foundations, explains that conduits are measured against drawn lines not corner points, and notes that a zero count means true absence with a readable save.

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 description is front-loaded with the core purpose and organized logically from input formats to behavior to a sibling note. It is somewhat long and contains a few dense, stylized phrases, but for a tool with five parameters, no annotations, and no output schema, most sentences add useful context 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?

Given high complexity, no annotations, and no output schema, the description covers return behavior extensively—region, elevation modes, conduit counting, and absence semantics. It leaves `save`, `world`, and `as_of` largely unexplained, which is a meaningful gap for a tool that supports pinning to earlier world states, but the overall behavioral picture is strong.

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

Parameters4/5

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

Schema coverage is 60%, and the description meaningfully extends the `at` parameter beyond the schema by specifying that it accepts 'x,y' in metres, `me`, a named factory, `slab:<n>` from `factory_map show=slabs`, or a `chain:`/`pipe:` run from `search_conduits`. It does not expand on `save`, `world`, `as_of`, or `radius_m`, so it only partially compensates for the coverage gap.

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?

The first sentence states a specific verb and three resources: name the region, sample elevation, count conduits. It later distinguishes this tool from `search_conduits` (which lists runs) and from `factory_map` (source of slab ids), so an agent can tell what makes this tool unique.

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 implies when to use the tool by describing what it returns, and it notes that `search_conduits` lists the runs themselves, but it never explicitly states when to choose this tool over alternatives like `whereami`, `show_on_map`, or `list_regions`. Usage is inferable, not spelled out.

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