Skip to main content
Glama
lukszi

SatisfactoryMCP

by lukszi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

somersloops

Count Somersloops in a Satisfactory save, reporting free, committed, and slotted totals to replace budget guesswork.

Instructions

Somersloops held, slotted and owned -- the sibling of power_shards.

sloop_budget has existed since sloops became spendable and nothing exposed it, so the only way to learn how many you had was to guess a sloops= budget and read the shortfall warning: you had to guess the budget to discover the budget.

Free and committed are both exact. Slotted ones live in InventoryPotential, the same component as Power Shards, so this counts slot contents rather than inverting a boost multiplier.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
saveNo
as_ofNopin to one world state: a sav:… token from an earlier answer
limitNomax rows (hard cap 25)
worldNo
offsetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 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 / limit
      Added value: +{
+  "default": 20,
+  "description": "max rows (hard cap 25)",
+  "maximum": 25,
+  "minimum": 1,
+  "title": "Limit",
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose real methodology: free and committed counts are exact, slotted ones come from `InventoryPotential` (the Power Shards component), and it counts slot contents rather than inverting a boost multiplier. However, it says nothing about read-only semantics, pagination behavior, or rate/scan cost.

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 purpose is front-loaded, but the middle paragraph is a narrative detour about having to guess a budget to discover a budget that, while colorful, takes space without routing the agent. Three paragraphs is more than this definition needs.

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?

No output schema and no annotations mean the description must cover return shape, pagination (limit/offset), and the save/world scoping parameters, yet it covers none of them. For a 5-parameter listing tool, it leaves the agent under-equipped to call it correctly.

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?

Schema description coverage is only 40% (`save`, `world`, and `offset` are undocumented), and the description adds no parameter-level meaning at all, discussing only `sloop_budget`/`sloops=` from a different tool. It fails to compensate for the coverage gap on a 5-parameter tool.

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 identifies the resource (somersloops) and its three states (held, slotted, owned), and explicitly names its sibling `power_shards`, letting an agent place it without opening the schema. The verb is only implicit ('counts slot contents'), but the reporting intent is clear enough to act on.

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?

The second paragraph explains why the tool exists (nothing exposed `sloop_budget`; you previously had to guess a `sloops=` budget), which implies the usage context of checking somersloop holdings. It never states when to call this versus `power_shards` or other inventory tools, so usage is inferred rather than directed.

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