How do I use fotmob-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fotmob-mcp list upcoming matches for Manchester City" 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.

fotmob-mcp

by ccdejene

Overview Schema Related Servers Score Discussions

Python

Remote

FotMob MCP

Model Context Protocol server for live FotMob football data.

Python 3.11+ MCP ready Transports

FotMob MCP exposes a small set of MCP tools and resources for working with football data from FotMob. It is intended for agents and local tooling that need fixture lookup, league pages, team/player data, match details, live fixture polling, and league stats.

Features

Verified FotMob route catalog
Search suggestions for teams, players, leagues, and matches
Direct fetch tool for supported FotMob JSON routes
Helpers for live match details, live fixtures, and league top stats
MCP resources for route reference and reusable prompt context
Optional local response cache
stdio, sse, and streamable-http transports

Related MCP server: api-football-mcp-server

Installation

From the repository root:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt

requirements.txt installs the runtime dependencies and this package in editable mode.

Verify that the console script is available:

command -v fotmob-mcp
fotmob-mcp --help

Usage

Run the server with the default stdio transport:

fotmob-mcp

Run with streamable HTTP:

fotmob-mcp --transport streamable-http --host 127.0.0.1 --port 8000

Default streamable HTTP endpoint:

http://127.0.0.1:8000/mcp

Client Configuration

Codex

codex mcp add fotmob -- fotmob-mcp

Hermes Agent

Install the package in the runtime environment used by Hermes, then add the MCP server entry:

{
  "mcpServers": {
    "fotmob": {
      "command": "fotmob-mcp",
      "args": []
    }
  }
}

Verify that Hermes can resolve the command from the same environment:

command -v fotmob-mcp

Tools

Tool	Description
`list_fotmob_routes`	List supported routes, optionally filtered by keyword.
`fetch_fotmob_route`	Fetch a supported route by route key and JSON parameters. Fresh by default.
`search_fotmob`	Query FotMob search suggestions.
`get_match_details`	Fetch match details from a FotMob match id or URL. Fresh by default.
`get_match_liveticker`	Fetch match live ticker/commentary events from a match id or URL. Fresh by default.
`get_live_fixtures`	Fetch live fixtures from a league payload's poll link.
`get_league_top_stats`	Fetch league player or team stats and resolve internal season ids when possible.

Resources

Resource	Description
`fotmob://reference`	Markdown reference for the supported FotMob API routes.
`fotmob://routes`	Route catalog generated by the server.
`fotmob://prompt`	Reusable prompt context for agents.

Supported Routes

Key	Endpoint
`search_suggest`	`/api/data/search/suggest`
`all_leagues`	`/api/data/allLeagues`
`matches`	`/api/data/matches`
`leagues`	`/api/data/leagues`
`leagues_shotmap`	`/api/data/leagues?shotmap=true`
`league_season_deep_stats`	`/api/data/leagueseasondeepstats`
`teams`	`/api/data/teams`
`player_data`	`/api/data/playerData`
`player_matches`	`/api/data/playerMatches`
`match_details`	`/api/data/matchDetails`
`match_liveticker`	`/api/data/ltc`
`match_heatmaps`	`/api/data/heatmap/match/{matchId}/heatmaps`
`transfers`	`/api/data/transfers`
`tvlistings`	`/api/data/tvlistings`
`audio_matches`	`/api/data/audio-matches`
`dataproviders`	`/api/data/dataproviders`

Use list_fotmob_routes to inspect parameters and notes for each route.

For match pages, prefer get_match_details when you have a FotMob URL:

get_match_details("https://www.fotmob.com/en-GB/matches/japan-vs-brazil/1uqadm#4653711")

For match commentary/live ticker events, use the same URL or match id:

get_match_liveticker("https://www.fotmob.com/en-GB/matches/japan-vs-brazil/1uqadm#4653711")

The match page slug can vary; the helper extracts the match id from the URL fragment. If FotMob has no live ticker file for a match, the tool returns status: unavailable with an empty events array.

All MCP tools fetch fresh FotMob data by default, including search, league, team, player, match, fixture, heatmap, transfer, TV, audio, and provider routes. fetch_fotmob_route and get_match_details still expose use_cache=true for explicit opt-in caching.

Configuration

Optional environment variables:

Variable	Description
`FOTMOB_BASE_URL`	Override the default FotMob base URL.
`FOTMOB_CACHE_DIR`	Change the local cache directory for explicit cache use.
`FOTMOB_CACHE_TTL_SECONDS`	Change cache lifetime in seconds for explicit cache use.
`FOTMOB_MCP_TRANSPORT`	Default transport: `stdio`, `sse`, or `streamable-http`.
`FOTMOB_MCP_HOST`	HTTP bind host.
`FOTMOB_MCP_PORT`	HTTP bind port.
`FOTMOB_MCP_SSE_PATH`	SSE endpoint path.
`FOTMOB_MCP_STREAMABLE_HTTP_PATH`	Streamable HTTP endpoint path.

Development

Run tests:

python -m unittest

Available Tools

7 tools

fetch_fotmob_routeC

Fetch one of the verified FotMob JSON routes through the shared FotMob client.

ParametersJSON Schema

Name	Required	Default
`route_key`	Yes
`use_cache`	No
`params_json`	No	{}

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided; description does not disclose behavioral traits like read-only, caching behavior, or authentication needs.

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?

Single sentence is concise but lacks necessary detail. Every word earns its place in stating purpose, but overall structure is too minimal.

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

Completeness2/5

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

Despite having an output schema, the description fails to explain how to use the tool, including parameter behavior and expected input. Incomplete for a 3-parameter tool with no param descriptions.

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

Parameters2/5

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

Schema description coverage is 0%, and description adds no meaning to parameters. Does not clarify what 'route_key' represents or the format of 'params_json'.

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

Purpose3/5

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

Description states it fetches a FotMob JSON route, but 'route' is vague and not differentiated from sibling tools like get_match_details. Purpose is clear in verb but ambiguous in resource.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus specific sibling tools. Does not mention prerequisites or context.

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

get_league_top_statsB

Fetch top league player/team stats and resolve FotMob internal season ids automatically.

ParametersJSON Schema

Name	Required	Default
`stat`	No	goals
`limit`	No
`season`	Yes
`team_id`	No
`league_id`	Yes
`stat_type`	No	players

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior3/5

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

No annotations provided, so description carries burden. Mentions automatic season ID resolution as a behavioral trait, but lacks details on side effects, permissions, or limitations. Adequate for a read tool but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Single sentence, 15 words, front-loaded with main action. No redundancy or filler. Every word earns its place.

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

Completeness2/5

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

Despite having an output schema, the description omits parameter details and usage context for a 6-parameter tool. Lacks explanation of stat_type, limit, or team_id. Insufficient for an agent to invoke correctly without external knowledge.

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

Parameters2/5

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

Input schema has 6 parameters with 0% description coverage. Description only hints at 'season' via ID resolution, failing to explain other parameters like stat, limit, team_id, stat_type, or league_id. Schema has defaults but no semantic context.

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?

Description clearly states 'Fetch top league player/team stats', specifying action (fetch) and resource (league stats). Mention of automatic season ID resolution adds unique functionality, distinguishing it from sibling tools like get_match_details or search_fotmob.

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

Usage Guidelines2/5

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

No guidance on when to use this tool over alternatives. Absence of conditions, prerequisites, or exclusions leaves the agent without direction for selection among siblings.

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

get_live_fixturesC

Fetch live league fixtures from the league payload's live fixture poll link.

ParametersJSON Schema

Name	Required	Default
`ccode3`	No	INT
`season`	Yes
`league_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning authentication, rate limits, data freshness, or whether the operation is read-only. The bare minimum is covered.

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 a single sentence, which is concise but lacks depth. It is front-loaded with the core action, but no additional structure or elaboration is provided to aid understanding.

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

Completeness2/5

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

Despite having an output schema, the description fails to explain what 'live league fixtures' entails or how parameters relate to the fetch. For a tool with 3 parameters and no schema descriptions, the description is insufficiently complete.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to the parameters (league_id, season, ccode3). It only references the source (live fixture poll link) without explaining how parameters are used or what valid values are.

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 clearly states it fetches live league fixtures, specifying the source as the league payload's live fixture poll link. This distinguishes it from sibling tools like get_match_details or get_match_liveticker, but the technical phrasing slightly reduces clarity.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives like search_fotmob or list_fotmob_routes. The description does not mention prerequisites or exclusions, leaving the agent without context for selection.

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

get_match_detailsB

Fetch FotMob match details from a match id or FotMob match URL. Fresh data is fetched by default.

ParametersJSON Schema

Name	Required	Description	Default
`use_cache`	No
`match_id_or_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior3/5

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

The description mentions that 'Fresh data is fetched by default,' which implies a caching mechanism and the use_cache parameter. However, it does not disclose other behavioral aspects such as error handling, rate limits, or whether the tool is read-only. Without annotations, the description carries the burden but only partially fulfills it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is only two sentences, with the first sentence conveying the core purpose and the second adding a key behavioral detail. Every word serves a purpose, and the structure is front-loaded for quick scanning. No unnecessary text.

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

Completeness3/5

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

Given the tool has 2 parameters and an output schema, the description is fairly complete in stating its purpose and caching behavior. However, it lacks usage guidance and detailed parameter descriptions. The output schema exists, so return values need not be explained, but the description could still mention the type of details returned. Sibling tools suggest overlap, so more context would help.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It explains that match_id_or_url can be a match ID or URL, adding meaning beyond the schema. However, it does not clarify the expected format (e.g., numeric ID vs. full URL). The use_cache parameter is implied but not explicitly described. This partially addresses the gap but is not exhaustive.

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 clearly states the verb 'Fetch' and the resource 'FotMob match details' and specifies input via match id or URL. It distinguishes from siblings like get_match_liveticker by focusing on general details, but does not explicitly contrast with other similar tools.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its siblings (e.g., get_match_liveticker, get_league_top_stats). It lacks any context about prerequisites, typical use cases, or conditions where alternatives are preferred.

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

get_match_livetickerA

Fetch FotMob live ticker/commentary events from a match id or FotMob match URL. Fresh data is fetched by default.

ParametersJSON Schema

Name	Required	Default
`lang`	No	en
`use_cache`	No
`match_id_or_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Mentions 'Fresh data is fetched by default' which hints at caching, but lacks details on authentication, rate limits, or error states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two concise sentences with no fluff, front-loading the core purpose.

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

Completeness3/5

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

While an output schema exists, the description lacks prerequisites or context for when the tool should be invoked. Adequate for a simple read tool but could be more complete.

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

Parameters2/5

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

Schema coverage is 0%, so description must compensate. Only partially explains match_id_or_url and hints at use_cache, but ignores lang. Incomplete coverage for 3 parameters.

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 it fetches live ticker/commentary events using a match id or URL, distinguishing it from sibling tools like get_match_details.

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?

No explicit guidance on when to use this tool versus alternatives like get_match_details or search_fotmob. Usage is implied but not clarified.

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

list_fotmob_routesB

List the verified FotMob route inventory, optionally filtered by a keyword.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It only states the core functionality without mentioning behavioral traits such as read-only nature, authorization requirements, rate limits, or response structure. The tool name suggests safety, but this is not confirmed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single concise sentence with no extraneous information. It is well-structured and front-loaded, efficiently conveying the tool's purpose.

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 the tool's simplicity (one optional parameter, no required fields, and presence of an output schema), the description adequately covers the core functionality. It omits details like pagination or filtering specifics, but these are not critical for a basic list endpoint.

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

Parameters3/5

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

Schema description coverage is 0%, but the description explains the 'query' parameter as an optional keyword filter. This adds meaning beyond the minimal schema. However, it does not detail filter behavior or valid patterns, leaving room for ambiguity.

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 clearly states the tool lists verified FotMob routes with an optional keyword filter. It effectively implies a listing operation, distinguishing from the sibling 'fetch_fotmob_route' which likely retrieves a specific route. However, explicit differentiation is absent.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'fetch_fotmob_route'. The description only implies usage for listing, but lacks explicit context about when not to use it or what alternatives exist.

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

search_fotmobC

Fetch FotMob search suggestions for a term.

ParametersJSON Schema

Name	Required	Default
`hits`	No
`lang`	No	en
`term`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states the basic function without mentioning expected behavior like read-only nature, rate limits, or result characteristics.

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 a single concise sentence that immediately conveys the main purpose. However, it may be too brief given the lack of other documentation.

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

Completeness2/5

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

Despite having an output schema, the description fails to explain what kind of suggestions are returned or any details about the three parameters. It is insufficient for a search tool.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning beyond the parameter names and defaults. It does not explain 'hits' or 'lang', leaving the agent uninformed.

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 fetches FotMob search suggestions for a term, which is specific and distinguishes it from siblings like get_match_details or get_live_fixtures.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or context for usage. Siblings exist but are not referenced.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 7, 2026
- First observedfetch_fotmob_route
- First observedget_league_top_stats
- First observedget_live_fixtures
- First observedget_match_details
- First observedget_match_liveticker
- First observedlist_fotmob_routes
- First observedsearch_fotmob

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool targets a distinct data source or action: fetching specific routes, league stats, live fixtures, match details, liveticker, listing routes, and searching. No two tools have overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_match_details, list_fotmob_routes). The naming is predictable and easy to understand.

Tool Count5/5

Seven tools is well-scoped for a sports data API, covering common queries without being excessive. Each tool serves a clear need.

Completeness4/5

The tool set covers search, live data, match details, and league stats. The generic fetch_fotmob_route allows access to any API endpoint, compensating for missing specific tools like team info or league tables.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

CualBet MCP
com.cualbet
Football fixtures, standings, and odds intelligence for AI agents.
Sports Search Finance
2
Api Football
io.github.pipeworx-io
API-Football MCP — comprehensive soccer/football data
Sports Research & Data
2
Football Database and Results
io.fdb4
Historical football results, teams, competitions and draw/streak statistics via 10 read-only tools.
Sports Open Data
1
StatsHawkOAuth
ai.statshawk
Live sports stats and pre-computed analysis for AI assistants across NBA, MLB, NFL, and NHL.
Sports Research & Data
2

Related MCP Servers

FotMoCP
Sports Web Scraping Search
Margeshy
A
license
A
quality
C
maintenance
Enables MCP clients to access live football data from FotMob, including match stats, team form, injuries, and player workload, without making predictions.
Updated 2 months ago (2026-07-15 21:55 UTC)
10
1
MIT
api-football-mcp-server
Sports Search
dankniight
F
license
Not graded
quality
D
maintenance
Enables natural language querying of football/soccer data via the API-Football service, providing access to leagues, teams, players, fixtures, standings, and statistics.
Updated a year ago (2025-09-15 15:57 UTC)
3
-
matchday-mcp
Sports Search
mgphp
A
license
Not graded
quality
C
maintenance
Enables fetching football fixtures, match details, league tables, and squad information from the matchday app through natural language.
Updated a month ago (2026-07-22 16:16 UTC)
14
MIT
API-Football MCP Server
Sports Search
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides comprehensive soccer/football data including standings, team search, league search, match predictions, and head-to-head records via the API-Football service.
Updated 11 days ago (2026-08-26 16:33 UTC)
20
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ccdejene/fotmob-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server