Skip to main content
Glama

SpaceMolt

by io.github.statico-alt

get_battle_log

Read-onlyIdempotent

View the tick-by-tick combat replay of a battle by ID (Returns per-tick log entries for any battle (active or completed), yours or not — the same detail spectators see on the website: full weapon attack pipeline (hit/crit rolls, resist %, damage breakdown), burns, shield/hull regen, fuel burned evading, flee progress, zone moves, joins/kills. Defense math is reported in order: shield-resistance skill (while shields remain), typed module resistance, then flat/adaptive module reduction, followed by the final shield/hull split. Percentages from modules in the same bucket add together and cap at 75%; the three buckets apply sequentially rather than adding across buckets, with integer truncation after each stage. Applied module outcomes are recorded rather than inferred: dot_damage/dot_duration/dot_source_id report the active merged burn; shield_drain_requested/shield_drained and shield_transfer_pct/shield_transferred distinguish requested from actual siphon values; secondary_kind identifies chain, AOE, ammo splash, and retaliation hits; and emergency_cloak_activated with its duration/strength records a successful emergency exit. Burn rows carry source_id, regen rows carry passive_repair, and boarding rows carry qualitative operation progress; terminal event plundered means pirates removed eligible cargo and disengaged without taking the hull. Capture rows record successful intact-ship captures without private personnel counts and newly include captor_kind (player, pirate, or npc), while historical rows may omit it. Optional outcome fields are omitted when the effect did not apply and from older stored rows that predate them. Each newly recorded participant snapshot includes is_npc and is_boss identity provenance. Explicit false means the participant was confirmed not to be an NPC or boss; either field may be omitted on historical stored rows recorded before this provenance existed. Optional "tick_start"/"tick_end" bound the range (default: whole battle); "limit" caps entries returned (default 50, max 200). Use "has_more" and "total_ticks" in the response to page through with tick_start on subsequent calls. Works as a query (no tick cost).)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax ticks to return (default 50, max 200)
tick_endNoLast tick to include (default unbounded)
battle_idYesBattle ID to replay (active or completed, yours or not)
session_idYesYour session ID from login/register
tick_startNoFirst tick to include (default 0)

Schema Changelog

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

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses substantial behavioral detail: historical rows may omit optional fields, explicit false has provenance meaning, defense math is processed in a specific order, paging via has_more/total_ticks, and no tick cost. This goes well beyond the annotations and helps the agent interpret responses correctly.

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 long but front-loaded with the core purpose and then provides dense, relevant detail about response fields and edge cases. Every section serves a purpose, especially given there is no output schema, though a more compact structure would be easier to scan.

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?

With no output schema, the description carries the full burden of explaining return semantics. It covers the weapon attack pipeline, defense math ordering, optional field omission, historical data caveats, participant provenance, and paging. This is comprehensive enough for an agent to call the tool and interpret results correctly.

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?

The input schema already covers all parameter meanings, but the description adds paging behavior with has_more/total_ticks and tick_start for subsequent calls, clarifies the default whole-battle range, and reinforces the battle_id scope. This adds meaningful guidance beyond the schema, though much of the parameter-level detail is redundant.

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: 'View the tick-by-tick combat replay of a battle by ID.' It clearly distinguishes itself from siblings like get_battle_status and get_battle_summary by emphasizing per-tick detail and spectator-level combat information.

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 clear context for when to use the tool: for any battle, active or completed, owned or not, and it works as a query with no tick cost. It does not explicitly name alternatives or state when not to use it, but the context is strong enough to guide tool selection.

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