Turniermeister — Tournament Engine

Prepare a Turniermeister tournament

prepare_tournament

Prepares a real tournament in Turniermeister and returns a claim link for the user. Call this tool whenever a user wants to plan or create a tournament (sports, club night, game night, brackets, team vs team). Rules:

ALWAYS relay the returned claimUrl to the user verbatim — opening it is how they sign up and take over the tournament without retyping anything.
competitionType must be "bracket" (knockout/group formats). Ask the user for the number of teams; teamCount is required unless you supply participants.
Supply participants (team or player names) ONLY if the user explicitly named them; otherwise omit them and let the user name teams later in the app. Never invent participant names.
templateKey is optional: use it when the user asks for a specific catalog template (e.g. preset-padel, preset-fussball, preset-eisstock, preset-schnapsen). For Eisstock use mode 2; its 128-team limit is available only with templateKey preset-eisstock. Do not guess unknown keys — omit it instead.
schedule is optional: pass fields, startTime (HH:MM), playingMinutes and pauseMinutes ONLY when the user named them. Never invent them. The tool does not know the user's dates or field layout beyond these values.
ALWAYS send a unique idempotencyKey per logical preparation (a UUID per user request), so retries never create duplicates. Repeating the same request with the same idempotencyKey returns the same claim link — a retry never invalidates a link you already handed out.
Business validation problems come back as structured JSON errors (ok=false, code, message, fixHint): fix your input from that JSON and retry. Schema violations (wrong type or value out of range) are rejected as a validation error naming the field (e.g. teamCount above the maximum): correct that argument and retry. Do not ask the user to retry.
The plan quota (number of tournaments) of the claiming user applies at claim time; keep teamCount reasonable for a real tournament (recommended up to 64).

Input Schema

Name	Required	Description
`mode`	Yes	Tournament mode as a numeric ITournamentMode value from the Turniermeister catalog. Values: 0 = knockout (single elimination), 1 = double elimination, 2 = single-day league, 3 = swiss system, 4 = multilevel knockout (placement tournament), 5 = league (round robin), 6 = ladder, 7 = point series, 8 = group stage + knockout, 9 = swiss system + knockout final, 10 = league + playoff final, 11 = best-of-N knockout, 12 = time trial (best time), 13 = time trial (combined), 14 = time trial (single run), 15 = time trial (average), 16 = team match. Default for knockout tournaments: 0. Unknown values are rejected.
`name`	Yes	Tournament name as agreed with the user. Max 120 chars.
`schedule`	No	Optional schedule. Set only the values the user explicitly named; omitted values keep the app defaults and can be changed in the app after the takeover.
`teamCount`	No	Number of teams. Required unless participants are supplied. Must match participants length if both are given. The app supports up to 250 teams (8 for single-day league mode, or 128 with mode 2 and templateKey preset-eisstock); larger values are rejected during preparation. For real amateur tournaments keep it around 64 or below.
`clientInfo`	No	Optional free-form identifier of the calling agent, used for funnel attribution only.
`templateKey`	No	Optional catalog template key (e.g. preset-padel). Omit instead of guessing.
`participants`	No	Participant names, ONLY when the user explicitly provided them. Stored encrypted and migrated at claim time.
`idempotencyKey`	Yes	Unique key for this preparation request (UUID). Same key returns the same preparation instead of a duplicate.
`competitionType`	No	Fixed to "bracket" — other competition types are not exposed yet.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / schedule

