Beleeg

Start a tournament bracket (no account needed)

beleeg_start_tournament

Creates a real standalone tournament bracket on Beleeg right away for someone who does not have a Beleeg account yet: the draw is built from the entrants you give. It is never attached to an existing league or organization. It is held for the organizer whose email you give: to take it over they open the claim_url, sign in at beleeg.com with THAT email address (email code, Google or Apple), and choose to keep it. Signing in alone does not make it theirs. Always give the person the claim_url exactly as returned (never build a link from the name) and tell them which email to sign in with. Ask the person for their email; never guess one. If Beleeg refuses, tell the person to sign in to Beleeg with that email and ask again. After signing in, the organizer is asked whether to keep the bracket or discard it; it is theirs only once they keep it. Until then nobody else can see the entrants or the draw: the bracket page only says it is waiting for its organizer. If the organizer has not kept it within 30 days, the bracket is removed. Limits: up to 64 entrants (32 for round robin); 3 per organizer email per day, 5 per caller per day, and at most 3 leagues or brackets waiting on the organizer. Tell the person what you are about to create and get a yes BEFORE calling this; there is no separate confirm step.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Tournament name, plain text.
`bestOf`	No	Sets per match, 1 to 9. Defaults to 3.
`client`	No	Which assistant this is, for example muse, claude, chatgpt, cursor.
`format`	No	Bracket format. Defaults to single_elim.
`entrants`	Yes	Who is playing: a list of names, or text with one entrant per line. For pairs write "Ann Lee / Bo Park". 2 to 64 entrants (2 to 32 for round_robin).
`organizerEmail`	Yes	The organizer's own email address. They sign in with it to run the bracket. Ask for it; never guess.
`registrationUnit`	No	solo (default) or pair (doubles).

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`format`	Yes
`entrants`	Yes
`claim_url`	Yes	Give this to the organizer: it explains how to run the bracket.
`public_url`	Yes	The bracket page. Until the organizer keeps the bracket it only says the tournament is waiting for its organizer; the entrants and the draw show once it is kept.
`tournament_id`	Yes
`organizer_email`	Yes
`claim_instructions`	Yes	Read this to the person.
`unclaimed_expires_on`	No	If the organizer has not signed in and kept the bracket by this date, it is removed.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 6, 2026
RemovedOct 6, 2026
AddedOct 3, 2026
RemovedOct 3, 2026

Changed1 schema field changedSep 30, 2026

changedInput schema / properties / format / enum

Previous value: -[
-  "single_elim",
-  "single_elim_consolation",
-  "three_match_guarantee",
-  "round_robin",
-  "pool_to_bracket"
-]New value: +[
+  "single_elim",
+  "single_elim_consolation",
+  "three_match_guarantee",
+  "double_elim",
+  "round_robin",
+  "pool_to_bracket"
+]

AddedSep 28, 2026
RemovedSep 28, 2026
First observedSep 28, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond annotations, the description discloses important behavior: the bracket is held for the organizer until they claim it, signing in alone is insufficient, nobody else can see entrants until it is kept, and unclaimed brackets are removed after 30 days. It also states concrete limits: up to 64 entrants (32 for round robin), 3 per organizer email per day, 5 per caller per day, and at most 3 waiting leagues or brackets. It does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded: it states the core action first, then the claim process, visibility rules, retention, limits, and pre-call confirmation. Every sentence carries operational information needed to avoid mistakes, and there is no redundant filler. The density is justified by the complexity of the tool.

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

Completeness5/5

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

Given the tool's complexity and the existence of an output schema, the description covers the missing behavioral context thoroughly: accountless creation, claim flow, visibility, retention, rate limits, and confirmation requirements. It does not need to explain return values because an output schema is present. An agent has enough information to invoke the tool correctly and guide the user afterward.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including entrants, format, bestOf, and organizerEmail. The description reinforces a few constraints, such as entrant limits and pair naming, but adds no parameter syntax or meaning beyond what the schema provides. With full schema coverage, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Creates a real standalone tournament bracket on Beleeg.' It immediately distinguishes the tool from a league-creation sibling by stating the bracket 'is never attached to an existing league or organization.' It also clarifies the no-account use case, so an agent can tell what this tool does without opening the schema.

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

Usage Guidelines4/5

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

The description clearly defines the usage context: for someone without a Beleeg account, creating a standalone bracket rather than one attached to a league or organization. It also gives workflow guidance such as asking for the organizer's email, never guessing it, and getting a yes before calling. However, it does not explicitly name an alternative sibling tool such as beleeg_start_league, so it stops short of the full when-to-use-vs-alternative guidance.

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

All Beleeg tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?