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

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation3/5

Several tools serve overlapping purposes: get_pdf and get_pdf_link both return PDF artifacts, get_schedule and list_matches both provide match scheduling info, and get_results vs. get_standings can be confused for finished tournaments. However, the descriptions clarify the distinctions (embedded vs. link, upcoming vs. all matches, final vs. current standings), and roster-management tools are clearly separated by action.

Naming Consistency5/5

All 30 tools consistently use lowercase snake_case with a verb_noun pattern (e.g., create_tournament, record_results, withdraw_player). The only slight variation is the mix of get_* and list_* for read operations, but that's a common and predictable convention. There are no camelCase or inconsistent verb styles.

Tool Count2/5

With 30 tools, the server exceeds the 'too many' threshold of 25. While the domain is complex, this count is heavy and may overwhelm agents, especially since several tools could be consolidated (e.g., get_pdf/get_pdf_link, get_schedule/list_matches). A more streamlined set around 20 tools would be more appropriate.

Completeness5/5

The tool set provides comprehensive lifecycle coverage for tournament management: create/delete/end tournaments, manage players (add, remove, replace, withdraw, promote, update), generate draws, record results, handle doubles pairs, reschedule, retrieve standings/schedule/results, export/PDF, audit log, undo changes, and feedback. No major gaps are apparent for the stated purpose.

Create tournament

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources