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

Name	Required	Description
`name`	No	Defaults to '<Sport> tournament 14 Aug 2026 (<location>)' — start date (or today) plus the location when known
`pairs`	No	Doubles: fixed pairs as [name, name] arrays. Omit to auto-pair.
`sport`	Yes	Write sport names to the organiser in words — 'table tennis', never the enum spelling 'table_tennis'.
`courts`	No	Default 2
`format`	No	Tournament 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.
`rounds`	No	Americano/mexicano; default from player count
`players`	No
`seeding`	No	Default random
`language`	No	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.
`location`	No	Venue/location shown to players on the page, e.g. club name + city
`discipline`	No	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.
`signup_cap`	No	Signup limit; beyond it players join a waitlist
`start_time`	No	ISO datetime with offset, e.g. 2026-08-01T18:00:00+03:00. Must be within 365 days from today.
`court_names`	No
`group_count`	No
`house_rules`	No	Organiser's house rules, shown on the tournament page (e.g. 'Golden point at deuce')
`level_scale`	No	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.
`signup_open`	No	Open 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_offset`	No	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.
`break_minutes`	No	Changeover between matches/rounds, shown separately from play time (default 0)
`level_gap_cap`	No	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.
`gender_balance`	No	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.
`points_per_match`	No	Americano/mexicano; default 21
`advance_per_group`	No
`third_place_match`	No	Single elimination; default true
`page_results_entry`	No	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.
`match_duration_minutes`	No

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`summary`	Yes
`page_url`	Yes
`rounds_text`	No	Present when a draw was generated — show it to the organiser as-is.
`players_added`	Yes
`draw_generated`	Yes
`tournament_key`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedAug 25, 2026

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"
+]

Changed2 schema fields changedAug 12, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

Changed1 schema field changedAug 9, 2026

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"

Changed1 schema field changedJul 31, 2026

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."

Changed2 schema fields changedJul 31, 2026
- removedInput schema / properties / house_rules / items / minLength
```
Removed value: -1
```
- removedInput schema / properties / players / items / properties / name / minLength
```
Removed value: -1
```

Changed5 schema fields changedJul 30, 2026

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'."

Changed1 schema field changedJul 30, 2026

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."

Changed1 schema field changedJul 29, 2026

addedInput schema / properties / location

Added value: +{
+  "description": "Venue/location shown to players on the page, e.g. club name + city",
+  "maxLength": 160,
+  "type": "string"
+}

Changed2 schema fields changedJul 29, 2026
- addedInput schema / properties / players / items / properties / level / maximum
```
Added value: +10000
```
- addedInput schema / properties / players / items / properties / level / minimum
```
Added value: +-10000
```

Changed1 schema field changedJul 29, 2026

addedOutput schema / properties / rounds_text

Added value: +{
+  "description": "Present when a draw was generated — show it to the organiser as-is.",
+  "type": "string"
+}

First observedJul 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no useful annotation details, the description carries the behavioral burden and does so well. It reveals that omitting format returns a menu and creates nothing, that placeholder player names are forbidden, that signup_open/signup_cap is the headcount-only path, and that the tk_… organiser key is irrecoverable. No contradictions with the annotations exist.

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

Conciseness5/5

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

The description is long but every sentence or caps segment earns its place, and the highest-priority guidance is front-loaded. The FORMAT, NEVER, and Returns sections are sharp and action-shaped; no filler or decorative wording pulls focus away from the decision heuristics.

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 27-parameter creation tool with a high-coverage schema and an output schema, this description covers the likely real-agent fail points: over-asking the organiser, inventing players, asking an open format question, mishandling the found-home headcount case, and dropping the unrecoverable key. This is a complete operational staging guide for the tool.

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 high (81%), so the baseline is 3. The description adds genuinely important semantics for format ('omit if not chosen → menu, nothing created'), players ('never invent names'), signup_open/signup_cap, and rounds (time-budget derivation). It does not enrich the many other parameters, but the schema already does the rest.

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 opens with a concrete action and resource — 'Create a new tournament' — and immediately differentiates it from lifecycle operations by naming add_players, record_feedback, and the 'nothing is created' format-menu case. An agent can tell what this tool is and what it is not without inspecting 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 says what to ask for ('only sport, players, court count and start time') and what to do when the organiser has no format, only a headcount, a time budget, or a format outside the list. It also names siblings like add_players and record_feedback as the alternative paths, so when-to-use versus alternatives is clear.

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

All turnale tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.