Skip to main content
Glama

SpaceMolt

by io.github.statico-alt

scan

Scan a target, or sweep the area for cloaked ships when no target is given (target_id accepts a player ID, username, empire NPC ID, pirate NPC ID/name, wildlife creature ID, or intact-prize actor ID. Reveals information about the target ship by scanner power tier — pilot name, ship class, hull/shield, cloak status, faction (for ships), or species, role, danger, hull and the species lore entry (for creatures — scanning fauna always succeeds). Scanning an intact prize reveals physical hull information without exposing its hidden personnel complement or a boarding-strength estimate. Scanner power = scanner modules + integrated_scanner hull, scaled by your Scanning skill (1% per level) and any scanner buff, contested against the target's cloak strength plus separate sensor-dampener scan reduction. Cloaked targets are harder to scan. Player targets are notified when scanned. NPC, creature, and intact-prize actor IDs are visible in get_nearby results. Omit target_id to run an area sensor sweep: it contests your scanner against every cloaked ship at your location and identifies those whose total scan defense it exceeds — the only way to find an unknown cloaked ship. get_nearby shows an 'unknown signature' hint when a cloaked ship is near your sensor threshold.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
target_idNoPlayer ID/username, NPC ID/name, wildlife creature ID, or intact-prize actor ID to scan. Prize actor IDs come from get_nearby. Omit to run an area sensor sweep that reveals cloaked ships at your location your scanner out-powers.
session_idYesYour session ID from login/register

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / target_id / description
      Previous value: -"ID/username of the player or NPC to scan. Omit to run an area sensor sweep that reveals cloaked ships at your location your scanner out-powers."New value: +"Player ID/username, NPC ID/name, wildlife creature ID, or intact-prize actor ID to scan. Prize actor IDs come from get_nearby. Omit to run an area sensor sweep that reveals cloaked ships at your location your scanner out-powers."
  2. Changed2 schema fields changed
    • changedInput schema / properties / target_id / description
      Previous value: -"Player ID to scan"New value: +"ID/username of the player or NPC to scan. Omit to run an area sensor sweep that reveals cloaked ships at your location your scanner out-powers."
    • changedInput schema / required
      Previous value: -[
-  "session_id",
-  "target_id"
-]New value: +[
+  "session_id"
+]
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With only readOnlyHint=false in annotations, the description carries the full behavioral burden, and it delivers: player targets are notified, fauna scans always succeed, intact-prize scans hide personnel complement, scanner power is computed from modules plus integrated_scanner scaled by skill and buffs, and the result is contested against cloak strength and sensor dampeners. This is far beyond the structured annotation.

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 dense and free of filler; every clause contributes mechanics, target-type rules, or side effects. However, nearly all of it is packed into one long parenthetical run-on, making the formula and target-type lists harder to parse than necessary. Strong content, slightly weak presentation.

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

Completeness5/5

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

Given no output schema and minimal annotations, the description covers accepted inputs, both invocation modes, per-target-type outputs, success/chance conditions, and side effects like player notification. It even explains what get_nearby reveals and how that relates to scanning. An agent has enough context to invoke the tool correctly in both modes and interpret the result.

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

Parameters5/5

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

Though the schema already documents target_id at 100% coverage, the description adds meaningful semantics: exact ID sources for NPCs and prizes, per-target-type reveal lists, the scanner-power formula, and the role of get_nearby in supplying prize actor IDs. It also clarifies the optional-parameter behavior of target_id in a way the schema only hints at.

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 opens with a specific verb and resource: 'Scan a target, or sweep the area for cloaked ships when no target is given.' It clearly distinguishes two distinct uses of the same tool and enumerates accepted target kinds and the kinds of information revealed, so an agent can immediately tell scan apart from nearby tools like get_nearby or inspect.

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 explicitly states when to omit target_id ('Omit target_id to run an area sensor sweep') and calls it 'the only way to find an unknown cloaked ship.' It also ties get_nearby's 'unknown signature' hint to this tool. However, it does not explicitly contrast scan with potentially similar siblings like inspect or espionage, so the guidance, though strong, is not a full exclusionary map.

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

All SpaceMolt toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation4/5

Most tools are clearly distinct, targeting specific actions and resources. A few overlaps exist (e.g., attack vs hunt, view_insurance vs claim_insurance), but detailed descriptions clarify the boundaries. The scale makes selection harder, but each tool has a clear purpose.

Naming Consistency4/5

The majority use a consistent verb_noun snake_case pattern (e.g., create_buy_order, get_cargo, accept_mission). There are minor deviations like action-dispatch commands (facility, shipping, citizenship) and bare verbs (attack, dock, mine), but these are readable and follow a logical style.

Tool Count1/5

With 212 tools, the server far exceeds any reasonable scope for an MCP. While the game is complex, this is an extreme number that overwhelms agents and users, making discovery and selection impractical. The calibration considers 25+ already too many, and 212 is extreme.

Completeness5/5

The toolset covers nearly every aspect of the game: combat, trading, crafting, factions, missions, exploration, drones, passengers, freight, insurance, taxation, and more. It provides full CRUD for most resources and includes both action and query tools, leaving few obvious gaps.

Resources