Skip to main content
Glama

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 or a robbing player removed eligible cargo without taking the hull; a player robbery also removes the victim from the battle with reason surrendered. Against plunder, a ship's crew fights only while a fit marine is aboard: with no marines at latch, or once the last marine falls, the crew surrenders, the plundered row carries reason surrendered, and the ship keeps its surviving crew. Captures are fought to the end by the whole crew and never surrender. Fit barracks and recruit marines (recruit_personnel) so your crew can fight back against plunder. 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

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.

  1. Added
  2. Removed
  3. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered; the description goes further by disclosing that optional outcome fields are omitted when not applicable and that older stored rows predate newer fields (is_npc/is_boss, captor_kind). That is genuinely useful beyond the annotations. Much of the middle text is a field-level data dictionary of output semantics rather than tool behavior, which limits it short of a 5.

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

Conciseness2/5

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

The purpose, paging rules, and no-tick-cost note are front-loaded and useful, but the bulk is a multi-paragraph payload dictionary (resistance bucket math, burn/siphon/boarding field notes, plunder crew rules) that does not help an agent select or call the tool. For a read-only replay fetch, this is heavily over-specified and buries the two sentences an agent actually needs.

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?

There is no output schema, so the description carries the return-value burden and does so thoroughly, including omission rules for optional and historical fields plus the paging contract. Nothing an agent needs to call this correctly is missing.

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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema does not carry: it explains how tick_start/tick_end bound the range as a default-to-whole-battle pair and, more importantly, prescribes the paging loop (use has_more and total_ticks to page with tick_start on subsequent calls). That goes beyond the per-field schema text.

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 opening clause states a specific verb and resource: 'View the tick-by-tick combat replay of a battle by ID.' That is unambiguous. It does not name the sibling retrieval tools (get_battle_summary, get_battle_status) it is distinct from, so the agent must infer the replay-vs-summary split from names alone.

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?

It clarifies eligibility ('any battle (active or completed), yours or not') and cost ('Works as a query (no tick cost)'), which helps an agent decide whether it can afford to call it. Paging is explained via has_more/total_ticks with tick_start. However, it never states when to prefer get_battle_summary or get_battle_status instead, so sibling selection is only implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources