Skip to main content
Glama

factory_query

Query a Satisfactory factory's production, power draw, inputs, outputs, and machine details from a save to diagnose balance or bottlenecks.

Instructions

Ask one thing about one factory: what it makes, needs, draws, or touches.

show accepts several at once, e.g. "balance,power,links". offset pages every table in the answer at once, so asking for one aspect at a time is what you want when a factory has more machines than fit.

  • summary size, position, top recipes, net power

  • balance per-item produced vs consumed vs net -- the sign is the point

  • outputs net surplus: it leaves the factory, or it backs up

  • inputs net deficit: it has to be fed in from outside

  • internal made and eaten inside the set -- the mark of a self-contained line

  • machines every machine with its building, recipe and clock

  • recipes / buildings counts

  • power draw vs generation, nameplate AND measured -- which factory is really burning the grid, rather than which could

  • nodes resource nodes its extractors sit on

  • links which other factories it exchanges material with

  • issues paused, recipe-less, or unresolved machines

Every rate is printed twice. NAMEPLATE is the machine's recipe rate at its saved clock, which a starved factory still reports in full. MEASURED is that rate scaled by the share of its own productivity window each machine spent producing -- the window that ended when the save was written, so a line idle at that moment measures 0 and is not broken. A machine keeping no monitor is left out of measured entirely and shown separately, because counting it in full there would invent output.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ofNoretired -- write show= instead
saveNo
showNocomma-separated: summary, machines, recipes, buildings, balance, inputs, outputs, internal, power, nodes, links, issuessummary
as_ofNopin to one world state: a sav:… token from an earlier answer
limitNomax rows (hard cap 25)
worldNo
offsetNo
factoryYesa label name, or any selector e.g. 'proposal:3'

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 / of / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / of / default
      Previous value: -"summary"New value: +null
    • changedInput schema / properties / of / description
      Previous value: -"comma-separated: summary, machines, recipes, buildings, balance, inputs, outputs, power, nodes, links, issues"New value: +"retired -- write show= instead"
    • removedInput schema / properties / of / type
      Removed value: -"string"
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "title": "Offset",
      +  "type": "integer"
      +}
    • addedInput schema / properties / show
      Added value: +{
      +  "default": "summary",
      +  "description": "comma-separated: summary, machines, recipes, buildings, balance, inputs, outputs, internal, power, nodes, links, issues",
      +  "title": "Show",
      +  "type": "string"
      +}
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly. It explains the crucial NAMEPLATE vs MEASURED distinction, notes that idle machines measure 0 and are not broken, and warns that machines without monitors are excluded from measured to avoid inventing output. These are deep, non-obvious behavioral traits that an agent cannot infer from the schema.

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 front-loaded with the purpose, then organized into a bulleted list of show aspects followed by a measurement-semantics paragraph. It is dense and long, but each section earns its place by explaining how to interpret the returned data; there is little redundant filler.

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?

Given 8 parameters, no output schema, and moderate schema coverage, the description is largely complete for the main query workflow: it explains show aspects, pagination behavior, and rate semantics. It leaves save, world, and limit without description-level context, and does not say how to obtain a factory selector, but the central calling pattern is fully covered.

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 description coverage is 63%, so the description must add meaning beyond the schema, and it does: it expands on what each show aspect returns (e.g., 'balance -- per-item produced vs consumed vs net -- the sign is the point', 'internal -- made and eaten inside the set'), clarifies that multiple show values are accepted, and explains that offset pages all tables together. It does not cover save, world, or limit semantics, but the core query parameters are well served.

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 opening sentence states a specific verb and resource: 'Ask one thing about one factory: what it makes, needs, draws, or touches.' This clearly distinguishes a single-factory detail query from list-oriented siblings like list_factories. However, it stops short of explicitly naming alternative tools such as factory_health or factory_map for sibling differentiation.

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 concrete when-to-use guidance for aspects and pagination: 'offset pages every table in the answer at once, so asking for one aspect at a time is what you want when a factory has more machines than fit.' It does not explicitly compare the tool to siblings or state exclusions, but the context for selecting show combinations is clear.

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