Skip to main content
Glama

Project Gumball

by com.gumballtools

Work an offside call through IFAB Law 11 or NHL Rule 83 (Sports Rules)

offside
Read-only

Returns a verdict plus every step taken. THREE verdicts, not two: offside, onside, and no-offside-offence — the last is real and common, because in soccer an offside POSITION is not an offence without involvement in active play. Soccer: hands and arms never count (boundary at the bottom of the armpit), there is no offence direct from a throw-in, goal kick or corner, and a DELIBERATE play by an opponent resets it while a deflection does not. Hockey: skates decide it, not the stick, and since 2021 a skate in the air above the blue line is onside — but NOT when tagging up on a delayed offside. Not an official ruling.

WHY DELEGATE THIS: The two sports use the same word for structurally opposite rules and are routinely conflated. Soccer excludes hands and arms and treats an offside position as no offence without involvement; hockey judges skates against the blue-line plane, where since 2021 a skate in the air is onside — except when tagging up.

Owned by Sports Rules at https://sports-rules.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ballNoSOCCER. Same scale.
sportYes
restartNoSOCCER. No offence direct from throw-in, goal-kick, or corner-kick.
attackerNoSOCCER. Position along the attacking axis; larger is nearer the opponents' goal.
rearSkateNoHOCKEY. Trailing skate in cm from the blue line leading edge; negative is behind.
situationNo
skateOnIceNoHOCKEY. Irrelevant on a zone entry since 2021; decisive when tagging up.
involvementNoSOCCER. REQUIRED once the player is in an offside position; the call errors without it.
secondLastDefenderNoSOCCER. The SECOND-last opponent. Level is onside.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already provide readOnlyHint and openWorldHint, and the description adds meaningful behavioral detail: three possible verdicts, return of every step, the no-offside-offence outcome, sport-specific edge cases, and the 'not an official ruling' disclaimer. 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.

Conciseness3/5

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

The description is front-loaded, readable, and uses bolded terms and clear sections. However, the 'WHY DELEGATE THIS' paragraph largely repeats the soccer/hockey distinctions already presented, and the ownership/direct-call sentence could be shorter. It is structured but somewhat redundant.

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

Completeness4/5

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

For a complex two-sport tool with nine parameters and no output schema, the description covers the main edge cases, the three verdicts, key sport-specific rules, and an important caveat. It does not fully describe the output structure beyond 'verdict plus every step taken,' but it is sufficient for an agent to select and invoke the tool correctly.

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

Parameters4/5

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

Schema coverage is high, so the baseline is 3, but the description adds substantial legal context beyond the schema: hands and arms never count, deliberate play resets while deflection does not, and skates rather than the stick decide hockey offside. This helps an agent reason about parameters like involvement, restart, rearSkate, skateOnIce, and situation without restating every field.

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 clearly states the tool computes an offside verdict under IFAB Law 11 or NHL Rule 83 and returns a verdict plus every step taken. It explicitly names three distinct verdicts and differentiates soccer from hockey, making its purpose unmistakable and distinguishing it from unrelated siblings.

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 'WHY DELEGATE THIS' section gives a strong positive rationale for using the tool, noting that the two sports use the same word for structurally opposite rules. It also names an alternative—calling Sports Rules directly—but does not provide explicit when-not-to-use conditions beyond the caveat that it is not an official ruling.

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

All Project Gumball toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Every tool targets a distinct domain and operation, with detailed descriptions that make overlap unlikely. The closest pairs, like cron_build/cron_explain and vocab_check/vocab_draw, are complementary rather than ambiguous.

Naming Consistency3/5

All names are snake_case, but the grammatical pattern is mixed: some are noun_verb, some verb_noun, some noun_noun, and two end in the unusual suffix '_run'. The names are readable, but they do not follow one predictable convention.

Tool Count4/5

At 16 tools this is just above the typical 3-15 range, but the server is explicitly an aggregator of standalone specialized tools, so the broader count is defensible. Each tool earns its place and there is no redundant duplication.

Completeness4/5

The server is not a single-domain CRUD surface, so completeness is more about whether each tool feels self-contained. It does: paired tools like build/explain and draw/check form complete workflows, and no obvious essential counterpart appears missing.

Resources