Skip to main content
Glama

Break an entry's run down

get_breakdown
Read-onlyIdempotent

One entry's grade run on a phase, row by row, as far as you may see it (view). A market replay (kind pnl; money as integer strings of pnl.unit: lamports, or USDC quote units): each item's realized PnL, fees, transaction fees and fills with their sums line (items_total) and every identity re-added (sums: each fill's cash flow is its trade minus its fees and transaction fee plus its other movements, the cash chain, the items to the net, start plus net to the end, each with both sides and ok), the rejections per reason, the round trips, the equity curve downsampled to at most 1000 points with every dip and spike kept (full: every point, once the breakdown is public; an error before, but to admins), and the fills with each part of their cash flow, paged (pass fills.next_cursor back as cursor: the first page carries the whole breakdown, a later page only pnl.unit and that page of fills, beside the run's identity: submission, phase, run, view, clock). A program/v1 or agent/v1 run (kind checks): its parts, a scorer's checks earned against their maximum or its scored columns, per trial on agent/v1, and the total. A scrape/v1 run (kind checks, from its score): its timed trials, one per round, each with its wall time in ms, whether the trimmed mean kept it (1) or dropped it (0) and its verdict; the total the trimmed mean that ranks it (time_ms, null when it did not finish); and on no trial (no earned_by_trial, the value in mean) the trimmed mean's 90% interval ends and the trials voided and run again. view full: the whole run, to the entry's owner (send your account's API key as the x-api-key header of the MCP connection) and admins, and to everyone once its action log opens (its competition's deadline, the winner's or not; on a competition with a running phase, once its results are published); view aggregates: the score's public rows alone (per_token, per_symbol or per_block; the scored columns), to anyone else; view replay: during a running phase, the run cut at the replay's clock (clock), the same for every caller, its owner and admins included, and the whole of it from the replay's end; on a sealed draw (the phase's dataset a sealed-window draw, its results not published) its equity alone: pnl.start_equity, pnl.equity and pnl.net at the clock (from the replay's end the run's as it ended), pnl.equity_curve up to it, and pnl.fills a page that lists none, its total the fills so far (failed orders and closes included), every time (clock.t_ms, clock.window, pnl.window, each point's t_ms) in ms from the replayed window's start, no item, fill, round trip, sum, rejection, realized or unrealized figure until the results are published; view none: the run did not finish or is still grading. A sealed phase is an error until its replay starts, a phase whose scores are hidden an error too.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "submission_id": "<submission_id>"
    },
    "name": "get_breakdown"
  }
}

Input Schema

NameRequiredDescriptionDefault
fullNoEvery equity point, not downsampled (only once the breakdown is public, or as an admin)
limitNoPage size, 1 to 200 (default 50)
phaseNodev or final (default: a phase whose breakdown you may see, the latest first)
cursorNoThe previous page's next_cursor, for the next page (keep the other arguments the same)
submission_idYesThe entry (submission) id: a UUID, as get_competition, get_leaderboard and search list them

Output Schema

NameRequiredDescriptionDefault
pnlYes
runYes
kindYes
noteYes
viewYes
clockYes
phaseYes
checksYes
phasesYes
aggregatesYes
submission_idYes
trace_problemYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds substantial context beyond that: API-key header authentication, owner/admin visibility, public-release timing, sealed-draw redaction, phase-hidden errors, and page-dependent response shapes. It also discloses that later pages omit most of the breakdown and carry only pnl.unit plus that page of fills. This is unusually rich behavioral disclosure.

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 description is a single sprawling, parenthesis-heavy block with long run-on sentences and deeply nested conditions. Important facts are present but not front-loaded or scannable, making it hard for an agent to parse quickly. It is over-specified for a tool whose output schema already carries much of the return-shape burden.

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 the tool's complexity across pnl, checks, and scrape runs, multiple view modes, visibility tiers, sealed draws, pagination, and errors, the description covers the relevant edge cases thoroughly. An output schema exists, yet the description still explains enough about return variations and access conditions to call the tool correctly. Nothing material appears missing for invocation.

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

Parameters3/5

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

Schema coverage is 100%, so all five parameters are already documented in the input schema. The description reinforces cursor chaining and the meaning of full availability, but it mostly repeats schema semantics rather than adding new parameter-level detail. The later-page response shape is useful, though it is more output behavior than parameter semantics.

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 sentence states a specific resource and scope: one entry's grade run on a phase, row by row, constrained by what the caller may see. It is distinguishable from siblings in substance, though it never names an alternative tool such as get_result or get_submission. The dense jargon makes the core purpose harder to extract than it should be.

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 description explains the conditions under which each view applies, including full, aggregates, replay, none, and sealed-draw behavior, plus when sealed phases are errors. That gives useful context for interpreting results, but it does not explicitly say when an agent should choose get_breakdown over sibling tools. Usage is implied by the response contract rather than stated as guidance.

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.