Skip to main content
Glama

Get a competition's check reveal

get_reveal
Read-onlyIdempotent

A program/v1 or agent/v1 competition's check reveal as it stands: its final scores, sealed at the deadline, shown part by part over its running phase (reveal: the bundle's block, its parts with each one's max, the held ones and duration_sec), the winner last. status: none (no check reveal: get_live has its board), scheduled (sealed until the reveal starts, once the final grades and checks pass: nothing of it is shown before), running, ended, fallback (its checks failed: no step, every result published at once at its end, the reason naming no entry), unavailable or published (the results came out with no reveal). sentence: one sentence with the time (UTC) of what comes next. From its start: timetable (stage 1 shows each open part for every entry at once, a step every stage1_step_ms; stage 2 resolves the held parts bottom-up, the lowest entry not yet placed showing its next one; steps, ends_at: the last step's time, when the results publish), latest_step, and board: every entry's position, total, ceiling (the most it can still reach), the parts shown with their points (one per trial on agent/v1, whose totals are each entry's integer-sum mean over its trials to six places), the parts pending and, once placed, its final place; decided, the entry whose total beats every other ceiling; next, the step after. step: the board after an earlier step already published (a later one is an error). aside: the entries it lists but does not rank, their values out with the results. House and internal entries are left out here, so the timetable counts the entries this surface lists. stream names its stream (Server-Sent Events, each step at its time, HTTP only): call this tool again for the next step.

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": {
      "slug": "<slug>"
    },
    "name": "get_reveal"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesThe competition slug, e.g. chess-engine-01 (list_competitions lists them)
stepNoThe board after this step, one already published (0: the opening board); default the latest

Output Schema

NameRequiredDescriptionDefault
stepYes
asideYes
boardYes
phaseYes
revealYes
statusYes
streamYes
ends_atYes
fallbackYes
sentenceYes
timetableYes
started_atYes
aggregationYes
competitionYes
latest_stepYes
published_atYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior5/5

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

Beyond the annotations (which already cover read-only, idempotent, non-destructive), the description discloses non-obvious behavior: reveals stay sealed until final grades and checks pass, the fallback case publishes everything at once with no step, house and internal entries are excluded so the timetable count differs from the surface, and streaming requires re-calling the tool per step. It also spells out ordering semantics (stage 1 vs. stage 2 bottom-up resolution) and what 'ceiling' and 'decided' mean.

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 text is one enormous run-on construction dense with nested parentheticals and unexplained jargon ('the lowest entry not yet placed showing its next one', 'the bundle's block'). It is information-rich but poorly structured and much longer than needed, with no paragraphing or bullet separation of status taxonomy from board semantics from stream behavior.

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

Completeness4/5

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

For a complex, stateful read with an output schema provided, the description covers the status taxonomy, timetable phases, board fields, decided/next, aside, entry exclusions, and the SSE streaming protocol — enough to call it correctly. Minor gaps remain around how the stream terminates and what 'published' means relative to 'ended'.

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 description coverage is 100%, so the schema already documents both parameters. The description restates step's constraint ('the board after an earlier step already published, a later one is an error'), reinforcing rather than adding new syntax or format information, which is the baseline-3 case when the schema does the heavy lifting.

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 description names a specific resource (a program/v1 or agent/v1 competition's check reveal) and enumerates its contents — final scores, timetable, board, decided, next, aside. It also distinguishes itself from get_live for the 'none' status case, but the purpose is buried inside a single sprawling sentence, so an agent must parse hard to extract it.

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?

Some routing is explicit: 'status: none (no check reveal: get_live has its board)' points to a sibling, and the step parameter's error condition ('a later one is an error') is stated. However, there is no clear statement of when to prefer this over get_leaderboard, get_result, or get_live for the general case, and usage guidance is scattered rather than systematic.

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.