Free tournament organiser for humans & AI agents — set up, draw brackets, score matches, and run hall projector displays by prompt.
Scored across 25 tools
Most tools target clearly distinct resources and actions, such as add_court vs add_entry and get_stage_table vs list_standings. A few pairs are related enough to require care, especially list_on_club vs publish_tournament and the several create_* tools around tournaments, clubs, stages, displays, and handoffs. Overall the boundaries are clear, with only minor overlap.
The tool names consistently use snake_case with a predictable verb_noun pattern: add_*, create_*, get_*, list_*, update_*, generate_*, publish_*, and resolve_*. list_on_club is slightly unusual but still readable and clearly an action on a tournament. There is no mixing of casing or naming styles.
At 25 tools, the surface is at the heavy end for an MCP server and risks burdening an agent with many choices. The tournament domain is broad, covering tournaments, stages, pools, fixtures, courts, entries, standings, clubs, displays, and handoffs, so each tool has a plausible purpose. Still, the count is borderline heavy rather than well-scoped.
The core tournament workflow is covered: create tournament, add entries, create and generate stages, list fixtures, update scores, view standings/tables, manage courts, publish, and hand off. However, the surface lacks deletion/removal operations for entries, courts, stages, fixtures, and tournaments, and it has no update operations for tournament metadata or stage details. These are notable gaps that an agent would likely hit when correcting or cleaning up a tournament.
Add a court, pitch or table. Courts are what the schedule puts matches on and what the projector groups them by, so a tournament with none can be played but not organised: update_fixture's court argument has nothing to point at.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Court name, e.g. 'Court 1' | |
| position | No | Order on the screen, 0-based (default: after the last one) | |
| tournament_id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| id | Yes | Record ID |
| name | Yes | Name |
| active | Yes | Whether it is in use |
| position | Yes | Order, 0-based; in a table, the rank |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare it is not read-only, not destructive, and not idempotent. The description adds valuable domain context: a tournament without courts can still be played but is not organised. This explains the practical consequence of the tool's absence, which goes beyond standard safety flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core purpose is front-loaded, and the second sentence efficiently explains the entity's role and a key dependency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations cover the safety profile, the schema covers parameters, and an output schema exists for return values, the description provides sufficient domain context for an agent to call this correctly. It could be marginally improved by noting any prerequisite permissions, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents name, position, and tournament_id. The description does not add any syntax or format details for these parameters. Baseline 3 is correct when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Add a court, pitch or table'). It further distinguishes the entity's role by relating it to scheduling and projector grouping. An agent can immediately tell this is a creation tool for physical playing surfaces, distinct from create_stage or add_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for why you would use it: courts are needed for the schedule and projector. It even explains a downstream dependency (update_fixture's court argument). However, it doesn't explicitly state when NOT to use it or name a direct alternative for creating venues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a team/participant to a tournament
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Team name | |
| seed | Yes | Seed (position) | |
| tournament_id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| id | Yes | Record ID |
| name | Yes | Name |
| seed | Yes | Seed |
| status | Yes | Status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations specify readOnlyHint=false, idempotentHint=false, confirming a non-idempotent write. The description adds context that the entity being added is a team/participant to a tournament, which is useful behavioral framing. However, it doesn't disclose side effects like whether seeds are unique or whether the tournament must be in a certain state. With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and target, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with annotations and an output schema, the description is minimal. It conveys the core action but omits prerequisites (e.g., tournament must exist) and any behavioral traits beyond safety hints. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no parameter-specific details beyond the schema, so baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Add') and resource ('team/participant to a tournament'), clearly distinguishing it from siblings like add_court or create_tournament.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., add_court, create_tournament), nor any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a public page for a club at /c/{slug}, which lists the tournaments put on it with list_on_club. One per account, and only on a signed-in account: the temporary one create_tournament makes is gone when this connection is. The page starts empty; nothing is listed until you list it. The address cannot be changed later, because it ends up printed on posters.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The club's name, e.g. 'TJ Sokol Brno' | |
| slug | No | The address, 3 to 40 lowercase letters and digits joined by single dashes. Default: made from the name, e.g. 'tj-sokol-brno' |
| Name | Required | Description |
|---|---|---|
| id | Yes | Club ID |
| logo | Yes | Path of the uploaded logo on this host, empty when there is none |
| name | Yes | The club's name, as its page shows it |
| slug | Yes | The address: the page is /c/{slug}. Fixed once made |
| accent | Yes | The page's colour as #rrggbb, empty for the default |
| page_url | Yes | The public page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: public visibility, authentication requirement, one-per-account limit, initial empty state, and immutability of the slug because it is printed on posters. It also clarifies that create_tournament's temporary club disappears with the connection, which is important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four tight sentences with the core purpose front-loaded. Each sentence contributes a distinct, useful constraint rather than repeating schema or annotation data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations and an output schema already present, the description supplies the remaining operational context an agent needs: auth requirements, account limit, empty initial state, listing behavior via list_on_club, and slug immutability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description still adds meaningful semantics for the slug parameter by explaining that it forms the public URL and cannot be changed later; name semantics remain schema-only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: making a public club page at /c/{slug}. It also distinguishes the tool from siblings by naming list_on_club and contrasting it with the temporary club created by create_tournament.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear preconditions: one club per account, signed-in account only, and the page starts empty until tournaments are added with list_on_club. It does not explicitly route the agent between related siblings such as update_club or get_my_club, so it falls short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a projector display screen for a published tournament
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name (default: Main screen) | |
| token | No | URL token (default: auto-generated) | |
| tournament_id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| id | Yes | Display ID |
| name | Yes | Display name |
| token | Yes | URL token; anybody who has it can open the screen |
| display_url | Yes | JSON feed the screen reads |
| projector_url | Yes | The page to open on the projector |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds the 'published tournament' precondition, which is real behavioral context. It does not say what happens on a duplicate name/token, whether creation fails when the tournament is unpublished, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loaded with the verb and resource. It is appropriately sized for the tool's simplicity, though it is terse enough to leave questions unanswered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 described, and annotations cover the safety profile. The gap is failure/edge behavior: the stated 'published tournament' precondition is never explained in terms of consequences, and non-idempotency (per annotations) is not surfaced in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents name, token (with auto-generation defaults), and tournament_id. The description adds no parameter-level detail beyond that, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Create) and a specific resource (projector display screen), plus a scoping condition (for a published tournament). That distinguishes it from siblings like create_tournament, create_stage, or add_court. It stops short of naming an alternative, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'For a published tournament' implies a precondition that the agent must create/publish the tournament first, which is genuine usage guidance. However, there is no explicit when-to-use vs. alternative, and no statement of what to do when the precondition is unmet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a link that hands this tournament to a person. They open it, set an email and a password, and the account this session has been acting as becomes theirs. Single use, and it expires. Afterwards this connection can no longer change the tournament — which is the point, so hand it over when the tournament is ready rather than when you are still building it. Only for a tournament made without signing in; a signed-in account already owns what it creates.
| Name | Required | Description | Default |
|---|---|---|---|
| tournament_id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| url | Yes | The link to give to the person taking the tournament over |
| note | Yes | What to tell the person, and what changes once they open it |
| expires | Yes | When the link stops working, UTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag destructive/non-idempotent/closed-world; the description adds the truly consequential behavior: single use, expiry, ownership transfer, and permanent loss of this connection's ability to modify the tournament. It also documents the precondition (unsigned-in tournament) that annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and only mildly conversational ('which is the point'). Every sentence carries information, though the aside-about-readiness could be trimmed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no explanation, and the description still covers preconditions, irreversibility, expiry, and the post-handoff state. An agent has everything required to decide whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers tournament_id at 100% description coverage, so the parameter is already documented; the description refers to 'this tournament' but adds no format, ID source, or validation detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting for a single param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: creates a link that hands a tournament to a person, with the exact mechanic (recipient sets email/password and takes ownership of the current session's account). It is specific enough to separate from siblings like publish_tournament, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('hand it over when the tournament is ready rather than when you are still building it') and an explicit exclusion ('Only for a tournament made without signing in; a signed-in account already owns what it creates'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a stage in a tournament (e.g. round_robin group)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Stage name, e.g. 'Group' or 'Playoff' | |
| config | No | JSON config, e.g. {"poolCount":1} | |
| format | Yes | Format: round_robin, single_elim, double_elim, swiss | |
| position | Yes | Stage position (0-based) | |
| tournament_id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| id | Yes | Record ID |
| name | Yes | Name |
| config | Yes | Format-specific settings, e.g. poolCount |
| format | Yes | round_robin, single_elim, double_elim, swiss or ladder |
| status | Yes | Status |
| position | Yes | Order, 0-based; in a table, the rank |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey the mutation profile (readOnlyHint=false, idempotentHint=false, non-destructive, closed-world), so the safety picture is covered. The description adds no behavioral context beyond that — no prerequisites, no note on whether calling twice duplicates stages, no effect of the config field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no waste. It is arguably too terse for a 4-required-parameter mutation, but nothing is padded or repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 schema fully documents parameters. Still, for a create mutation the description omits prerequisite and ordering context (position is 0-based, tournament must exist) that would help an agent invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter (name, config, format, position, tournament_id) is already described in the schema. The description only echoes 'round_robin' as an example, adding no syntax or constraint detail beyond the structured fields. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a stage in a tournament') with an example of the stage kind. However, it does not differentiate itself from the sibling 'generate_stage', which an agent could easily confuse with this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus 'generate_stage' or 'add_entry', and no mention of prerequisites such as the tournament needing to exist. The only usage signal is the parenthetical example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a draft tournament. Signed in, it is created on that account. Not signed in, it is created on a temporary account that lasts as long as this connection does, and the other tools then work on it for the rest of the connection; use create_handoff to give a person a link that makes it theirs.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Tournament name | |
| sport | No | What is being played: volleyball, football, basketball, tennis, padel, badminton, table_tennis, handball, other. This decides the points, whether a draw is a result at all, and how many sets a match is played to — so getting it wrong scores the whole day wrong. Defaults to "other", which is a generic table rather than a guess. |
| Name | Required | Description |
|---|---|---|
| id | Yes | Record ID |
| name | Yes | Name |
| note | Yes | Which account the tournament was created on |
| sport | Yes | Sport preset the tournament is scored by |
| status | Yes | Status |
| scoring | Yes | The scoring rules the sport preset set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare write/non-idempotent/non-destructive, and the description adds behavior those annotations cannot express: the object starts as a draft, is bound to the current account, and in the anonymous case lives only as long as the connection with subsequent sibling tools operating on it. It stops short of describing what "draft" entails (visibility, publishability) beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action in the first clause, then spends the rest on the signed-in/anonymous fork and the handoff escape hatch. Every clause carries information, though the second sentence is dense and could be split for scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, annotations covering the safety profile, and 100% schema coverage, the remaining burden is lifecycle/auth semantics — exactly what the description supplies (draft state, account binding, connection-scoped temp account, create_handoff path). Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the sport parameter's schema text is unusually rich (enum-like values, scoring effects, "other" default). The description adds nothing about name or sport, so the schema does the work and the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Create a draft tournament") and the "draft" qualifier implicitly separates it from publish_tournament. It does not explicitly name or contrast with siblings such as list_tournaments or create_handoff beyond its role in the lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the two operating contexts (signed in vs. not) and what happens in each, and routes the agent to create_handoff when the tournament needs to be handed to a person. It gives clear context for the anonymous path but does not state when this tool should be preferred over other creation/entry tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate pools, slots and fixtures for a stage. Use dry_run=true to preview without saving.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | Preview only, don't write anything | |
| stage_id | Yes | Stage ID |
| Name | Required | Description |
|---|---|---|
| plan | No | The pools, slots and fixtures that would be written. Dry run only. |
| pools | No | Pools written |
| slots | No | Slots written |
| stage | Yes | Stage ID |
| dry_run | No | True when this was a preview and nothing was written |
| fixtures | No | Fixtures written |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this writes data. The description usefully adds that pool/slot/fixture records are what gets generated and that dry_run previews without saving, but it does not warn whether regenerating a stage overwrites existing fixtures or what permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and immediately followed by the safety-relevant dry_run guidance. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and annotations carry the safety profile, reducing the burden. However, for a destructive generation tool the description omits prerequisites (does the stage need to exist?) and overwrite/repeat-run behavior, which an agent needs to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description only restates the dry_run semantics already given in the schema ('Preview only, don't write anything'). No additional meaning is added beyond the structured fields, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (generate) and enumerates exactly what is produced: pools, slots and fixtures for a stage. This distinguishes it from get_stage/list_stages, though it does not explicitly differentiate it from create_stage or resolve_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The dry_run sentence gives useful operational guidance for one parameter, but the description never says when this tool should be used instead of siblings like create_stage, resolve_stage or update_fixture. Usage is implied by context rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a fixture by ID with games
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Fixture ID |
| Name | Required | Description |
|---|---|---|
| id | Yes | Record ID |
| code | Yes | Short handle for the match, e.g. A1 or QF2 |
| pool | Yes | Pool ID, empty when the stage has no pools |
| court | Yes | Court ID, empty when unassigned |
| games | Yes | |
| loser | Yes | Entry ID of the loser, empty until decided |
| round | Yes | Round, 0-based |
| stage | Yes | Stage ID |
| status | Yes | Status |
| winner | Yes | Entry ID of the winner, empty until decided |
| position | Yes | Order, 0-based; in a table, the rank |
| away_slot | Yes | Slot ID the away side is drawn from |
| home_slot | Yes | Slot ID the home side is drawn from |
| away_entry | Yes | Entry ID of the away side, empty until it is known |
| away_score | Yes | Away score: sets, or goals |
| home_entry | Yes | Entry ID of the home side, empty until it is known |
| home_score | Yes | Home score: sets, or goals |
| scheduled_at | Yes | Scheduled start, UTC, empty when unscheduled |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description's only added behavioral detail is that games are bundled into the response, which is useful but thin for a tool with an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Seven words, front-loaded with the action and resource, and the payload qualifier ('with games') is placed immediately after. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be spelled out, and annotations cover safety and idempotency. The definition is sufficient for correct invocation; only the lack of routing against list_fixtures/update_fixture keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter with 100% schema description coverage, so the schema already documents the ID. The phrase 'by ID' merely restates that and adds no format, source, or resolution guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (fixture) and adds that games are included, so the payload is distinguishable from a bare fetch. It does not explicitly name the sibling list_fixtures to contrast with, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'by ID' — an agent infers this is the single-fixture lookup used when it already has an ID, versus list_fixtures for enumeration. No explicit when-to-use, prerequisites, or named alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The signed-in account's club, if it has one, and every tournament it owns with whether that tournament is on the club's public page. club is null when there is none yet; create_club makes one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| club | Yes | The club, or null |
| tournaments | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuine behavioral detail beyond them: the result can be null, and owned tournaments carry a public-page visibility flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the resource and immediately followed by the null case and the create_club fallback. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return shape need not be spelled out; annotations carry the safety profile and there are no params. The remaining agent questions, what happens when there is no club and how to make one, are both answered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, which sets the baseline at 4. Nothing in the description is needed to disambiguate inputs, and none is offered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific read: the signed-in account's club plus every tournament it owns with the public-page flag. That is a distinct verb+resource combination that separates it from create_club, update_club, and list_tournaments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the null-case condition ('if it has one') and routes the agent to create_club when no club exists. It does not explicitly say when to prefer list_tournaments or get_tournament over this aggregate view, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a stage by ID with its pools
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Stage ID |
| Name | Required | Description |
|---|---|---|
| id | Yes | Record ID |
| name | Yes | Name |
| config | Yes | Format-specific settings, e.g. poolCount |
| format | Yes | round_robin, single_elim, double_elim, swiss or ladder |
| status | Yes | Status |
| created | Yes | When it was created, UTC |
| updated | Yes | When it was last changed, UTC |
| position | Yes | Order, 0-based; in a table, the rank |
| tournament | Yes | Tournament ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety and idempotency are covered. The description adds that pools are returned with the stage, which is useful composition context, but says nothing about auth requirements, error behavior, or what happens with an unknown ID.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler and the key scope detail ('with its pools') front-loaded. It is efficient, though arguably too terse to carry routing information for a 20-sibling toolset.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is not required, and annotations cover the safety profile. Still, in a toolset with many 'get_*' and 'list_*' siblings, the description leaves the agent without enough routing context to pick this over get_stage_table or list_stages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter, so the schema already documents 'id' as the Stage ID. The description's 'by ID' restates the schema rather than adding format, sourcing, or lookup semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (stage) plus a scope detail ('with its pools'), which is more informative than the bare name. However, it does not differentiate itself from siblings like get_stage_table or list_stages, which an agent would need to disambiguate a read by ID from a table/listing read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus list_stages (enumerate) or get_stage_table (table view). The phrase 'by ID' implies a single-record lookup, but no alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a stage's cross-pool table: every pool's first place, then every second, then every third, ranked within each of those tiers. This is what "the best third-placed teams" is decided on, and what a stage_rank slot reads. Provisional until every pool in the stage has finished — readable throughout, but nothing is seeded from it until then.
| Name | Required | Description | Default |
|---|---|---|---|
| stage_id | Yes | Stage ID |
| Name | Required | Description |
|---|---|---|
| standings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds non-obvious operational semantics not present in structured data: the table is readable at any time yet provisional until all pools finish, and nothing is seeded from it until then. That temporal validity warning is exactly the kind of behavioral context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the definition, then usage, then the provisional caveat. Every sentence carries information, though the final clause slightly restates provisionality ('provisional until... readable throughout... nothing is seeded until then').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 remaining agent-facing questions: what the table is, how it is ordered, and whether the data is final. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single stage_id parameter with 100% schema description coverage, so the schema already carries the parameter meaning; the baseline for full coverage is 3. The description only implicitly scopes the result to 'a stage's' table without adding format, ID source, or error semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get a stage's cross-pool table') and then defines the exact content and ordering rule (all first places, then seconds, then thirds, ranked within tier). This is distinct from siblings like list_standings (per-pool standings) or get_stage (stage metadata), so an agent can discriminate without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when the result matters ('what "the best third-placed teams" is decided on, and what a stage_rank slot reads') and when it is authoritative ('provisional until every pool in the stage has finished'). It does not explicitly route the agent away from a sibling (e.g., 'use list_standings for per-pool ordering'), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a tournament by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| id | Yes | Record ID |
| name | Yes | Name |
| sport | Yes | Sport preset the tournament is scored by |
| status | Yes | Status |
| created | Yes | When it was created, UTC |
| scoring | Yes | Scoring rules: points for a win, draw and loss, sets, tiebreakers |
| updated | Yes | When it was last changed, UTC |
| location | Yes | Where it is played |
| description | Yes | Free-text description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no note on error behavior for unknown IDs, no mention of what a fetched tournament includes, and no auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single five-word sentence with the resource and the lookup key front-loaded, and no filler. It is appropriately sized for a trivial single-record fetch, though it is arguably terse enough to omit useful disambiguation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no explanation, and rich annotations cover the safety profile. With the one required parameter fully documented, the only meaningful gap is disambiguation from sibling readers such as get_stage and get_fixture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter 'id' is documented as 'Tournament ID', so the schema carries the full burden. The description's 'by ID' adds no format, sourcing, or constraint detail beyond what the schema already states; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get a tournament') and scopes it to a single record via 'by ID', which distinguishes it from bulk siblings like list_tournaments. It does not, however, explicitly contrast itself with get_fixture/get_stage, so an agent must infer the resource boundary from the noun alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no statement of prerequisites (e.g. needing a valid tournament ID from list_tournaments), and no named alternatives. The correct use case is only implied by the phrase 'by ID'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The courts a tournament is played on. Their ids are what update_fixture's court argument takes.
| Name | Required | Description | Default |
|---|---|---|---|
| tournament_id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| courts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world scope, so the safety profile is covered. The description's added value is the id interlock with update_fixture, but it says nothing about ordering, filtering, or how courts are scoped beyond the tournament.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler, and the resource definition is front-loaded before the id-usage hint. The fragmentary first sentence is telegraphic but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and the single required parameter is schema-documented. The only real gap is the absence of an explicit listing verb and any note on result ordering or scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter exists and schema coverage is 100%, so the schema already documents tournament_id. The description adds no format or constraint detail beyond that, which is the expected baseline when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource precisely ('the courts a tournament is played on') and ties it to a concrete downstream consumer, update_fixture's court argument, which separates it from the write-side sibling add_court. It never states the verb 'list', so the agent relies on the tool name for the action, but the resource and scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives a clear reason to call this tool: to obtain the court ids that update_fixture expects. That is actionable context for a read-before-write workflow, though no explicit when-not or alternative (e.g. add_court) is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List entries (participants) in a tournament
| Name | Required | Description | Default |
|---|---|---|---|
| tournament_id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| entries | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only added value is clarifying that 'entries' means participants; it says nothing about ordering, volume, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the resource and its clarification front-loaded. Nothing is wasted, though it is perhaps too terse to earn a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 described, and the tool has only one simple required parameter. The description is adequate for such a simple read operation, though it could mention scoping or pagination expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single required tournament_id, so the schema fully documents the input. The description adds no parameter-level meaning (e.g., format or scope of the ID), making 3 the appropriate baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('entries'), and the parenthetical '(participants)' disambiguates a potentially ambiguous domain term. It is clear, though it does not distinguish itself from sibling list tools such as list_pools or list_standings beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any stated prerequisites. The agent must infer that this lists tournament participants simply from the name and the single tournament_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List fixtures in a stage, optionally filtered by pool, round, or status
| Name | Required | Description | Default |
|---|---|---|---|
| round | No | Round number (optional) | |
| status | No | Status filter: pending, ready, live, finished, walkover, bye (optional) | |
| pool_id | No | Pool ID (optional) | |
| stage_id | Yes | Stage ID |
| Name | Required | Description |
|---|---|---|
| fixtures | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that — no pagination, ordering, or empty-result behavior — so it neither earns extra credit nor contradicts anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the resource, its scope, and the optional filters with zero filler. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and annotations cover the safety profile; the description is adequate for a simple list operation. It leaves minor gaps around ordering and pagination that an agent might want, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (including the status enum values and round/pool types) are already documented in the schema. The description merely restates the filterable fields without adding format, semantics, or combination rules, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (fixtures) with scope ('in a stage'), which clearly separates it from the singular get_fixture and the mutating update_fixture. It does not explicitly name a sibling or contrast behavior, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Optionally filtered by pool, round, or status' implies the filtering use case, but there is no explicit when-to-use guidance, no statement of when to prefer get_fixture, and no mention of pagination or ordering concerns. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Put a tournament on the club's public page, or take it off with listed=false. The page links to the tournament's screen, so this publishes it: only a tournament this account owns can be listed, and a draft stays off the page until publish_tournament. Sending the same thing twice changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| listed | No | true to list it (default), false to take it off | |
| tournament_id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| club | Yes | Club ID |
| listed | Yes | Whether it is on the page now |
| status | Yes | The tournament's status; a draft is not shown until published |
| page_url | Yes | The club's public page |
| tournament | Yes | Tournament ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'Sending the same thing twice changes nothing', which directly asserts idempotency, while the annotations declare idempotentHint=false. An agent that trusts the prose may retry the call assuming no additional effect, which the structured annotation explicitly denies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, each doing work: the action, the consequence, the ownership/draft gate. Front-loaded with the operation. The final idempotency sentence is the only one that misfires, but for the wrong reason rather than length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 needn't be explained. Ownership requirements, publishing side effects, and the draft gate are all covered. The one gap is that the idempotency statement conflicts with the annotation, leaving the agent unsure what to trust on retries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description goes beyond the schema by explaining that listing publishes the tournament (the page links to the tournament's screen) and that a draft stays off the page. It still doesn't discuss the default value of `listed` explicitly — the schema does that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource with its scope: 'Put a tournament on the club's public page, or take it off with listed=false.' It also distinguishes itself from the sibling publish_tournament by naming the condition under which that tool is needed instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear precondition ('only a tournament this account owns can be listed') and routes the agent to publish_tournament when the tournament is still a draft. The removal path is explicitly named (listed=false). No explicit when-not guidance beyond those gates, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pools in a stage
| Name | Required | Description | Default |
|---|---|---|---|
| stage_id | Yes | Stage ID |
| Name | Required | Description |
|---|---|---|
| pools | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world behavior, so the safety profile is fully covered structurally. The description adds nothing on top of them — no ordering, pagination, empty-result behavior, or note about what a pool contains. It only restates the schema's stage scoping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five words, front-loaded with the verb and resource, no filler or hedging. It is appropriately sized for a trivial single-parameter list tool, though it is terse enough that it could afford one clarifying clause without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no explanation, and the annotations cover safety and idempotency. What remains missing is any usage context — for a tool whose resource ('pool') is not otherwise defined anywhere in the description, the definition is barely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is documented as 'Stage ID' in the schema, so the description's 'in a stage' phrase is redundant rather than additive. Baseline 3 applies when the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb ('List') and resource ('pools') with a scoping qualifier ('in a stage'), so the agent knows exactly what is returned and how it is constrained. It does not need to distinguish itself from siblings since no other pool-named tool exists, but it also gives no hint about what a pool is relative to the closely named list_standings/list_stages family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives, no preconditions, and no exclusions. The scope 'in a stage' weakly implies the caller must already have a stage, but the requirement is left entirely to the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List stages in a tournament
| Name | Required | Description | Default |
|---|---|---|---|
| tournament_id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| stages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds nothing beyond them (no result shape, ordering, or scope caveats), so it earns no credit beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single six-word sentence with zero filler and the resource/scope front-loaded. It is efficient, though it is so terse that it borders on under-specification rather than pure conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with a full annotation set and an output schema covering return values, almost everything the agent needs is present. The only gap is the missing explicit routing versus get_stage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter and schema description coverage is 100%, so the schema already documents tournament_id fully. The description restates the scope but adds no format, ID source, or validation detail beyond the schema, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('List') and resource ('stages') scoped to a tournament, which clearly separates it from create_stage, generate_stage, and resolve_stage. It does not explicitly differentiate from the singular sibling get_stage, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'List' signals plural/collection retrieval while get_stage covers a single stage. There is no explicit statement of when to prefer this tool over get_stage or any prerequisite/context, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List standings for a pool
| Name | Required | Description | Default |
|---|---|---|---|
| pool_id | Yes | Pool ID |
| Name | Required | Description |
|---|---|---|
| standings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds no behavior beyond the name and schema — no statement about ordering, whether the pool must exist, or whether unpublished data is included — so it contributes nothing beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single short sentence with the verb-and-resource front-loaded and zero filler. Nothing is repeated from the title or schema, and it is appropriately sized for a one-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, an output schema exists so return values need not be described, annotations cover safety, and the lone parameter is fully documented. The only real omission is sibling differentiation, which leaves a small but genuine gap in an otherwise complete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter (pool_id) with 100% schema description coverage, so the schema already documents it and the baseline is 3. The description adds no format, scope, or sourcing detail (e.g., where the pool ID comes from), so it neither compensates nor adds meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('standings') scoped to a pool, which is clear enough for an agent to know what it does. However, it does nothing to distinguish itself from siblings that also return tabular/ranking data, notably get_stage_table, so an agent could confuse the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_stage_table despite that sibling looking closely related. The agent must infer the intended context entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the tournaments this session can act on
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tournaments | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety and idempotency profile is fully covered by structured data. The description adds the scoping constraint ('this session can act on'), which clarifies the filtering behavior, but it does not disclose ordering, pagination, or result-size characteristics. Adds some value beyond annotations, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clause, front-loaded with the verb and resource, with every word carrying information. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain the return shape, and zero parameters mean no argument documentation is required. The one remaining gap is that it does not differentiate from sibling list/get tools, which would help an agent choose correctly. Otherwise complete for a no-arg read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. There is nothing for the description to clarify in terms of arguments, and it correctly does not invent any pseudo-parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (tournaments), and adds a meaningful scope qualifier ('this session can act on') that distinguishes it from a hypothetical global list. It does not, however, name or contrast with siblings like get_tournament, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'can act on' implies a permission-filtered listing, which is useful context, but the description gives no explicit when-to-use vs when-not, nor does it point to alternatives such as get_tournament for single-item retrieval. Usage is implied rather than specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a tournament (set status to live) so the display works
| Name | Required | Description | Default |
|---|---|---|---|
| tournament_id | Yes | Tournament ID |
| Name | Required | Description |
|---|---|---|
| id | Yes | Record ID |
| name | Yes | Name |
| status | Yes | Status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the safety burden is partly lifted. The description usefully discloses the exact state transition (status → live), but omits preconditions (e.g., whether stages/entries must exist), reversibility, and why idempotency is declared false for what looks like a status set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the action and parenthetically defining the mechanic and payoff. No filler, though the colloquial trailing clause is slightly loose for a definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no explanation, and the single parameter is covered. However, for a state-transition tool the description omits preconditions for publishing and whether the change can be undone, leaving meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the single parameter is already documented by the schema; baseline is 3. The description adds no format, source, or lookup guidance for tournament_id beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource and goes further by defining what publishing means ('set status to live') plus its consequence ('so the display works'). An agent can distinguish it from create_tournament or generate_stage, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'so the display works' implies the reason to publish (when a tournament should become visible), but there is no explicit when-to-use/when-not-to-use guidance and no named alternative. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-resolve a stage's fixture propagation and standings. Use after correcting scores.
| Name | Required | Description | Default |
|---|---|---|---|
| stage_id | Yes | Stage ID |
| Name | Required | Description |
|---|---|---|
| stage | Yes | Stage ID |
| resolved | Yes | How many updates the resolve made |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the agent knows this mutates and is not safely repeatable. The description adds useful context that it recomputes fixture propagation and standings, but never says what existing data is overwritten or whether re-running repeatedly is risky, which matters for a destructive, non-idempotent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the operation is front-loaded and the triggering condition follows immediately. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 described. For a one-parameter tool with annotations covering the risk profile, the description supplies purpose and timing adequately, though the destructive effects on existing standings/fixtures could be stated more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter (stage_id) with 100% schema description coverage, so the schema already carries the semantics. The description adds no meaning about the identifier, which is the expected baseline when coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Re-resolve") and a concrete resource (a stage's fixture propagation and standings), which an agent can distinguish from siblings like generate_stage, create_stage, and list_standings. The purpose is clear, though it does not explicitly contrast itself with the other stage-manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use after correcting scores" gives an explicit triggering condition, which is more than most siblings likely offer. It stops short of naming alternatives or stating when not to call it (e.g., before scores are corrected), so it is clear context without full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename the signed-in account's club or change its page's colour. Leave out what should stay as it is. The address cannot be changed, and a logo is uploaded on the account screen.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New name | |
| accent | No | Colour as #rrggbb, or an empty string for the default |
| Name | Required | Description |
|---|---|---|
| id | Yes | Club ID |
| logo | Yes | Path of the uploaded logo on this host, empty when there is none |
| name | Yes | The club's name, as its page shows it |
| slug | Yes | The address: the page is /c/{slug}. Fixed once made |
| accent | Yes | The page's colour as #rrggbb, empty for the default |
| page_url | Yes | The public page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the mutation profile is covered. The description adds useful boundaries beyond that — the address is immutable and the logo is managed elsewhere — but says nothing about what the rename affects (e.g. links, existing references) despite being flagged destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the primary action (rename / recolour) before the caveats. No filler, though the second sentence is slightly redundant with the third's partial-update intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no explanation, and the schema fully documents both parameters. The description supplies the scope and the two out-of-scope attributes, leaving only authorization requirements unstated for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (name, accent) are already documented including the #rrggbb format and empty-string default. The description adds only the negative information that address and logo are not accepted here, which is marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the specific resource (the signed-in account's club) and the two mutable attributes (name, page colour), which separates it from create_club and get_my_club. It stops short of an explicit sibling comparison, so an agent must infer the create/read/update split from names alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Leave out what should stay as it is" implies a partial-update pattern, and the note that the logo is set on the account screen rules out one alternative path. However, no condition says when to use this versus get_my_club or create_club, and no prerequisites or prerequisites such as admin rights are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a fixture's score and status (settle a match)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Fixture ID | |
| court | No | Court ID (optional) | |
| status | Yes | New status: finished, walkover, live, ready, pending | |
| winner | No | Winner entry ID (for walkover) | |
| away_score | No | Away score | |
| home_score | No | Home score |
| Name | Required | Description |
|---|---|---|
| id | Yes | Record ID |
| code | Yes | Short handle for the match, e.g. A1 or QF2 |
| status | Yes | Status |
| winner | Yes | Entry ID of the winner, empty until decided |
| away_score | Yes | Away score: sets, or goals |
| home_score | Yes | Home score: sets, or goals |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, non-idempotent, non-readOnly, so safety profile is covered by structured data. The description adds little beyond what annotations provide, though 'settle a match' hints at finality. It does not explain reversibility or what data a status change affects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero waste. Every word earns its place and the main action is stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with subtle implications (settling a match changes tournament standings and stage progression), yet the description does not mention downstream effects or whether the fixture must be in a particular state. With an output schema present, return values need not be explained, but the behavioral context for a destructive update is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all six parameters are already documented in the schema, including status enum values and winner semantics for walkover. The description only names 'score and status' generically, adding no syntax or format detail beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (update) and resource (fixture) with the fields ('score and status') and an example motivation ('settle a match'). It does not name the sibling get_fixture as the read alternative, but the purpose is clear enough to distinguish from list/get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'settle a match' implies a primary use case, but there is no explicit when-to-use vs when-not-to-use guidance, no mention of prerequisites, and no routing to alternative tools for reading the fixture first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_clubget_my_clublist_on_clubupdate_clubcreate_tournament1 field changedOutput schema / requiredPrevious value: -[
- "id",
- "name",
- "sport",
- "status",
- "note",
- "scoring"
-]New value: +[
+ "id",
+ "name",
+ "sport",
+ "status",
+ "scoring",
+ "note"
+]create_tournament1 field changedOutput schema / requiredPrevious value: -[
- "id",
- "name",
- "sport",
- "status",
- "scoring",
- "note"
-]New value: +[
+ "id",
+ "name",
+ "sport",
+ "status",
+ "note",
+ "scoring"
+]create_tournament1 field changedOutput schema / requiredPrevious value: -[
- "id",
- "name",
- "sport",
- "status",
- "note",
- "scoring"
-]New value: +[
+ "id",
+ "name",
+ "sport",
+ "status",
+ "scoring",
+ "note"
+]create_tournament1 field changedOutput schema / requiredPrevious value: -[
- "id",
- "name",
- "sport",
- "status",
- "scoring",
- "note"
-]New value: +[
+ "id",
+ "name",
+ "sport",
+ "status",
+ "note",
+ "scoring"
+]create_tournament1 field changedOutput schema / requiredPrevious value: -[
- "id",
- "name",
- "sport",
- "status",
- "note",
- "scoring"
-]New value: +[
+ "id",
+ "name",
+ "sport",
+ "status",
+ "scoring",
+ "note"
+]create_tournament1 field changedOutput schema / requiredPrevious value: -[
- "id",
- "name",
- "sport",
- "status",
- "scoring",
- "note"
-]New value: +[
+ "id",
+ "name",
+ "sport",
+ "status",
+ "note",
+ "scoring"
+]create_tournament1 field changedOutput schema / requiredPrevious value: -[
- "id",
- "name",
- "sport",
- "status",
- "note",
- "scoring"
-]New value: +[
+ "id",
+ "name",
+ "sport",
+ "status",
+ "scoring",
+ "note"
+]add_court1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "active": {
+ "description": "Whether it is in use",
+ "type": "boolean"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "position": {
+ "description": "Order, 0-based; in a table, the rank",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "position",
+ "active"
+ ],
+ "type": "object"
+}add_entry1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "seed": {
+ "description": "Seed",
+ "type": "integer"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "seed",
+ "status"
+ ],
+ "type": "object"
+}create_display1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "display_url": {
+ "description": "JSON feed the screen reads",
+ "type": "string"
+ },
+ "id": {
+ "description": "Display ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Display name",
+ "type": "string"
+ },
+ "projector_url": {
+ "description": "The page to open on the projector",
+ "type": "string"
+ },
+ "token": {
+ "description": "URL token; anybody who has it can open the screen",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "token",
+ "display_url",
+ "projector_url"
+ ],
+ "type": "object"
+}create_handoff1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "expires": {
+ "description": "When the link stops working, UTC",
+ "type": "string"
+ },
+ "note": {
+ "description": "What to tell the person, and what changes once they open it",
+ "type": "string"
+ },
+ "url": {
+ "description": "The link to give to the person taking the tournament over",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "expires",
+ "note"
+ ],
+ "type": "object"
+}create_stage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "config": {
+ "description": "Format-specific settings, e.g. poolCount",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "format": {
+ "description": "round_robin, single_elim, double_elim, swiss or ladder",
+ "type": "string"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "position": {
+ "description": "Order, 0-based; in a table, the rank",
+ "type": "integer"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "format",
+ "status",
+ "position",
+ "config"
+ ],
+ "type": "object"
+}create_tournament1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "note": {
+ "description": "Which account the tournament was created on",
+ "type": "string"
+ },
+ "scoring": {
+ "description": "The scoring rules the sport preset set",
+ "type": "object"
+ },
+ "sport": {
+ "description": "Sport preset the tournament is scored by",
+ "type": "string"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "sport",
+ "status",
+ "note",
+ "scoring"
+ ],
+ "type": "object"
+}generate_stage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "dry_run": {
+ "description": "True when this was a preview and nothing was written",
+ "type": "boolean"
+ },
+ "fixtures": {
+ "description": "Fixtures written",
+ "type": "integer"
+ },
+ "plan": {
+ "description": "The pools, slots and fixtures that would be written. Dry run only.",
+ "type": "object"
+ },
+ "pools": {
+ "description": "Pools written",
+ "type": "integer"
+ },
+ "slots": {
+ "description": "Slots written",
+ "type": "integer"
+ },
+ "stage": {
+ "description": "Stage ID",
+ "type": "string"
+ }
+ },
+ "required": [
+ "stage"
+ ],
+ "type": "object"
+}get_fixture1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "away_entry": {
+ "description": "Entry ID of the away side, empty until it is known",
+ "type": "string"
+ },
+ "away_score": {
+ "description": "Away score: sets, or goals",
+ "type": "integer"
+ },
+ "away_slot": {
+ "description": "Slot ID the away side is drawn from",
+ "type": "string"
+ },
+ "code": {
+ "description": "Short handle for the match, e.g. A1 or QF2",
+ "type": "string"
+ },
+ "court": {
+ "description": "Court ID, empty when unassigned",
+ "type": "string"
+ },
+ "games": {
+ "items": {
+ "properties": {
+ "away_score": {
+ "description": "Away score: sets, or goals",
+ "type": "integer"
+ },
+ "home_score": {
+ "description": "Home score: sets, or goals",
+ "type": "integer"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "number": {
+ "description": "Set or game number, 1-based",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "home_score",
+ "away_score"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "home_entry": {
+ "description": "Entry ID of the home side, empty until it is known",
+ "type": "string"
+ },
+ "home_score": {
+ "description": "Home score: sets, or goals",
+ "type": "integer"
+ },
+ "home_slot": {
+ "description": "Slot ID the home side is drawn from",
+ "type": "string"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "loser": {
+ "description": "Entry ID of the loser, empty until decided",
+ "type": "string"
+ },
+ "pool": {
+ "description": "Pool ID, empty when the stage has no pools",
+ "type": "string"
+ },
+ "position": {
+ "description": "Order, 0-based; in a table, the rank",
+ "type": "integer"
+ },
+ "round": {
+ "description": "Round, 0-based",
+ "type": "integer"
+ },
+ "scheduled_at": {
+ "description": "Scheduled start, UTC, empty when unscheduled",
+ "type": "string"
+ },
+ "stage": {
+ "description": "Stage ID",
+ "type": "string"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ },
+ "winner": {
+ "description": "Entry ID of the winner, empty until decided",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "code",
+ "status",
+ "round",
+ "position",
+ "home_entry",
+ "away_entry",
+ "home_score",
+ "away_score",
+ "winner",
+ "loser",
+ "court",
+ "scheduled_at",
+ "stage",
+ "pool",
+ "home_slot",
+ "away_slot",
+ "games"
+ ],
+ "type": "object"
+}get_stage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "config": {
+ "description": "Format-specific settings, e.g. poolCount",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "created": {
+ "description": "When it was created, UTC",
+ "type": "string"
+ },
+ "format": {
+ "description": "round_robin, single_elim, double_elim, swiss or ladder",
+ "type": "string"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "position": {
+ "description": "Order, 0-based; in a table, the rank",
+ "type": "integer"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ },
+ "tournament": {
+ "description": "Tournament ID",
+ "type": "string"
+ },
+ "updated": {
+ "description": "When it was last changed, UTC",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "format",
+ "status",
+ "position",
+ "config",
+ "tournament",
+ "created",
+ "updated"
+ ],
+ "type": "object"
+}get_stage_table1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "standings": {
+ "items": {
+ "properties": {
+ "drawn": {
+ "description": "Matches drawn",
+ "type": "integer"
+ },
+ "entry": {
+ "description": "Entry ID",
+ "type": "string"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "lost": {
+ "description": "Matches lost",
+ "type": "integer"
+ },
+ "played": {
+ "description": "Matches played",
+ "type": "integer"
+ },
+ "points": {
+ "description": "Table points",
+ "type": "integer"
+ },
+ "position": {
+ "description": "Order, 0-based; in a table, the rank",
+ "type": "integer"
+ },
+ "score_against": {
+ "description": "Sets or goals conceded",
+ "type": "integer"
+ },
+ "score_for": {
+ "description": "Sets or goals scored",
+ "type": "integer"
+ },
+ "won": {
+ "description": "Matches won",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "position",
+ "entry",
+ "played",
+ "won",
+ "drawn",
+ "lost",
+ "score_for",
+ "score_against",
+ "points"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "standings"
+ ],
+ "type": "object"
+}get_tournament1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "created": {
+ "description": "When it was created, UTC",
+ "type": "string"
+ },
+ "description": {
+ "description": "Free-text description",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "location": {
+ "description": "Where it is played",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "scoring": {
+ "description": "Scoring rules: points for a win, draw and loss, sets, tiebreakers",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "sport": {
+ "description": "Sport preset the tournament is scored by",
+ "type": "string"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ },
+ "updated": {
+ "description": "When it was last changed, UTC",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "sport",
+ "location",
+ "status",
+ "scoring",
+ "description",
+ "created",
+ "updated"
+ ],
+ "type": "object"
+}list_courts1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "courts": {
+ "items": {
+ "properties": {
+ "active": {
+ "description": "Whether it is in use",
+ "type": "boolean"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "position": {
+ "description": "Order, 0-based; in a table, the rank",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "position",
+ "active"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "courts"
+ ],
+ "type": "object"
+}list_entries1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "entries": {
+ "items": {
+ "properties": {
+ "club": {
+ "description": "Club",
+ "type": "string"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "seed": {
+ "description": "Seed",
+ "type": "integer"
+ },
+ "short_name": {
+ "description": "Short name the projector shows",
+ "type": "string"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "short_name",
+ "club",
+ "seed",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "entries"
+ ],
+ "type": "object"
+}list_fixtures1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "fixtures": {
+ "items": {
+ "properties": {
+ "away_entry": {
+ "description": "Entry ID of the away side, empty until it is known",
+ "type": "string"
+ },
+ "away_score": {
+ "description": "Away score: sets, or goals",
+ "type": "integer"
+ },
+ "code": {
+ "description": "Short handle for the match, e.g. A1 or QF2",
+ "type": "string"
+ },
+ "court": {
+ "description": "Court ID, empty when unassigned",
+ "type": "string"
+ },
+ "home_entry": {
+ "description": "Entry ID of the home side, empty until it is known",
+ "type": "string"
+ },
+ "home_score": {
+ "description": "Home score: sets, or goals",
+ "type": "integer"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "pool": {
+ "description": "Pool ID, empty when the stage has no pools",
+ "type": "string"
+ },
+ "position": {
+ "description": "Order, 0-based; in a table, the rank",
+ "type": "integer"
+ },
+ "round": {
+ "description": "Round, 0-based",
+ "type": "integer"
+ },
+ "stage": {
+ "description": "Stage ID",
+ "type": "string"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ },
+ "winner": {
+ "description": "Entry ID of the winner, empty until decided",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "code",
+ "status",
+ "round",
+ "position",
+ "home_entry",
+ "away_entry",
+ "home_score",
+ "away_score",
+ "winner",
+ "court",
+ "stage",
+ "pool"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "fixtures"
+ ],
+ "type": "object"
+}list_pools1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "pools": {
+ "items": {
+ "properties": {
+ "advance_count": {
+ "description": "How many entries go through from this pool",
+ "type": "integer"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "kind": {
+ "description": "group, winners, losers, final or consolation",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "position": {
+ "description": "Order, 0-based; in a table, the rank",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "kind",
+ "position",
+ "advance_count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "pools"
+ ],
+ "type": "object"
+}list_stages1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "stages": {
+ "items": {
+ "properties": {
+ "config": {
+ "description": "Format-specific settings, e.g. poolCount",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "format": {
+ "description": "round_robin, single_elim, double_elim, swiss or ladder",
+ "type": "string"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "position": {
+ "description": "Order, 0-based; in a table, the rank",
+ "type": "integer"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "format",
+ "status",
+ "position",
+ "config"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "stages"
+ ],
+ "type": "object"
+}list_standings1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "standings": {
+ "items": {
+ "properties": {
+ "drawn": {
+ "description": "Matches drawn",
+ "type": "integer"
+ },
+ "entry": {
+ "description": "Entry ID",
+ "type": "string"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "lost": {
+ "description": "Matches lost",
+ "type": "integer"
+ },
+ "played": {
+ "description": "Matches played",
+ "type": "integer"
+ },
+ "points": {
+ "description": "Table points",
+ "type": "integer"
+ },
+ "position": {
+ "description": "Order, 0-based; in a table, the rank",
+ "type": "integer"
+ },
+ "qualified": {
+ "description": "Whether this place goes through to the next stage",
+ "type": "boolean"
+ },
+ "score_against": {
+ "description": "Sets or goals conceded",
+ "type": "integer"
+ },
+ "score_for": {
+ "description": "Sets or goals scored",
+ "type": "integer"
+ },
+ "won": {
+ "description": "Matches won",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "position",
+ "entry",
+ "played",
+ "won",
+ "drawn",
+ "lost",
+ "score_for",
+ "score_against",
+ "points",
+ "qualified"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "standings"
+ ],
+ "type": "object"
+}list_tournaments1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "tournaments": {
+ "items": {
+ "properties": {
+ "created": {
+ "description": "When it was created, UTC",
+ "type": "string"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "location": {
+ "description": "Where it is played",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "sport": {
+ "description": "Sport preset the tournament is scored by",
+ "type": "string"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "sport",
+ "location",
+ "status",
+ "created"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "tournaments"
+ ],
+ "type": "object"
+}publish_tournament1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name",
+ "type": "string"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "status"
+ ],
+ "type": "object"
+}resolve_stage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "resolved": {
+ "description": "How many updates the resolve made",
+ "type": "integer"
+ },
+ "stage": {
+ "description": "Stage ID",
+ "type": "string"
+ }
+ },
+ "required": [
+ "stage",
+ "resolved"
+ ],
+ "type": "object"
+}update_fixture1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "away_score": {
+ "description": "Away score: sets, or goals",
+ "type": "integer"
+ },
+ "code": {
+ "description": "Short handle for the match, e.g. A1 or QF2",
+ "type": "string"
+ },
+ "home_score": {
+ "description": "Home score: sets, or goals",
+ "type": "integer"
+ },
+ "id": {
+ "description": "Record ID",
+ "type": "string"
+ },
+ "status": {
+ "description": "Status",
+ "type": "string"
+ },
+ "winner": {
+ "description": "Entry ID of the winner, empty until decided",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "code",
+ "status",
+ "home_score",
+ "away_score",
+ "winner"
+ ],
+ "type": "object"
+}add_court2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "tournament_id",
- "name",
- "session_token"
-]New value: +[
+ "tournament_id",
+ "name"
+]add_entry2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "tournament_id",
- "name",
- "seed",
- "session_token"
-]New value: +[
+ "tournament_id",
+ "name",
+ "seed"
+]create_display2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "tournament_id",
- "session_token"
-]New value: +[
+ "tournament_id"
+]create_handoff2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "tournament_id",
- "session_token"
-]New value: +[
+ "tournament_id"
+]create_stage2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "tournament_id",
- "name",
- "format",
- "position",
- "session_token"
-]New value: +[
+ "tournament_id",
+ "name",
+ "format",
+ "position"
+]generate_stage2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "stage_id",
- "session_token"
-]New value: +[
+ "stage_id"
+]get_fixture2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "id",
- "session_token"
-]New value: +[
+ "id"
+]get_stage2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "id",
- "session_token"
-]New value: +[
+ "id"
+]get_stage_table2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "stage_id",
- "session_token"
-]New value: +[
+ "stage_id"
+]get_tournament2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "id",
- "session_token"
-]New value: +[
+ "id"
+]list_courts2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "tournament_id",
- "session_token"
-]New value: +[
+ "tournament_id"
+]list_entries2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "tournament_id",
- "session_token"
-]New value: +[
+ "tournament_id"
+]list_fixtures2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "stage_id",
- "session_token"
-]New value: +[
+ "stage_id"
+]list_pools2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "stage_id",
- "session_token"
-]New value: +[
+ "stage_id"
+]list_stages2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "tournament_id",
- "session_token"
-]New value: +[
+ "tournament_id"
+]list_standings2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "pool_id",
- "session_token"
-]New value: +[
+ "pool_id"
+]list_tournaments2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "session_token"
-]New value: +[]publish_tournament2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "tournament_id",
- "session_token"
-]New value: +[
+ "tournament_id"
+]resolve_stage2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "stage_id",
- "session_token"
-]New value: +[
+ "stage_id"
+]update_fixture2 fields changedInput schema / properties / session_tokenRemoved value: -{
- "description": "The session_token returned by create_tournament",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "id",
- "status",
- "session_token"
-]New value: +[
+ "id",
+ "status"
+]create_tournament1 field changedInput schema / properties / sport / descriptionPrevious value: -"What is being played: volleyball, football, basketball, other. This decides the points, whether a draw is a result at all, and how many sets a match is played to — so getting it wrong scores the whole day wrong. Defaults to \"other\", which is a generic table rather than a guess."New value: +"What is being played: volleyball, football, basketball, tennis, padel, badminton, table_tennis, handball, other. This decides the points, whether a draw is a result at all, and how many sets a match is played to — so getting it wrong scores the whole day wrong. Defaults to \"other\", which is a generic table rather than a guess."add_courtadd_entrycreate_displaycreate_handoffcreate_stagecreate_tournamentgenerate_stageget_fixtureget_stageget_stage_tableget_tournamentlist_courtslist_entrieslist_fixtureslist_poolslist_stageslist_standingslist_tournamentspublish_tournamentresolve_stageupdate_fixture
Add one secure layer between your agents and this server.