Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mam_research

Check which MAM research capabilities remain, their resource costs, and what your save can afford right now. Filter by name or status to plan gated unlocks like the Production Amplifier.

Instructions

MAM research: what is left, what it costs, and what you can afford right now.

The MAM is where CAPABILITIES live, as opposed to recipes -- the Dimensional Depot, the Power Augmenter, and Production Amplifier, which is the one that lets a Somersloop go into a machine at all.

That last one has no flag in the save. BP_UnlockSubsystem_C records overclocking as mIsBuildingOverclockUnlocked, but nothing anywhere in the file records production amplification, so it is derived from the purchased-schematic set instead. Capability rows are marked LOCKS so it is obvious which research gates a tool argument rather than just adding a recipe.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
saveNo
showNoall | todo | affordable -- todo hides finished researchtodo
as_ofNopin to one world state: a sav:… token from an earlier answer
limitNomax rows (hard cap 25)
queryNofilter by name, case-insensitive
worldNo
offsetNo
searchNoretired -- write query= instead
statusNoretired -- write show= instead

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 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 / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
    • addedInput schema / properties / query
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "filter by name, case-insensitive",
+  "title": "Query"
+}
    • changedInput schema / properties / search / description
      Previous value: -"filter by name, case-insensitive"New value: +"retired -- write query= instead"
    • addedInput schema / properties / show
      Added value: +{
+  "default": "todo",
+  "description": "all | todo | affordable -- todo hides finished research",
+  "title": "Show",
+  "type": "string"
+}
    • addedInput schema / properties / status / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / status / default
      Previous value: -"todo"New value: +null
    • changedInput schema / properties / status / description
      Previous value: -"all | todo | affordable -- todo hides finished research"New value: +"retired -- write show= instead"
    • removedInput schema / properties / status / type
      Removed value: -"string"
  2. First observedv0.1.0

TDQS

B3.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden. It discloses meaningful internal behavior: MAM capabilities are distinct from recipes, production amplification is not directly recorded in the save and is derived from the purchased-schematic set, and capability rows are marked LOCKS to indicate tool-argument gating. It still does not state read-only safety, permissions, or return format, but the domain disclosure is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the purpose effectively, but the following paragraphs drift into detailed save-file implementation lore such as BP_UnlockSubsystem_C and mIsBuildingOverclockUnlocked. That context is relevant to trust the LOCKS marker, yet it is longer and more technical than needed for most invocation decisions.

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?

Given 9 parameters, no annotations, and no output schema, the description should explain more about invocation and expected results. It provides useful domain context but omits parameter usage, pagination behavior, and return shape, leaving the agent without guidance for several important call decisions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no parameter-specific meaning beyond the schema. With 9 parameters and only 67% schema description coverage, several parameters (save, world, offset) lack documentation in either place, and the description does not compensate or explain how to use query, show, as_of, or retired parameters. The schema does some work, but the description contributes nothing to parameter semantics.

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 description states a specific resource (MAM research) and the three questions it answers: what is left, what it costs, and what you can afford right now. It also distinguishes MAM capabilities from recipes, which helps separate it from recipe-oriented siblings. It does not explicitly name a sibling tool, so it stops short of a 5.

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

Usage Guidelines3/5

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

Usage is implied by the opening question set and by the contrast between MAM capabilities and recipes. However, there is no explicit 'use this when' or 'do not use this when' guidance, and no named alternatives among the many sibling tools. The agent must infer the appropriate context.

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