Provides Danish broadcast hints for Premier League matches on Amazon Prime Video.
Provides Danish broadcast hints for football matches on Viaplay.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@aria-mcp-football when are Denmark, AGF, and Chelsea playing next?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that tells you when your favourite football teams play and where to watch in Denmark. Built for ARIA and shareable with the community.
Data from TheSportsDB.com. No API key required for basic use — the free public dev key (123) is built in.
Source | What | Attribution |
Fixtures, results | Data from TheSportsDB.com |
Danish broadcast information is a best-effort hint built into this server. TheSportsDB does not provide broadcaster data — the hints are researched defaults for the 2025/26 season. Rights change. Always verify at tvsporten.dk or tvbolden.dk.
Related MCP server: OPTA API Documentation MCP Server
npx aria-mcp-footballOr install globally:
npm install -g aria-mcp-football
aria-mcp-footballNo API key required. Optionally set THESPORTSDB_KEY for a premium key.
Requires Node.js 20 or later.
Variable | Required | Description |
| No | TheSportsDB API key. Defaults to |
| No | Comma-separated TheSportsDB team IDs to follow (default: |
| No | JSON object overriding the Danish broadcast hint map (keys: competition name pattern, values: broadcaster string). |
Team | TheSportsDB ID | Competition |
Denmark (national men's) | 133906 | UEFA Nations League, Friendlies, qualifiers |
AGF Aarhus | 133899 | Danish Superliga |
Chelsea | 133610 | Premier League |
Override via FOLLOW_TEAMS=133906,133899,133610 (or any other TheSportsDB team IDs).
get_my_fixturesGet upcoming fixtures for all followed teams within the next N days. This is the primary tool for ARIA's daily check.
Parameters:
Name | Type | Required | Description |
| number | No | Days ahead to look (default 14, max 60). |
Returns:
{
"followedTeams": ["Denmark (id:133906)", "AGF (id:133899)", "Chelsea (id:133610)"],
"daysAhead": 14,
"count": 2,
"fixtures": [
{
"team": "AGF Aarhus",
"opponent": "Viborg",
"homeAway": "home",
"competition": "Danish Superliga",
"kickoffUtc": "2026-06-27T19:00:00.000Z",
"kickoffLocal": "2026-06-27T21:00:00",
"venue": "Ceres Park",
"status": "Not Started",
"danishBroadcast": "TV 2 Play / Viaplay"
}
],
"broadcastNote": "danishBroadcast is a best-effort hint. Rights change — verify at tvsporten.dk / tvbolden.dk."
}get_team_fixturesGet upcoming fixtures or recent results for any football team by name or TheSportsDB team ID.
Parameters:
Name | Type | Required | Description |
| string | Yes | Team name (e.g. |
| number | No | Days ahead to look (default 14, max 60). Ignored when |
| number | No | Return the last N results instead of upcoming fixtures (max 20). |
get_resultsGet recent finished match results with scores for a followed team or all followed teams.
Parameters:
Name | Type | Required | Description |
| string | No | Team name or ID to filter. If omitted, returns results across all followed teams. |
| number | No | Number of recent results (default 5, max 20). |
Returns:
{
"count": 1,
"results": [
{
"team": "Chelsea",
"opponent": "Arsenal",
"homeAway": "home",
"competition": "Premier League",
"kickoffUtc": "2025-08-10T14:00:00.000Z",
"score": "2 - 1",
"outcome": "W"
}
]
}live_nowCheck if any followed team is currently playing. Live scores require a premium TheSportsDB key. On the free key (123) this returns a structured unavailable notice:
{
"status": "unavailable",
"message": "Live-resultater kræver en premium TheSportsDB-nøgle."
}Parameters: None
Competition (substring match) | Danish Broadcaster |
Premier League | Viaplay (1 kamp/uge på Amazon Prime Video) |
Superliga / Superligaen | TV 2 Play / Viaplay |
UEFA Champions League | Viaplay |
Friendlies (national) | TV 2 / TV 2 Play |
UEFA Nations League | TV 2 / TV 2 Play |
World Cup Qualification | TV 2 / TV 2 Play |
Euro Qualification | TV 2 / TV 2 Play |
Anything else | Ukendt — tjek tvsporten.dk / tvbolden.dk |
Override the entire map via BROADCAST_MAP_JSON='{"premier league":"MyTV"}'.
These are best-effort hints. Rights change. Always verify at tvsporten.dk or tvbolden.dk.
Add to your ARIA credentials / MCP config to use with ARIA:
{
"Name": "Football",
"Command": "npx",
"Args": ["-y", "aria-mcp-football"],
"Env": {}
}No key is required. If you have a premium TheSportsDB key you can optionally add:
{
"Name": "Football",
"Command": "npx",
"Args": ["-y", "aria-mcp-football"],
"Env": {
"THESPORTSDB_KEY": "your_premium_key_here"
}
}Note: THESPORTSDB_KEY is not a secret — the default (123) is a public free key. Only use secret: prefix in ARIA if you want to protect a personal premium key.
git clone https://github.com/kimhjort/aria-mcp-football
cd aria-mcp-football
npm install
npm run build
npm testRun the server:
node dist/index.jsMIT — see LICENSE.
Data from TheSportsDB.com.
Get upcoming fixtures (matches) for all followed football teams within the next N days. Default followed teams: Denmark (national), AGF (Danish Superliga), Chelsea (Premier League). Override via FOLLOW_TEAMS env (comma-separated TheSportsDB team IDs). Each fixture includes team, opponent, home/away, competition, kick-off time (UTC and Europe/Copenhagen local), venue, status, and a best-effort Danish broadcaster hint. Sorted by kick-off time ascending. This is the primary tool for ARIA's daily check — call this once to see if any followed team plays soon. Note: danishBroadcast is a best-effort hint; rights change — verify at tvsporten.dk / tvbolden.dk.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days ahead to look for fixtures (default 14, max 60). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully details output fields, sorting, and a caveat about danishBroadcast being best-effort. Lacks info on error handling or permissions, but adequate for a read operation.
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?
Concise at ~100 words, front-loaded with main action, structured logically with no unnecessary sentences.
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 all essential aspects: what, who, configuration, output, sorting, usage tip, caveat. Lacks explicit differentiation from siblings but is sufficient for its simple scope.
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?
With 100% schema coverage, the description adds no extra semantics beyond the schema's parameter definition. Baseline score applies.
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?
Description clearly states verb 'get', resource 'upcoming fixtures', and scope 'for all followed football teams within the next N days'. It lists default teams and distinguishes itself from siblings as the primary daily check tool.
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 indicates this is the primary tool for ARIA's daily check and suggests calling once to see if any team plays soon. Does not explicitly state when to avoid, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent finished match results (with scores) for a followed team or all followed teams. Returns results sorted newest-first with score and win/draw/loss outcome. Useful for checking how a team did in their last few matches.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | Team name or numeric TheSportsDB team ID to filter results. If omitted, returns recent results across all followed teams. | |
| last | No | Number of recent results to return (default 5, max 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states results are sorted newest-first with score and outcome but does not disclose error handling, authentication requirements (implied by 'followed teams'), or potential behaviors like empty results.
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 sentences with no redundant information. The core functionality and sorting order are front-loaded. Every sentence adds value.
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 no output schema, the description adequately covers return values (scores, outcomes, sorting). It misses details on error responses but is sufficient for a simple result-fetching tool.
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% with parameter descriptions. The description adds value by clarifying the team parameter's behavior when omitted (returns all followed teams), but adds little beyond the schema for the 'last' parameter.
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?
The description clearly states the tool retrieves recent finished match results with scores and outcomes, specifying it returns results for a followed team or all followed teams. It distinguishes from sibling tools like get_my_fixtures and live_now.
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?
The description implies use for checking recent results but lacks explicit when-not-to-use guidance or comparisons to alternatives. The sibling names provide context, but the description itself does not offer exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get upcoming fixtures or recent results for any football team, by name or TheSportsDB team ID. When 'last' is provided, returns the last N finished matches instead of a date range. Returns fixture entries (kickoff, competition, venue, status, broadcast hint) or result entries (score, outcome) if last is set. Note: danishBroadcast is a best-effort hint; rights change — verify at tvsporten.dk / tvbolden.dk.
| Name | Required | Description | Default |
|---|---|---|---|
| team | Yes | Team name (e.g. 'Chelsea', 'AGF', 'Denmark') or numeric TheSportsDB team ID. Name search is performed if a non-numeric string is provided. | |
| days | No | Number of days ahead to look for fixtures (default 14, max 60). Ignored when 'last' is set. | |
| last | No | Return the last N results instead of upcoming fixtures (max 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the output structure (fixture entries vs result entries) and notes that 'danishBroadcast' is best-effort, with verification links. Could mention rate limits or error handling, but overall informative for a read tool.
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 core parameters. The final note on broadcast verification is useful context but slightly lengthens the description. Generally efficient with no redundancy.
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 no output schema, the description adequately explains return types (fixture vs result entries). Covers behavior of all parameters and provides verification guidance. Lacks error handling or edge case info, but sufficient for typical use.
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% with parameter descriptions. Description adds value by explaining the interaction between 'days' and 'last' (ignored when last is set) and describing the output format, which goes beyond schema definitions.
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?
Clearly states it gets upcoming fixtures or recent results for a football team by name or ID. Differentiates from siblings like get_my_fixtures (user-specific) and live_now (current live) by its team-specific focus and date/result modes.
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?
Provides explicit guidance on using the 'last' parameter to switch from fixtures to results. Does not directly compare to sibling tools or state when not to use, but the description's clarity on functionality implicitly guides appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if any followed football team is currently playing. Live scores require a premium TheSportsDB key — on the free key this returns a structured unavailable notice. Returns live match entries with current score on premium tier, or { status: 'unavailable', message: '...' } on free tier. Note: danishBroadcast is a best-effort hint; rights change — verify at tvsporten.dk / tvbolden.dk.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses premium vs free tier behavior (structured unavailable notice), and notes that danishBroadcast is a best-effort hint. No annotations exist, so description fully covers behavioral traits.
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 concise sentences plus a helpful note, front-loaded with core action. No wasted words.
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?
Explains return values for both premium and free tiers, despite no output schema. Covers behavioral caveat about danishBroadcast. Complete for a zero-parameter tool.
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?
No parameters in schema, description does not need to add parameter info. Baseline of 4 applies as it adds meaning about the tool's function beyond the empty 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?
Description clearly states it checks if any followed football team is currently playing, with a specific verb and resource. It distinguishes from sibling tools like get_my_fixtures (fixtures) and get_results (results) by focusing on live status.
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?
Describes when to use (current live status) but does not explicitly exclude alternatives. Provides context on premium vs free key limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct: get_my_fixtures for upcoming followed teams, get_results for past followed teams, get_team_fixtures for any team (upcoming or past), live_now for current matches. However, get_team_fixtures with 'last' can overlap with get_results for followed teams, causing potential confusion.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_my_fixtures, live_now). No mix of styles or abbreviations, ensuring predictability.
4 tools are well-suited for the football match info domain. Each tool serves a distinct purpose (upcoming, past, live, generic team query), without being too few or excessive.
The tool set covers the core match lifecycle (upcoming, results, live) for both followed and general teams. Missing are tools for managing followed teams (env variable only) and broader football data like standings or player info, but these are beyond the stated scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
API-Football MCP — comprehensive soccer/football data
TheSportsDB MCP — sports catalog (teams, players, events)
Sports MCP — wraps TheSportsDB API (free tier, test key 3, no auth required)
Historical football results, teams, competitions and draw/streak statistics via 10 read-only tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kimhjort/aria-mcp-football'
If you have feedback or need assistance with the MCP directory API, please join our Discord server