Skip to main content
Glama

Calculate bracket standings

calculate_bracket_standings
Read-onlyIdempotent

Use this when the user reports results of a tournament made with generate_tournament_bracket (or describes one) and wants the updated bracket, who advances, the standings table or what is next. Takes the same format and participants plus every result so far (winner or scores per match) and returns the advanced bracket, the round robin or Swiss table (points, head-to-head, score difference; Buchholz for Swiss), final places, the next Swiss round's pairings, and the next matches to play. Do not use to predict outcomes; it only records results the user gives.

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": {
      "format": "<format>"
    },
    "name": "calculate_bracket_standings"
  }
}

Input Schema

NameRequiredDescriptionDefault
paperNoPaper size for the landscape PDF: letter (default) or a4. Example: a4
titleNoTournament name for the bracket, PDF and CSV. Example: "Friday Ping Pong Cup"
courtsNoCourts, tables, boards or fields available at the same time (1-64), used for the timetable. Example: 3
formatYesTournament format: single_elimination (knockout), double_elimination (out after two losses, losers bracket, grand final), round_robin (everyone plays everyone once; league), swiss (fixed number of rounds, players with equal scores meet, no rematches). Example: single_elimination
resultsNoResults already played, in any order for elimination formats and round by round for Swiss. Each needs the players (p1, p2) or a match id, plus a winner or both scores. Example: [{"p1":"Ann","p2":"Finn","score1":21,"score2":12}]
seedingNostandard (default): list order is the seed ranking, 1 plays the lowest seed, top seeds get the byes and seeds 1 and 2 can only meet in the final. random: a reproducible random draw (see random_seed), then placed like seeds. as_listed: fill the bracket top to bottom in list order, 1st vs 2nd, 3rd vs 4th, with byes spread evenly. Example: random
meetingsNoRound robin only: 1 (default) = every pair meets once; 2 = home and away (double round robin). Example: 2
start_timeNoStart time of the first matches, 24-hour HH:MM (default 09:00). Example: "18:30"
win_pointsNoRound robin / Swiss table points for a win (default 3 for round robin, 1 for Swiss). Example: 2
draw_pointsNoPoints for a draw (default 1 for round robin, 0.5 for Swiss). Example: 1
loss_pointsNoPoints for a loss (default 0). Example: 0
random_seedNoDraw number for random seeding (1-999999). The same participants and number always give the same draw. Example: 4821
participantsNoPlayers or teams, 2-128 unique names. With standard seeding the order is the ranking: first = seed 1. Example: ["Ann","Bob","Cy","Dee","Eve","Finn"]
swiss_roundsNoSwiss only: number of rounds (default log2 of the field, rounded up; maximum depends on the field size). Example: 5
break_minutesNoChangeover time between matches on a court, in minutes (0-120, default 0). Example: 5
match_minutesNoLength of one match in minutes (5-600). Giving this adds start times and courts to every match. Example: 20
grand_final_resetNoDouble elimination only (default true): if the losers-bracket champion wins the grand final, a second deciding match is played, so nobody is out after one loss. Example: false
participant_countNoUse instead of participants when the user gives only a number: makes Team 1 ... Team N (2-128). Example: 12
third_place_matchNoSingle elimination only: add a third-place match between the semifinal losers. Example: true

Output Schema

NameRequiredDescriptionDefault
byesYes
kindYes
notesYes
swissYes
titleYes
countsYes
formatYes
matchesYes
requestYes
resultsYes
seedingYes
championYes
completeYes
scheduleYes
downloadsYes
standingsYes
placementsYes
random_seedYes
bracket_sizeYes
format_labelYes
next_matchesYes
participantsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare this as a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds useful behavioral context: it only records results supplied by the user and returns derived standings, pairings, and advancement rather than predicting results.

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 front-loaded with the use case and the key exclusion, and every sentence contributes. The middle sentence is dense with output enumerations that could be somewhat shorter, but the extra detail helps an agent understand what the tool returns.

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?

For a 19-parameter tool with a full output schema and strong annotations, the description is complete enough to guide correct selection and invocation. It covers the trigger condition, required inputs at a high level, returned artifacts, and the key non-use case.

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 parameter meanings are already fully documented. The description reinforces the core input shape, especially that results so far and format/participants matter, but it does not add substantial semantics beyond the schema for the many optional parameters.

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 gives a specific verb and resource, clearly frames this as updating standings after reported results, and explicitly distinguishes it from the sibling generator by saying it does not predict outcomes. An agent can identify the operation without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use this tool: after results are reported for a bracket made with generate_tournament_bracket, when the user wants the updated bracket, standings, advancement, or next matches. It also states a clear exclusion: do not use it to predict outcomes.

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