AI Ball MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AIBALL_API_BASE | No | Set AIBALL_API_BASE to point the server at another base URL. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_matchesA | Matches for one calendar day: match_id, kick-off time (UTC), league, teams and status. status is |
| get_match_analysisA | For one match: the model's home / draw / away probabilities as recorded before kick-off (fractions that sum to 1), its most likely outcome, a confidence score, the pre-match favourite, and when the read was captured. For a finished match it also returns the final score and whether the most likely outcome happened ( |
| get_open_recordA | How the model's pre-kick-off reads turned out. Without arguments: the whole public record. With |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools target clearly distinct scopes: list_matches discovers matches for a day, get_match_analysis drills into one match's probabilities, and get_open_record reports aggregate performance. There is no functional overlap between them.
All three follow a verb_noun pattern (list_matches, get_match_analysis, get_open_record), which is predictable and readable. The slightly odd term 'open_record' is a minor deviation but the convention itself is consistent.
Three tools is lean but each maps to a distinct need (discovery, per-match detail, aggregate record). It is slightly thin for a data service but nothing feels redundant or missing at the top level.
Core flow — find matches, analyze a match, check the record — is covered, but notable gaps remain: no multi-day or date-range query, no league/team filtering, and no way to look up a specific match directly without a daily listing. These force workarounds for common agent requests.