Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_regions

List named map regions in Satisfactory, optionally filtered to those containing a specific resource, to help discuss locations based on game map areas.

Instructions

Named map regions, optionally only those containing a given resource.

Region names are ADVISORY: the boundaries are the game's own map areas, downsampled to a 256 m grid to publish and a 64 m one to look up in, so a name near a boundary can be one cell out. Use them to talk about places, not to compute with -- every node row also carries an exact grid cell.

anchor is a coordinate that provably lies in the region, which a centroid does not: a concave region's mean lands on its neighbour's ground, and the map has drawn its names at the anchor all along.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
resourceNo
with_resourceNoretired -- write resource= instead

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / resource
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Resource"
+}
    • addedInput schema / properties / with_resource / description
      Added value: +"retired -- write resource= instead"
  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 burden and discharges it well: it discloses that names are advisory, that boundaries are downsampled to a 256 m grid to publish and 64 m to look up, that a boundary-adjacent name can be one cell out, and that `anchor` provably lies inside the region whereas a centroid may not. These are exactly the behavioral traits an agent needs to avoid misusing the output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then two tightly scoped paragraphs that each add non-redundant value (advisory-boundary caveat, anchor-vs-centroid rationale). No filler sentences or restated titles.

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 two-parameter, read-only listing tool with no output schema and no annotations, the description covers the semantics and caveats of the returned data well. It could still say a little more about the shape of a region record beyond `anchor`, but nothing needed to invoke it correctly is missing.

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 50% and the description compensates: it explains that `resource` restricts results to regions containing that resource, and effectively reinforces the schema's note that `with_resource` is retired in favor of `resource=`. The `anchor` discussion concerns output fields rather than inputs, so it does not leave an input parameter uninterpreted.

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 exactly what is returned (named map regions) and the optional filter (those containing a given resource), which is enough to distinguish it from siblings like whereami, describe_location, or search_resource_nodes. It is a noun phrase rather than a verb-led statement, but the resource and scope are unambiguous.

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 explicitly tells the agent when to use the results ('to talk about places, not to compute with') and points to the alternative for computation ('every node row also carries an exact grid cell'). It does not name which sibling to call instead when exact geometry is needed, so it falls short of full when/when-not/alternative routing.

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