Skip to main content
Glama

plan_layout

Turn a factory plan into a buildable schematic with blocks, buses, and floors. It organizes modules by throughput and assigns floor depths for Satisfactory builds.

Instructions

Turn a plan into a buildable schematic: blocks, buses and floors.

Same arguments as plan_factory, plus show: "floors" (default, the stack), "blocks" (every module with its size and rates), "buses" (item flows), "trunks" (which resource nodes share each pipe or belt run into the site), "materials" (what the whole thing costs to build, machines plus deck), or "sites" (cut the plan into named modules and report what crosses between them).

This is a SCHEMATIC, not a blueprint. It gives modules, connections, floor assignment and a space budget. It deliberately does NOT give world coordinates or belt routing -- there is no terrain data here, so those would be invented.

Blocks are split by throughput: 46 Refineries needing 1380 m3/min of crude cannot share one manifold when a Mk2 pipe carries 600, so that is 3 blocks. Floors follow chain depth, with a logistics deck between each pair of production floors.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNorecall a saved plan by name
saveNo
showNofloors | blocks | buses | trunks | materials | sitesfloors
as_ofNopin to one world state: a sav:… token from an earlier answer
limitNomax rows (hard cap 25)
sitesNoshow="sites": {"rig": ["Heavy Oil Residue", ...], "hall": ["MW"]} -- MW/power claims every generator
worldNo
clocksNo
detailNoretired -- write show= instead
sloopsNoSomersloops the plan may spend; 0 spends none
exportsNo
factoryNofit the layout against this factory's existing platform
sourcesNo
belt_tierNobelt tier name; blank = the fastest you have unlocked
objectiveNomax_mw
pipe_tierNopipe tier name; blank = the fastest you have unlocked
allow_sinksNo
target_itemNo
only_recipesNo
exclude_recipesNo
export_minimumsNo
machine_cost_mwNo
only_free_nodesNo
order_floors_byNo"chain" (build order) or "head" (minimise fluid lift)chain
extractor_clocksNo
water_extractorsNohow many Water Extractors your site can actually hold
max_floor_foundationsNocap a deck at this many 8m foundations; 0 = one stage per deck

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 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 / detail / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / detail / default
      Previous value: -"floors"New value: +null
    • addedInput schema / properties / detail / description
      Added value: +"retired -- write show= instead"
    • removedInput schema / properties / detail / type
      Removed value: -"string"
    • addedInput schema / properties / show
      Added value: +{
      +  "default": "floors",
      +  "description": "floors | blocks | buses | trunks | materials | sites",
      +  "title": "Show",
      +  "type": "string"
      +}
    • changedInput schema / properties / sites / description
      Previous value: -"detail=\"sites\": {\"rig\": [\"Heavy Oil Residue\", ...], ...}"New value: +"show=\"sites\": {\"rig\": [\"Heavy Oil Residue\", ...], \"hall\": [\"MW\"]} -- MW/power claims every generator"
  2. First observedv0.1.0

TDQS

A4/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 does real work: it discloses the deliberate omissions (no world coordinates, no belt routing, because no terrain data) and explains the derivation rules (blocks split by throughput, floors follow chain depth with logistics decks between). It does not state whether the operation is read-only/side-effect-free or what cost/preconditions exist, so a 4 rather than 5.

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 with the core purpose, then the `show` modes, then the deliberate exclusions, then the derivation rationale. Sentences are dense but each earns its place. Slightly long, and the blocks/floors rationale paragraph could be trimmed, but structure is sound.

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

Completeness3/5

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

For a 27-parameter tool with no annotations, no output schema and 48% schema coverage, the description covers purpose and output modes well but leaves more than half the parameters and the entire side-effect/precondition surface unexplained. The 'same as plan_factory' pointer helps but shifts burden onto the sibling's definition.

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?

Only 48% of 27 parameters are schema-documented, so the description must compensate. It richly explains `show` (the main control) and clarifies blocks/floors semantics, and defers the rest via 'Same arguments as plan_factory'. But many meaningful parameters (objective, allow_sinks, exports, sources, clocks, only_recipes, machine_cost_mw) get no explanation in either place, leaving the agent guessing.

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 opening sentence states a concrete transformation (plan -> buildable schematic) and then enumerates the six output shapes via `show`. It explicitly positions itself against the sibling plan_factory ('Same arguments as plan_factory, plus show'), so the agent can distinguish it without opening either schema.

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 tells the agent what the tool is for and names the alternative it extends (plan_factory), and it rules out a class of use cases ('schematic, not blueprint... no world coordinates or belt routing'), implicitly routing coordinate-level needs elsewhere. It does not give an explicit when-not-to-use clause or name the sibling that provides coordinates, so it stops short of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.