Beleeg (public, no account)

Start a league (no account needed)

beleeg_start_league

Creates a real league on Beleeg right away for someone who does not have a Beleeg account yet: the league, its first season with registration open, optional teams, and a public page. 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 league or discard it; it is theirs only once they keep it. Invited people are saved but not emailed until the organizer has kept the league and sends them. If the organizer has not kept it within 30 days, the league is removed. Limits: 3 per organizer email per day, 5 per caller per day, and at most 3 leagues or brackets waiting on the organizer. Team names that differ only by capitals or spacing are treated as one team. 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
`city`	No	Town or city, shown on the public page.
`name`	Yes	League name, plain text, for example "Tuesday Night Pickleball".
`sport`	Yes	Sport key, for example pickleball, platform-tennis, tennis, softball, volleyball.
`teams`	No	Team names to create right away (up to 64).
`client`	No	Which assistant this is, for example muse, claude, chatgpt, cursor.
`timezone`	Yes	IANA time zone the league plays in, for example America/Chicago.
`inviteEmails`	No	People to invite (up to 200). They are only SAVED as pending invites: no email goes out until the organizer has signed in, kept the league, and sends them.
`organizerEmail`	Yes	The organizer's own email address. They sign in with it to take over the league. Ask for it; never guess.
`organizationName`	No	Club or group name. Defaults to the league name.
`registrationClosesOn`	No	Last day to register, YYYY-MM-DD. Defaults to 30 days from today.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`slug`	Yes
`teams`	Yes
`claim_url`	Yes	Give this to the organizer: it explains how to take over the league.
`league_id`	Yes
`public_url`	Yes	The public league page. Works right away, and says the league is waiting for its organizer until it is kept. Use it exactly as returned: while the league waits its address ends in a few extra characters. Once kept it moves to the short address if that is free, and this one keeps working.
`invites_pending`	Yes	Invites saved but NOT sent.
`organization_id`	Yes
`organizer_email`	Yes
`claim_instructions`	Yes	Read this to the person.
`unclaimed_expires_on`	Yes	If the organizer has not signed in and kept the league by this date, it is removed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly=false, openWorld=false, idempotent=false, destructive=false). The description adds substantial behavioral context the annotations cannot convey: the claim_url/is-it-theirs ownership flow, that sign-in alone does not transfer ownership, that invites stay unsent until the organizer keeps the league, the 30-day removal, and concrete rate limits (3/organizer/day, 5/caller/day, 3 pending).

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

Conciseness4/5

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

Front-loaded with purpose and claim mechanics, and almost every sentence carries operational value (claim_url handling, limits, dedup rule, confirmation requirement). Slight redundancy: ownership is restated ('Signing in alone does not make it theirs' vs 'it is theirs only once they keep it'), and the keep/discard flow is mentioned twice.

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 an output schema exists, return-value detail is not required, and the description still covers the full operational picture: creation side effects, ownership/claim flow, invite deferral, expiry, rate limits, and the mandatory confirmation step. 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.

Parameters3/5

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

Schema description coverage is 100%, so all ten parameters are already documented in the schema, setting the baseline at 3. The description reinforces a few constraints (organizer email must be asked for and never guessed, team-name capitalization/spacing normalization) but adds little parameter detail beyond what the schema already states.

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 real league on Beleeg right away') with a clear scope qualifier: for someone without a Beleeg account. This cleanly separates it from the sibling prepare_create_league / prepare_* family, which only stage actions.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ('someone who does not have a Beleeg account yet'), prerequisites (ask for the email, never guess), and a required pre-call step ('Tell the person what you are about to create and get a yes BEFORE calling this; there is no separate confirm step'), plus fallback behavior when Beleeg refuses.

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?