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

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedAug 25, 2026

changedInput schema / properties / language / description

Previous value: -"Page/PDF/email language: en (default) or et"New value: +"Page/PDF/email language, ISO 639-1 (default en)"

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 changedJul 31, 2026

changedInput schema / properties / page_results_entry / description

Previous value: -"Allow anyone with the page link to enter scores courtside (off by default)"New value: +"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."

Changed1 schema field changedJul 31, 2026
- removedInput schema / properties / house_rules / items / minLength
```
Removed value: -1
```

Changed2 schema fields changedJul 31, 2026

addedOutput schema / properties / promoted

Added value: +{
+  "description": "Waitlisted players a raised cap let in",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "courts",
-  "summary"
-]New value: +[
+  "courts",
+  "promoted",
+  "summary"
+]

Changed4 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"
+}

Changed1 schema field changedJul 29, 2026

addedInput schema / properties / location

Added value: +{
+  "description": "Venue/location shown to players; pass an empty string to clear it",
+  "maxLength": 160,
+  "type": "string"
+}

First observedJul 29, 2026

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

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.