Beleeg (public, no account)

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

Annotations already declare readOnly, idempotent, non-destructive, and non-open-world, so safety is covered. The description adds one genuinely useful trait beyond them: no authentication is required. It says nothing about rate limits, missing/case-sensitive slugs, or error behavior, keeping it short of a 5.

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 action and scope, then access condition, then example. The parenthetical enumeration of payload fields is slightly redundant given an output schema exists, but overall there is little 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?

With annotations covering the safety profile, a 100%-covered single parameter, and an output schema, the description only needs to convey purpose, access mode, and input shape, which it does. It could be stronger by noting that the slug must already exist or by contrasting with the authenticated league-lookup siblings.

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, and the schema already documents it at 100% coverage ('Public URL-safe league slug'), so the baseline is 3. The inline example ('ftw-volleyball-spring-2026') usefully conveys the expected slug format, adding real meaning 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 (look up), resource (league), and access path (public slug), plus the exact payload returned (name, sport, current season, teams, standings). The word 'public' and the payload scope distinguish it from authenticated league tools like beleeg_get_league_brief and from the narrower beleeg_get_standings.

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?

'Works without authentication' tells the agent the operating context in which this tool is the right pick (unauthenticated/public access), and the concrete slug example shows required input. It does not, however, explicitly state when to prefer this over sibling tools such as get_league_brief or list_league_teams.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description adds a genuine behavioral fact beyond them: 'Works without authentication,' which tells the agent it can call this unauthenticated. It does not cover rate limits or error behavior, so it is not a 5.

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 tightly written sentences: the payload scope comes first, then the auth and sourcing notes. No filler, no redundancy with schema or annotations.

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 covering return values, annotations covering safety, and a fully described single parameter, the description supplies exactly the remaining context an agent needs: read scope, auth requirement, and where to obtain the ID.

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% for the single match_id parameter, so the baseline is 3. The description goes further by framing the expected value as a public/schedule match ID obtainable from a get_league_brief row, adding provenance the schema does not.

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 ('look up') and resource ('fan-facing payload for a single match by ID') and enumerates the returned content (teams, lineups, set scores, venue, broadcast). This clearly separates it from siblings like beleeg_get_schedule or beleeg_get_public_league.

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?

Adds a concrete usage hint: 'pass match_id from a schedule row in get_league_brief', naming the sibling that produces the identifier. It also notes the tool works without authentication, but gives no explicit when-not or alternative-selection guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine extra context the annotations do not: that no authentication is required and that only the fan-facing/public subset of team data is exposed, which tells the agent about visibility scope.

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 return scope, followed by the auth note and example. Efficient overall, though the inline example partially duplicates the schema example and could be trimmed.

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 single-parameter read tool with an output schema, annotations and schema are rich, and the description covers auth and visibility scope. The return-field enumeration is mildly redundant given the output schema exists, but nothing an agent needs to call 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 single slug parameter is fully documented in the schema. The description's example (slug="hawks-2026") mirrors the schema's own example, so it adds essentially no meaning beyond the structured field.

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 (look up) and resource (team by public slug) and even enumerates the returned summary fields (name, league, roster, captain, color, recent matches). It implicitly separates itself from authed team tools via 'public'/'fan-facing', but never names a sibling such as beleeg_find_team, so it falls just short of full differentiation.

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 situational context: this is the unauthenticated lookup path, reinforced by a concrete example call. It does not state when to prefer this over beleeg_find_team or other team tools, and offers no exclusions.

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

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

Annotations already declare readOnly/idempotent/destructive=false, so the safety profile is covered. The description adds genuinely new behavior: public unauthenticated access and the rule that multi-draw events keep separate brackets rather than one here. Does not cover return shape or pagination, but an output schema exists.

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 what the tool returns, then access rules, then the multi-draw caveat and ID sourcing. Efficient overall, though the rhetorical 'who is in this tournament and who plays who?' sentence is mildly redundant with the opening clause.

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?

Covers access, the key edge case (multi-draw events), and ID provenance, and the output schema handles return values. Nearly complete for a single-resource read; only minor details like result size/pagination are absent, which is low-stakes for a one-tournament lookup.

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% for the single tournament_id, so the baseline is 3. The description adds value beyond the schema by telling the agent where valid IDs come from (beleeg_list_public_tournaments_by_league or a league brief), which the schema's bare 'Tournament ID.' does not.

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 plus the payload contents: status, entrant list, and the single-bracket case. It also explicitly distinguishes itself from beleeg_list_tournament_draws for multi-draw events, so an agent can tell the two apart without 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.

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

Explicitly says anyone may call it, signed in or not, and names the alternative path (beleeg_list_tournament_draws, one read per draw) for events split into parallel draws. It even names where to source the tournament_id. No inference required.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds genuinely new behavioral context: it works for unauthenticated callers and is filtered to the public view only, unlike the member-facing alternative. A small gap remains (no pagination or result-limit info), but the added value is real.

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 differentiator (slug instead of id, public-only), and every sentence carries information. It is a touch verbose at four sentences, but none are 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?

For a single-param, read-only list tool with an output schema present, the description covers access rules, scope, the alternative tool, and an example. Nothing an agent needs to call 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 coverage is 100% and the schema already says 'Public league slug (not UUID)'. The description reinforces this ('found by the league's web address (its slug) instead of its id') and supplies a concrete example, which meaningfully helps formatting even against a well-documented 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 (list), resource (public tournaments), and scope (by league slug), and explicitly contrasts with beleeg_list_tournaments. An agent can distinguish this from its closest sibling without opening any 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?

Explicitly says when to use it (anonymous/spectator/public pages, when only a link/slug is available) and when not to (use beleeg_list_tournaments when you have league_id and membership, since it includes finished/archived events). This is textbook routing guidance.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.