Beleeg (public, no account)

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.

First observedSep 28, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only say non-readonly, non-idempotent, non-destructive. The description adds substantial behavior beyond that: the claim_url handoff, the organizer-keep-or-discard flow, the waiting-for-organizer visibility state, 30-day removal, daily creation limits, and the concurrent-pending cap. This is exactly the extra 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.

Conciseness3/5

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

Purpose is front-loaded in the first sentence, but the claim flow is reiterated several times ('to take it over they open the claim_url', 'Signing in alone does not make it theirs', 'asked whether to keep... theirs only once they keep it'), which is repetitive. Much of the operational instruction earns its place; the redundancy does not.

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?

For a bracket-creation tool with a non-trivial claim/expiry lifecycle, the description covers limits, expiry, visibility, prerequisites, and failure handling, and an output schema exists so return values need no explanation. Nothing essential is missing.

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 every parameter including organizerEmail, entrants, format, and bestOf is already documented, and the description's mentions of email/entrants largely restate the schema's own 'ask for it; never guess' note. Baseline 3 is appropriate 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.

Purpose5/5

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

States a specific verb and resource (creates a standalone tournament bracket) and immediately narrows the scope: 'never attached to an existing league or organization.' This distinguishes it from league/tournament creation siblings without the agent opening either 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?

Gives clear triggering context ('for someone who does not have a Beleeg account yet'), prerequisites (ask for email, get a yes before calling, no separate confirm step), and a fallback path if Beleeg refuses. It does not explicitly name a sibling tool to prefer for the account-holder case, so routing is implied rather than stated.

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

All Beleeg (public, no account) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?