Skip to main content
Glama

plan_layout

Turn a Satisfactory production plan into a buildable schematic: module blocks, item buses, floor layout, and material costs.

Instructions

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

Same arguments as plan_factory, plus detail: "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
limitNomax rows (hard cap 25)
sitesNodetail="sites": {"rig": ["Heavy Oil Residue", ...], ...}
worldNo
clocksNo
detailNofloors
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
Behavior4/5

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

With no annotations, the description carries the burden and does so well: it discloses the schematic-vs-blueprint scope, the absence of world coordinates/belt routing, throughput-based block splitting (with a concrete pipe-capacity example), and floor ordering with logistics decks. This is substantive behavioral context beyond simple action phrasing.

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 focused and front-loaded with the core purpose, then details modes and key constraints. The throughput example is concrete and illustrative, not filler. It is longer than two sentences but every sentence contributes useful information.

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?

Given the tool's complexity (25 params, no output schema), the description covers high-level outputs and constraints well but omits return format and many parameter details. It is adequate for selecting the tool but not fully comprehensive for invoking all options correctly.

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 only 40% across 25 parameters, and the description adds meaningful semantics mainly for the 'detail' parameter, explaining each mode. The phrase 'Same arguments as plan_factory' references shared args but does not describe them individually, leaving many parameters without added meaning.

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 description opens with a specific verb and resource: 'Turn a plan into a buildable schematic: blocks, buses and floors.' It clearly distinguishes itself from a blueprint and from sibling plan_factory by stating what it does and does not produce (modules, connections, floors, space budget vs. world coordinates/routing).

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 explains that the tool shares arguments with plan_factory and enumerates the detail modes, giving clear context for selecting output granularity. It also warns that it is not a blueprint and lacks terrain data, so it is not for coordinate-level routing. However, it does not explicitly name alternative tools for blueprint-level work.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lukszi/SatisfactoryMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server