Skip to main content
Glama

AI Ball — AI football match analysis

Get the open record

get_open_record
Read-onlyIdempotent

Hits out of matches for the public record, the pre-match favourite and random baselines on the same matches, results by confidence band, and snapshot coverage. Without week_start it covers the whole record; with it, that week only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tzNoIANA time zone used to decide which calendar day a match falls on.Asia/Kuala_Lumpur
langNoLanguage of team and league names.en
week_startNoYYYY-MM-DD, the Monday of the week. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety behavior is covered. The description adds useful scoping behavior: without week_start it covers the whole record, with it just that week, and it lists the aggregate dimensions returned (baselines, confidence bands, snapshot coverage).

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?

The description is two sentences and avoids unnecessary repetition. The first sentence lists outputs, but the phrasing 'Hits out of matches for...' is a bit dense and not immediately front-loaded with the core action, making it slightly less clear than ideal.

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?

Given no output schema and full parameter descriptions in the schema, the description adequately explains what data is returned and how the optional week_start parameter affects scope. It does not describe pagination or output format details, but for an aggregate summary tool this is largely sufficient.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the effect of week_start: it scopes results to a single week instead of the whole record, which is not stated in the schema field description.

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

Purpose4/5

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

The description states the specific outputs: hit counts for the public record, pre-match favourite, and random baselines, results by confidence band, and snapshot coverage. It clearly identifies the resource as the 'open record' and what it contains, though it does not explicitly differentiate itself from sibling tools by name.

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

Usage Guidelines3/5

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

The description mentions that omitting week_start covers the whole record and including it restricts to that week, which gives implied usage. However, it does not state when to prefer this tool over alternatives like get_match_analysis or list_matches, nor does it provide any exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.