Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

alternates_for_item

Read-onlyIdempotent

Lists every recipe that produces an item, flags alternate recipes as available or locked against your save, and can show a saved plan's machine, power, and raw-input changes.

Instructions

Every recipe that makes an item, alternates first, marked HAVE/LOCKED against the save.

A LOCKED row names the schematic that grants it. With plan: each recipe's status in that plan and the machine, MW and raw-input deltas of requiring it.

Input Schema

NameRequiredDescriptionDefault
itemYes
planNoa saved plan: add what requiring each recipe would change in it
saveNo
as_ofNopin to one save: the sav:… token an earlier answer printed
worldNo
include_lockedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed17 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"
+]
    • removedInput schema / properties / include_locked / title
      Removed value: -"Include Locked"
    • removedInput schema / properties / item / title
      Removed value: -"Item"
    • removedInput schema / properties / plan / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • changedInput schema / properties / plan / description
      Previous value: -"a stored plan: add what requiring each recipe would change in it"New value: +"a saved plan: add what requiring each recipe would change in it"
    • removedInput schema / properties / plan / title
      Removed value: -"Plan"
    • addedInput schema / properties / plan / type
      Added value: +[
+  "string",
+  "null"
+]
    • 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 / title
      Removed value: -"alternates_for_itemArguments"
  2. Changed1 schema field changedv0.2.0
    • addedInput schema / properties / plan
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "a stored plan: add what requiring each recipe would change in it",
+  "title": "Plan"
+}
  3. Changed2 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 / world
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "World"
+}
  4. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world, so the safety profile is free. The description adds genuine behavioral detail — LOCKED rows name the granting schematic, and the plan mode returns per-recipe status plus machine/MW/raw-input deltas — but says nothing about result size, ordering guarantees, or what happens when the item is unknown.

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 behavior and only two short paragraphs, no filler. Slightly harmed by telegraphic phrasing ('alternates first, marked HAVE/LOCKED against the save') that costs a re-read.

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?

Six parameters with no output schema and four undocumented fields; the description does not explain what a row actually contains, how `save`/`as_of`/`world` interact, or what `include_locked=false` hides. For a tool whose whole value is the shape of its rows, that is a meaningful gap.

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 33% (only `plan` and `as_of` are documented). The description partially compensates by explaining plan-mode deltas and the save-relative HAVE/LOCKED marking, but `world`, `save` vs `as_of` distinction, and especially `include_locked` (default true) are left entirely unexplained.

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?

States a specific verb+resource: it enumerates every recipe that produces a given item, ordered alternates-first, with HAVE/LOCKED flags. That distinguishes it from recipe_detail or search_recipes, though the HAVE/LOCKED vocabulary is domain jargon used without definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains what happens if you pass `plan`, but never says when to choose this over nearby siblings such as compare_recipe_options, recipe_detail, or trace_upstream. No exclusions or preconditions are given.

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