Skip to main content
Glama

turnale

Create tournament

create_tournament

Create a new tournament. Keep setup SHORT: ask the organiser only for sport, players, court count and start time — sensible defaults cover everything else. FORMAT: never ask an open 'which format?' question. If the organiser clearly named one, pass it; otherwise omit format — the call then returns a ready-to-show menu of options (nothing is created) for you to relay so the organiser can read and choose in one reply. Players can be added later with add_players. NEVER invent placeholder or fake player names ('Player 1', made-up names): if the organiser only knows the headcount, create with signup_open: true and signup_cap set to it — players add themselves by name via the page link. If the organiser gives a time budget instead of rounds (e.g. 'we have 2 hours'), derive rounds ≈ total minutes ÷ (match + break minutes) and confirm. If they ask for a format that is not listed, offer to note it with record_feedback. Returns the organiser key (tk_…): relay it with the warning that it cannot be recovered, plus the shareable page link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoDefaults to '<Sport> tournament 14 Aug 2026 (<location>)' — start date (or today) plus the location when known
pairsNoDoubles: fixed pairs as [name, name] arrays. Omit to auto-pair.
sportYesWrite sport names to the organiser in words — 'table tennis', never the enum spelling 'table_tennis'.
courtsNoDefault 2
formatNoTournament format. round_robin: everyone plays everyone. groups_playoff: round-robin groups then a knockout. single_elimination: knockout with byes. americano/mexicano: rotating-partner doubles, points per round (mexicano pairs each round from standings). OMIT when the organiser hasn't clearly chosen — the call then returns a menu of explained options to show them instead of creating anything.
roundsNoAmericano/mexicano; default from player count
playersNo
seedingNoDefault random
languageNoLanguage of the tournament page, PDFs and player emails (ISO 639-1). Default en; set it to the language the organiser is writing in when it is in this list.
locationNoVenue/location shown to players on the page, e.g. club name + city
disciplineNoAsk the organiser — never infer it from the sport. Americano/mexicano are always doubles. Defaults to singles for the bracket formats when they truly have no preference.
request_idNoOptional idempotency id — retrying the call with the same id returns the same tournament and key instead of creating a second one. It doubles as the secret that guards that replay, so it must be at least 16 characters of your own random choosing (a UUID is ideal); short or predictable ids are refused before anything is created.
signup_capNoSignup limit; beyond it players join a waitlist
start_timeNoISO datetime with offset, e.g. 2026-08-01T18:00:00+03:00. Must be within 365 days from today.
court_namesNo
group_countNo
house_rulesNoOrganiser's house rules, shown on the tournament page (e.g. 'Golden point at deuce')
level_scaleNoHow to read the numbers in `level`. absolute (default): one shared scale, a 3 is a 3 whoever holds it. by_group: men and women were each rated within their own group, so the numbers are not directly comparable — ask the organiser which they did rather than guessing. ignore: the numbers are notes, never used for the draw.
signup_openNoOpen self-signup: players add themselves on the shared page (name-only or signed in). Offer this when the organiser has no player list yet.
level_offsetNoby_group only: how much stronger an m is than an f carrying the SAME number, in the organiser's own level units. Default 1 — a starting point to adjust, not a fact. Used for balancing only; never shown on the page or in standings.
break_minutesNoChangeover between matches/rounds, shown separately from play time (default 0)
level_gap_capNoOpt-in: the largest level gap the organiser wants between opponents, in their own level units. Soft — the draw prefers to respect it and reports when it cannot. Pass 0 to clear.
gender_balanceNoAmericano/mexicano: prefer matches where both teams have the same make-up (MM v MM, MW v MW, WW v WW). Default prefer_symmetric. A preference, not a rule — an uneven field cannot supply it, and the draw says so rather than distorting the rotation.
points_per_matchNoAmericano/mexicano; default 21
advance_per_groupNo
third_place_matchNoSingle elimination; default true
page_results_entryNoAllow anyone with the page link to enter scores courtside. Default TRUE — recreational tournaments run on whoever finishes their match first, and an organiser who has to type every result is the bottleneck. Pass false if the organiser wants to be the only one recording scores; switchable either way at any time via update_settings or the toggle on the page.
match_duration_minutesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
summaryYes
page_urlYes
rounds_textNoPresent when a draw was generated — show it to the organiser as-is.
players_addedYes
draw_generatedYes
tournament_keyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / request_id
      Added value: +{
      +  "description": "Optional idempotency id — retrying the call with the same id returns the same tournament and key instead of creating a second one. It doubles as the secret that guards that replay, so it must be at least 16 characters of your own random choosing (a UUID is ideal); short or predictable ids are refused before anything is created.",
      +  "maxLength": 64,
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / language / description
      Previous value: -"Language of the tournament page, PDFs and player emails. Default en; set et when the organiser works in Estonian."New value: +"Language of the tournament page, PDFs and player emails (ISO 639-1). Default en; set it to the language the organiser is writing in when it is in this list."
    • changedInput schema / properties / language / enum
      Previous value: -[
      -  "en",
      -  "et"
      -]New value: +[
      +  "en",
      +  "bg",
      +  "hr",
      +  "cs",
      +  "da",
      +  "nl",
      +  "et",
      +  "fi",
      +  "fr",
      +  "de",
      +  "el",
      +  "hu",
      +  "it",
      +  "lv",
      +  "lt",
      +  "nb",
      +  "pl",
      +  "ro",
      +  "sk",
      +  "sl",
      +  "sv",
      +  "uk",
      +  "es",
      +  "pt",
      +  "ar",
      +  "bn",
      +  "zh",
      +  "hi",
      +  "id",
      +  "ja",
      +  "ko",
      +  "ru",
      +  "tr",
      +  "ur",
      +  "vi"
      +]
  3. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  4. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"Defaults to '<Sport> tournament <date>'"New value: +"Defaults to '<Sport> tournament 14 Aug 2026 (<location>)' — start date (or today) plus the location when known"
  5. Changed1 schema field changed
    • changedInput schema / properties / page_results_entry / description
      Previous value: -"Allow anyone with the page link to enter scores courtside. Default false; switchable any time via update_settings or the toggle on the page."New value: +"Allow anyone with the page link to enter scores courtside. Default TRUE — recreational tournaments run on whoever finishes their match first, and an organiser who has to type every result is the bottleneck. Pass false if the organiser wants to be the only one recording scores; switchable either way at any time via update_settings or the toggle on the page."
  6. Changed2 schema fields changed
    • removedInput schema / properties / house_rules / items / minLength
      Removed value: -1
    • removedInput schema / properties / players / items / properties / name / minLength
      Removed value: -1
  7. Changed5 schema fields changed
    • addedInput schema / properties / gender_balance
      Added value: +{
      +  "description": "Americano/mexicano: prefer matches where both teams have the same make-up (MM v MM, MW v MW, WW v WW). Default prefer_symmetric. A preference, not a rule — an uneven field cannot supply it, and the draw says so rather than distorting the rotation.",
      +  "enum": [
      +    "prefer_symmetric",
      +    "off"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / level_gap_cap
      Added value: +{
      +  "description": "Opt-in: the largest level gap the organiser wants between opponents, in their own level units. Soft — the draw prefers to respect it and reports when it cannot. Pass 0 to clear.",
      +  "maximum": 1000,
      +  "minimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / level_offset
      Added value: +{
      +  "description": "by_group only: how much stronger an m is than an f carrying the SAME number, in the organiser's own level units. Default 1 — a starting point to adjust, not a fact. Used for balancing only; never shown on the page or in standings.",
      +  "maximum": 1000,
      +  "minimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / level_scale
      Added value: +{
      +  "description": "How to read the numbers in `level`. absolute (default): one shared scale, a 3 is a 3 whoever holds it. by_group: men and women were each rated within their own group, so the numbers are not directly comparable — ask the organiser which they did rather than guessing. ignore: the numbers are notes, never used for the draw.",
      +  "enum": [
      +    "absolute",
      +    "by_group",
      +    "ignore"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / sport / description
      Added value: +"Write sport names to the organiser in words — 'table tennis', never the enum spelling 'table_tennis'."
  8. Changed1 schema field changed
    • changedInput schema / properties / discipline / description
      Previous value: -"Default singles; americano/mexicano are always doubles"New value: +"Ask the organiser — never infer it from the sport. Americano/mexicano are always doubles. Defaults to singles for the bracket formats when they truly have no preference."
  9. Changed1 schema field changed
    • addedInput schema / properties / location
      Added value: +{
      +  "description": "Venue/location shown to players on the page, e.g. club name + city",
      +  "maxLength": 160,
      +  "type": "string"
      +}
  10. Changed2 schema fields changed
    • addedInput schema / properties / players / items / properties / level / maximum
      Added value: +10000
    • addedInput schema / properties / players / items / properties / level / minimum
      Added value: +-10000
  11. Changed1 schema field changed
    • addedOutput schema / properties / rounds_text
      Added value: +{
      +  "description": "Present when a draw was generated — show it to the organiser as-is.",
      +  "type": "string"
      +}
  12. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false): omitting 'format' makes the call create nothing and instead return a relay-able menu, and the call returns an organiser key that cannot be recovered plus a shareable page link. It does not cover auth/permission requirements or rate limits, but the conditional non-creation branch is exactly the non-obvious trait an agent needs.

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?

Front-loaded with purpose, then organized around a capitalized FORMAT directive, and every sentence carries a distinct rule rather than filler. It is dense prose for a 28-parameter tool, and some of the rules would scan faster as a short list, but the length is justified by the decision complexity.

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 28-param creation tool with an output schema already present, the description covers everything an agent needs: the minimal question set, the menu branch, the headcount/self-signup path, rounds derivation, and the secret-key relay warning. Return values are correctly left to the output schema.

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?

With 82% schema coverage the baseline would be 3, but the description adds real parameter-level meaning: which four fields to actually solicit, when to pass vs omit 'format', the signup_cap fallback for headcount-only organisers, deriving 'rounds' from a time budget, and the ban on placeholder player names. It leaves the remaining 18+ params (level_scale, level_offset, gender_balance, etc.) entirely to the schema.

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?

Opens with a specific verb+resource ('Create a new tournament') and immediately distinguishes itself from siblings by naming add_players as the follow-up path for a different job. An agent can tell this is the creation entry point without opening any 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?

Gives explicit when-to-use rules: ask only for sport/players/court count/start time, never ask an open format question, use signup_open when there is no player list, and route unlisted formats to record_feedback. It also states the alternative path when format is omitted (a menu is returned instead of a tournament).

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.