Skip to main content
Glama

commission_plan

Determine the order to power up a built factory block by block, ensuring each step stays under grid headroom plus generator output so the fuse does not blow.

Instructions

In what order to switch a built plant on, without blowing the fuse.

This is a STARTUP order, not a build order, and the difference removes most of the problem. Building costs materials, not power -- a machine draws only when it runs -- so the whole plant can be constructed at leisure, drawing nothing, and then energised block by block. Nothing here tells you what to build first.

The constraint is one line, and it is hard: at every step, energised consumer draw must stay under the headroom plus generation from generators already burning fuel. Exceeding it in Satisfactory does not degrade gracefully -- the fuse blows and the whole grid stops until it is reset by hand, including the plant that was feeding it.

Generators are free to energise (0 MW draw, read from the dump), so a wave costs its consumers and refunds its generators, and that refund pays for the next wave.

Takes plan_factory's arguments, or recall a saved plan with plan=.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNorecall a saved plan by name
saveNo
limitNomax rows (hard cap 25)
worldNo
clocksNo
sloopsNo
exportsNo
sourcesNo
objectiveNomax_mw
allow_sinksNo
headroom_mwNogrid power free for startup; default reads it from the save
target_itemNo
only_recipesNo
exclude_recipesNo
export_minimumsNo
machine_cost_mwNo
only_free_nodesNo
extractor_clocksNo
water_extractorsNo
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses key behaviors: the hard power constraint, fuse-blowing consequence, generators drawing 0 MW, and reading from the save/dump. This goes beyond basic expectations, though it does not address side effects or exact output format.

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 long but well-structured, front-loading the core purpose and then explaining the critical constraint and consequence. Some phrasing ('removes most of the problem') is a bit extraneous, but each section adds necessary context for a complex tool.

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

Completeness2/5

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

For a 19-parameter tool with no output schema and no annotations, the description lacks information about return values, how to interpret the resulting order, or details of the many parameters beyond a reference to plan_factory. The conceptual foundation is strong, but operational completeness is insufficient.

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 description coverage is only 16% (3/19 params), so the description must compensate. It adds useful context by stating it accepts plan_factory's arguments, explaining the 'plan=' recall, and relating headroom_mw to the power constraint. However, most parameters remain without added meaning, leaving a significant 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 description clearly states the tool determines the order to switch a built plant on without blowing the fuse. It explicitly contrasts STARTUP order with build order and notes 'Nothing here tells you what to build first,' which distinguishes it from sibling plan_factory. The verb+resource identity is 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?

The description implies use after construction ('a built plant') and highlights the difference from build order, which guides when to use this tool vs plan_factory. It also mentions 'Takes plan_factory's arguments,' signaling shared context. However, it does not explicitly state exclusions or name alternative tools for other scenarios.

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