turnale

Update settings

update_settings

Change the tournament name, start time, match duration, break/changeover minutes, courts (count or names), house rules, or courtside score entry from the page. Court changes recompute the remaining schedule; played matches never move.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No
`courts`	No
`language`	No	Page/PDF/email language, ISO 639-1 (default en)
`location`	No	Venue/location shown to players; pass an empty string to clear it
`request_id`	No	Optional idempotency id — retrying a call with the same id never applies it twice
`signup_cap`	No
`start_time`	No	ISO datetime with offset. Must be within 365 days from today.
`court_names`	No
`house_rules`	No
`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 or close self-signup on the page
`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
`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.
`tournament_key`	Yes	The tournament's organiser key (starts with tk_)
`page_results_entry`	No	Allow anyone with the page link to enter scores courtside. ON for new tournaments — pass false when the organiser wants to be the only one recording results, true to hand it back to the players.
`match_duration_minutes`	No

Output Schema

TableJSON Schema

Name	Required	Description
`courts`	Yes
`preview`	No	True when this is a preview — nothing was changed
`summary`	Yes	What happened, in one line
`promoted`	Yes	Waitlisted players a raised cap let in

TDQS

A3.9/5.0

Behavior4/5

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

The description adds a meaningful behavioral warning beyond the annotations: court changes recompute the remaining schedule, and played matches never move. That is exactly the kind of side-effect an agent needs to know before mutating settings, and it is not captured by the readOnly or destructive annotations.

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 compact and deliberately written: the first sentence enumerates the scope of settings, and the second sentence gives the most important side-effect. There is no filler, and the important invariant stays within a short field.

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

Completeness3/5

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

For an 18-property mutation tool, the description only states a subset of what can be changed, omitting signup controls, language, location, and level options. The schema helps compensate, but the description by itself does not fully convey all the setting categories this tool can operate on.

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 about two-thirds, so the schema already carries most parameter meaning. The description only mirrors a subset of field names such as courts and match duration without adding constraints, defaults, or format guidance, and it does not help for the remaining undocumented 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 states a specific verb, 'Change'/'Update', with a concrete resource: tournament settings. It names several fields such as name, start time, match duration, courts, house rules, and courtside score entry, making it clear that this tool is about settings rather than players, draws, or results.

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?

The description implies usage by listing the kinds of settings that can be changed, but it never explicitly says when to use this tool instead of alternatives or when not to use it. The context is recognizable, but the agent has to infer it rather than being directed.

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.

Update settings

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources