turnale

Record results

record_results

Record one or many results. Score is conversational text: "6-4 3-6 10-7" (sets) or "16-8" (americano points). Outcomes: completed (default), walkover, retired (partial score allowed), cancelled, reinstate — reinstate CLEARS a recorded result and returns the match to scheduled (the fix for a mis-entered score). Corrections simply re-record. Winner (a|b = first|second listed side) only needed when the score alone does not decide.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tournament_key": "<tournament_key>",
      "results": "<results>"
    },
    "name": "record_results"
  }
}

Input Schema

Name	Required	Description
`results`	Yes
`request_id`	No	Optional idempotency id — retrying a call with the same id never applies it twice
`tournament_key`	Yes	The tournament's organiser key (starts with tk_)

Output Schema

Name	Required	Description
`preview`	No	True when this is a preview — nothing was changed
`summary`	Yes	What happened, in one line
`recorded`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedNov 1, 2026
- removedOutput schema / properties / recorded / items / properties / court / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / recorded / items / properties / court / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / recorded / items / properties / estimated_start / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / recorded / items / properties / estimated_start / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / recorded / items / properties / retired / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / recorded / items / properties / retired / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / recorded / items / properties / score / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / recorded / items / properties / score / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / recorded / items / properties / winner / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / recorded / items / properties / winner / type
```
Added value: +[
+  "string",
+  "null"
+]
```

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 29, 2026
- addedInput schema / properties / results / items / properties / score / maxLength
```
Added value: +120
```
First observedJul 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds substantial behavior beyond the annotations: it discloses that reinstate CLEARS a recorded result and returns the match to scheduled, and that corrections are idempotent re-records. One tension is worth noting — annotations declare destructiveHint=false while a supported mode clears previously recorded data — but since the cleared result is re-recordable this reads as a reset rather than a contradiction. Batch semantics (atomic vs. partial application) are not stated.

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-loads the core action and packs a lot of decision-relevant detail into a few sentences with no filler. The heavy use of parentheticals and em-dash clauses makes it dense to parse, but almost every clause carries information the agent needs.

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?

An output schema exists, so return values need not be explained, and the description covers the tricky parts: score syntax, outcome semantics, and winner disambiguation. The remaining gap is batch behavior — whether a 100-item call succeeds or fails as a unit when one match_id is invalid.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Substantially exceeds the 67% schema coverage: the schema only types score as a string, while the description supplies the actual syntax with worked examples ("6-4 3-6 10-7" vs "16-8"). It also decodes the otherwise opaque winner enum as first/second listed side and adds behavior to each outcome value.

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 and resource ("Record one or many results") and immediately scopes it with concrete domain semantics — score formats for sets vs. americano points. The verb "record" cleanly separates it from the read-side sibling get_results without needing to name it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit guidance for each outcome mode: reinstate is framed as "the fix for a mis-entered score," corrections are described as simply re-recording, and winner is scoped to cases where the score alone doesn't decide. It stops short of naming alternatives such as undo_last_change for reversing a batch, but the when-to-use picture 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.