Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

site_plan

Destructive

Record, update, or clear where a saved factory plan is sited—origin, yaw, and footprint—without re-solving; later map views and comparisons can centre on that pad.

Instructions

Record, update or clear where a saved plan stands (origin, yaw, footprint). Nothing is re-solved.

Origin is the footprint centre in metres; yaw is degrees about world Z as the save stores facing; footprint defaults to plan_layout's square for the largest floor, and the record says whether it was measured or derived. A siting is a record, not a constraint: re-solving ignores it, save_as over the same name keeps it. Once sited, recalls print it, diff_vs_save adds an approximate on-pad census, show_on_map at='plan:' centres on it.

Input Schema

NameRequiredDescriptionDefault
atNoorigin (footprint centre): 'x,y[,z]' in metres, 'me', a factory name, 'slab:<n>', 'chain:<n>'/'pipe:<n>'; blank keeps the stored one
planYesthe saved plan's name or pin:N
saveNo
as_ofNopin to one save: the sav:… token an earlier answer printed
clearNodrop the siting; the plan itself stays
worldNo
previewNoshow what the pad would meet there; writes nothing
yaw_degNodegrees about world Z, positive +X towards +Y; omit to keep
base_revNothe plan version you read; needed to change an existing plan
footprintNo'WxD' in metres ('96' = square); blank keeps the stored one, else the layout's square

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed26 schema fields changedv0.3.0
    • removedInput schema / properties / as_of / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • changedInput schema / properties / as_of / description
      Previous value: -"pin to one world state: a sav:… token from an earlier answer"New value: +"pin to one save: the sav:… token an earlier answer printed"
    • removedInput schema / properties / as_of / title
      Removed value: -"As Of"
    • addedInput schema / properties / as_of / type
      Added value: +[
+  "string",
+  "null"
+]
    • changedInput schema / properties / at / description
      Previous value: -"site origin (the footprint's CENTRE): 'x,y[,z]' in metres, 'me', a factory name, 'slab:<n>' or a run id. Blank keeps the stored origin"New value: +"origin (footprint centre): 'x,y[,z]' in metres, 'me', a factory name, 'slab:<n>', 'chain:<n>'/'pipe:<n>'; blank keeps the stored one"
    • removedInput schema / properties / at / title
      Removed value: -"At"
    • removedInput schema / properties / base_rev / anyOf
      Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / base_rev / title
      Removed value: -"Base Rev"
    • addedInput schema / properties / base_rev / type
      Added value: +[
+  "integer",
+  "null"
+]
    • addedInput schema / properties / clear / description
      Added value: +"drop the siting; the plan itself stays"
    • removedInput schema / properties / clear / title
      Removed value: -"Clear"
    • changedInput schema / properties / footprint / description
      Previous value: -"'WxD' in metres ('96' = square). Blank keeps the stored one, or derives the layout's own square if none is stored"New value: +"'WxD' in metres ('96' = square); blank keeps the stored one, else the layout's square"
    • removedInput schema / properties / footprint / title
      Removed value: -"Footprint"
    • addedInput schema / properties / plan / description
      Added value: +"the saved plan's name or pin:N"
    • removedInput schema / properties / plan / title
      Removed value: -"Plan"
    • removedInput schema / properties / preview / title
      Removed value: -"Preview"
    • removedInput schema / properties / save / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / save / title
      Removed value: -"Save"
    • addedInput schema / properties / save / type
      Added value: +[
+  "string",
+  "null"
+]
    • removedInput schema / properties / world / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / world / title
      Removed value: -"World"
    • addedInput schema / properties / world / type
      Added value: +[
+  "string",
+  "null"
+]
    • removedInput schema / properties / yaw_deg / anyOf
      Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / yaw_deg / title
      Removed value: -"Yaw Deg"
    • addedInput schema / properties / yaw_deg / type
      Added value: +[
+  "number",
+  "null"
+]
    • removedInput schema / title
      Removed value: -"site_planArguments"
  2. Changed1 schema field changedv0.2.0
    • addedInput schema / properties / preview
      Added value: +{
+  "default": false,
+  "description": "show what the pad would meet there; writes nothing",
+  "title": "Preview",
+  "type": "boolean"
+}
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the destructiveHint annotation, the description explains that this records metadata rather than re-solving, that the siting survives save_as, and that downstream tools read it. The schema adds specifics about clear and preview, but the description itself provides strong behavioral context for a mutation tool.

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 core purpose is front-loaded in the first sentence, and subsequent sentences explain non-obvious behavior. The prose is dense and uses domain-specific terms like recalls and on-pad census, but it is appropriately sized for a 10-parameter mutation tool.

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 complex mutation tool with no output schema, the description covers the key conceptual model, side effects, persistence behavior, and downstream consumers. It leaves some parameter details and return behavior to the schema, but the overall context is sufficiently complete.

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 high, and the description adds meaningful semantics beyond the schema for the key spatial parameters: origin is the footprint centre in metres, yaw is about world Z, and footprint defaults to plan_layout's square for the largest floor. It does not clarify every parameter, such as save or world, but it adds real value where it matters most.

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 gives a specific verb set (record, update, clear) and resource (where a saved plan stands), with the exact fields affected (origin, yaw, footprint). It also clarifies that nothing is re-solved, which sharply distinguishes this from solve/layout editing tools.

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?

The description gives clear usage context: a siting is a record, not a constraint; re-solving ignores it; save_as preserves it; and downstream tools such as recalls, diff_vs_save, and show_on_map consume it. It does not explicitly name when to choose this over edit_plan or plan_layout, but the intended context is clear.

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