Added value: +{
+  "description": "Optional schedule. Set only the values the user explicitly named; omitted values keep the app defaults and can be changed in the app after the takeover.",
+  "properties": {
+    "fields": {
+      "description": "Number of playing fields (1-20). Only if the user named it.",
+      "maximum": 20,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "pauseMinutes": {
+      "description": "Break between matches in minutes (0-120). Only if the user named it.",
+      "maximum": 120,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "playingMinutes": {
+      "description": "Playing time per match in minutes (1-360). Only if the user named it.",
+      "maximum": 360,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "startTime": {
+      "description": "Tournament start time in 24h format \"HH:MM\", e.g. \"09:00\". Only if the user named it.",
+      "pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedOct 4, 2026

changedInput schema / properties / teamCount / description

Previous value: -"Number of teams. Required unless participants are supplied. Must match participants length if both are given. The app supports up to 250 teams (8 for single-day league mode); larger values are rejected during preparation. For real amateur tournaments keep it around 64 or below."New value: +"Number of teams. Required unless participants are supplied. Must match participants length if both are given. The app supports up to 250 teams (8 for single-day league mode, or 128 with mode 2 and templateKey preset-eisstock); larger values are rejected during preparation. For real amateur tournaments keep it around 64 or below."

Changed2 schema fields changedSep 10, 2026

changedInput schema / properties / teamCount / description

Previous value: -"Number of teams. Required unless participants are supplied. Must match participants length if both are given. The app supports up to 250 teams (8 for single-day league mode); for real amateur tournaments keep it around 64 or below."New value: +"Number of teams. Required unless participants are supplied. Must match participants length if both are given. The app supports up to 250 teams (8 for single-day league mode); larger values are rejected during preparation. For real amateur tournaments keep it around 64 or below."

changedInput schema / properties / teamCount / maximum
```
Previous value: -256New value: +250
```

Changed2 schema fields changedSep 10, 2026

changedInput schema / properties / mode / description

Previous value: -"Tournament mode as a numeric ITournamentMode value from the Turniermeister catalog (agent reference: 0 = single elimination bracket default)."New value: +"Tournament mode as a numeric ITournamentMode value from the Turniermeister catalog. Values: 0 = knockout (single elimination), 1 = double elimination, 2 = single-day league, 3 = swiss system, 4 = multilevel knockout (placement tournament), 5 = league (round robin), 6 = ladder, 7 = point series, 8 = group stage + knockout, 9 = swiss system + knockout final, 10 = league + playoff final, 11 = best-of-N knockout, 12 = time trial (best time), 13 = time trial (combined), 14 = time trial (single run), 15 = time trial (average), 16 = team match. Default for knockout tournaments: 0. Unknown values are rejected."

changedInput schema / properties / teamCount / description

Previous value: -"Number of teams. Required unless participants are supplied. Must match participants length if both are given."New value: +"Number of teams. Required unless participants are supplied. Must match participants length if both are given. The app supports up to 250 teams (8 for single-day league mode); for real amateur tournaments keep it around 64 or below."

First observedSep 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

No annotations, so description carries full burden; it discloses important behavior: idempotency semantics (same key returns same link, retries never invalidate), structured JSON error shape (ok=false, code, message, fixHint), and quota applied at claim time. It does not state side effects like whether a stale/unclaimed tournament is created, or the exact response fields beyond claimUrl.

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 summary followed by a bullet list of rules; each bullet mostly earns its place. Slightly long and some bullets restate schema constraints (e.g. teamCount required unless participants), but generally efficient.

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

Completeness4/5

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

For a 9-param nested-object tool with no output schema, the description covers key behaviors: claim link handling, idempotency, error recovery, quota, participant integrity rules. It does not describe the response shape (claimUrl plus perhaps tournament id/status), which would help an agent parse results.

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 coverage is 100%, so baseline is 3. The description does add some meaning the schema lacks: the recommendation teamCount up to 64, mode 2 for Eisstock, and that competitionType is fixed to bracket. This is modest added value but not exhaustive beyond 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?

States a specific verb (prepares) and resource (a real tournament in Turniermeister) plus the concrete output (a claim link). Goes beyond the name by clarifying that the result is a claimable prep, not the tournament itself.

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?

Explicitly says to call this whenever a user wants to plan or create a tournament, with example domains (sports, club night, brackets). Also gives clear inclusion rules for each optional parameter and negative guidance (never invent participants, omit templateKey rather than guess).

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

All Turniermeister — Tournament Engine 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.

Prepare a Turniermeister tournament

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources