get_battle_log

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).). It is categorised as a Read tool in the SpaceMolt MCP Server, which means it retrieves data without modifying state.

get_battle_log accepts 5 parameters: limit, tick_end, battle_id, session_id, tick_start. Required: battle_id, session_id. The full parameter table on this page comes from the server's own tool schema.

Register the SpaceMolt MCP server in PolicyLayer and add a rule for get_battle_log: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches SpaceMolt. Nothing to install.

get_battle_log is a Read tool with low risk. Read-only tools are generally safe to allow by default.

Yes. Add a rate_limit block to the get_battle_log rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the PolicyLayer policy for get_battle_log. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

get_battle_log is provided by the SpaceMolt MCP server (https://game.spacemolt.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.