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., "@ProCyclingStats MCP Server Show me the startlist for the 2025 Tour de France"
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.
An MCP (Model Context Protocol) server that provides professional cycling data from ProCyclingStats.
Tool | Description |
| Find races from the PCS calendar for a given year and tier |
| Get race metadata — name, dates, category, stages list |
| Get full stage/one-day race results with metadata |
| Get rider bio, physical stats, specialty scores, palmares |
| Get the startlist for a race grouped by team |
| Free-text search for riders, races, and teams |
Related MCP server: Chess.com MCP Server
pip install git+https://github.com/lewis-mcgillion/procyclingstats-mcp-server.gitOr clone and install locally:
git clone https://github.com/lewis-mcgillion/procyclingstats-mcp-server.git
cd procyclingstats-mcp-server
pip install -e .procyclingstats-mcpAdd to your MCP client config (e.g. Claude Desktop, VS Code GitHub Copilot).
Recommended — using uvx (no manual install needed):
{
"mcpServers": {
"procyclingstats": {
"command": "uvx",
"args": ["--from", "git+https://github.com/lewis-mcgillion/procyclingstats-mcp-server.git", "procyclingstats-mcp"]
}
}
}Using a local clone with uv:
{
"mcpServers": {
"procyclingstats": {
"command": "uv",
"args": ["run", "--directory", "/path/to/procyclingstats-mcp-server", "procyclingstats-mcp"]
}
}
}Using a global install:
{
"mcpServers": {
"procyclingstats": {
"command": "procyclingstats-mcp",
"args": []
}
}
}"What WorldTour races are happening in 2025?"
"Show me the results of Tour de France 2025 Stage 1"
"What's Tadej Pogačar's rider profile?"
"Who's on the startlist for the Giro d'Italia 2025?"
"Search for Remco Evenepoel"
All PCS URLs use the slug format:
Races: race/tour-de-france/2025
Stages: race/tour-de-france/2025/stage-1
One-day results: race/milano-sanremo/2025/result
Riders: rider/tadej-pogacar
The server enforces a 0.5s delay between requests to PCS and retries automatically on server errors (500/502/503/429).
Built on top of the procyclingstats Python library.
Discover professional cycling races from the PCS calendar for a given year.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year (e.g. 2025). | |
| tiers | No | Optional list of race tier filters. Valid values: 'worldtour', 'proseries', 'class1', 'class2'. Defaults to ['worldtour', 'proseries'] (top two tiers). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, any rate limits, authorization requirements, or pagination behavior. The existence of an output schema partially mitigates the lack of return value details, but the description adds minimal behavioral context beyond the purpose.
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?
A single sentence that is direct and front-loaded with the verb and resource. No extraneous information; every word earns its place.
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?
The tool is simple with 2 parameters and an output schema. The description covers the core purpose but omits mentioning that the 'tiers' parameter can filter results. While the schema provides this, a more complete description would note filtering capability.
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 description coverage is 100% for both parameters (year and tiers), so the schema already documents their meaning. The description does not elaborate on parameters beyond what is in the schema, meeting the baseline for high coverage.
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 fetches professional cycling races from the PCS calendar for a given year, with a specific verb ('discover') and resource. It distinguishes from sibling tools like 'get_race_overview' or 'get_stage_results' which target individual races or details.
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 usage for listing races by year, but lacks explicit when-to-use vs alternatives or exclusions. However, the context of sibling tools makes it clear this is for discovery, not detailed views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata and stage list for a race.
| Name | Required | Description | Default |
|---|---|---|---|
| race_url | Yes | PCS race URL, e.g. 'race/tour-de-france/2025'. Can also be a base URL like 'race/tour-de-france' for the latest edition. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details such as authentication requirements, rate limits, or side effects. It only states what the tool returns, not how it behaves.
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?
The description is a single, concise sentence that effectively communicates the core function without unnecessary 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?
Given the simple input (one parameter) and the presence of an output schema, the description is largely sufficient. However, it could mention that it returns both metadata and stage list to confirm expectations.
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% for the single parameter 'race_url', with a clear description in the schema. The tool description repeats the purpose but adds no additional detail about the 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 'metadata and stage list for a race', specifying verb and resource. It is distinct from sibling tools like discover_races (search) and get_stage_results (specific stage data).
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?
No explicit guidance on when to use this tool versus siblings. The description implies its purpose but does not exclude cases where other tools might be more appropriate, leaving ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the startlist for a race.
| Name | Required | Description | Default |
|---|---|---|---|
| race_url | Yes | PCS race URL, e.g. 'race/tour-de-france/2025'. The '/startlist' suffix is added automatically. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is minimal. It does not disclose behavioral traits such as what the startlist includes, authentication requirements, or side effects. The description adds no value beyond the name.
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?
The description is a single sentence, which is concise and front-loaded. However, it could benefit from slightly more detail to improve its utility without becoming verbose.
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?
The tool has an output schema, so the description does not need to explain return values. However, given the simplicity of the tool, the description is adequate but minimal, lacking details about the structure of the startlist.
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?
The input schema has 100% coverage with a clear description of the race_url parameter. The description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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 'Get the startlist for a race' clearly states the action (get) and the resource (startlist for a race). It is specific and distinguishes from sibling tools like get_race_overview and get_stage_results.
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?
No explicit usage guidelines are provided. The context signals include sibling tool names, which helps infer when to use this tool, but the description lacks guidance on when to use it versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a professional cyclist's profile from PCS.
| Name | Required | Description | Default |
|---|---|---|---|
| rider_url | Yes | PCS rider URL, e.g. 'rider/tadej-pogacar'. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only indicates a read operation ('Get'). It does not disclose any behavioral traits such as rate limits, authentication needs, or what happens if the rider URL is invalid.
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?
The description is a single, front-loaded sentence that effectively conveys the tool's core purpose. It is concise without being under-specified.
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 the tool's simplicity (one parameter, output schema present), the description provides minimal but adequate context. However, it lacks usage guidelines and fails to mention that the rider URL is required.
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?
The schema covers the single parameter fully with an example. The description does not add extra meaning beyond the schema, but the high coverage (100%) justifies a baseline score of 3.
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 verb 'Get', the resource 'professional cyclist's profile', and the source 'PCS'. It is specific enough to distinguish from sibling tools that focus on races and searches.
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?
No guidance is provided on when to use this tool versus alternatives like search_pcs. The description lacks context for usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get results and metadata for a specific stage or one-day race.
| Name | Required | Description | Default |
|---|---|---|---|
| stage_url | Yes | PCS stage URL, e.g. 'race/tour-de-france/2025/stage-1'. For one-day races use 'race/milano-sanremo/2025/result'. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states the operation type (get), but omits details like authentication requirements, rate limits, error behavior, or what happens with invalid URLs.
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?
The description is a single, front-loaded sentence that efficiently conveys the tool's functionality without any redundant language. Every word serves a purpose.
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 the tool's simplicity (one parameter, output schema present), the description is nearly complete. It explains the input format but could briefly mention what 'metadata' includes. However, the output schema likely covers that, so this is a minor gap.
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?
The schema covers the single parameter with description, and the tool description adds value by providing concrete examples ('race/tour-de-france/2025/stage-1' and 'race/milano-sanremo/2025/result'), clarifying differences between stage and one-day races beyond the 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?
The description clearly states the tool retrieves results and metadata for a stage or one-day race. It uses a specific verb ('get') and resource ('results and metadata'), and the context of sibling tools like 'discover_races' and 'get_race_overview' differentiates its purpose.
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 when to use the tool (when needing results for a stage or one-day race) but lacks explicit guidance on when not to use it or alternatives. No direct mention of alternatives among siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ProCyclingStats for riders, races, or teams.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text (e.g. 'Pogacar', 'Tour de France', 'UAE'). | |
| max_results | No | Maximum number of results (default 20). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the search scope. It lacks details on read-only nature, side effects, or response behavior (e.g., pagination, result limits), leaving the agent with insufficient behavioral context.
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?
One sentence, no wasted words. It is front-loaded. Could improve by adding minimal usage context without being verbose.
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 that an output schema exists, description does not need to detail return values. However, it omits search behavior (e.g., ordering, default limits), which would help the agent despite the output schema.
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 covers all parameters with descriptions, so the description adds no extra meaning beyond the input schema. Baseline 3 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?
The description clearly states the tool searches for three entity types (riders, races, teams) using a specific verb. This distinguishes it from sibling tools like discover_races and get_rider_profile, which are narrow.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies general search, but does not state when to prefer specific tools or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: discovering races, getting race overview, startlist, rider profile, stage results, and general search. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case, e.g., discover_races, get_race_overview, get_rider_profile. No deviations.
6 tools is well-scoped for a cycling statistics server. Each tool covers a necessary operation without being excessive or insufficient.
The set covers core operations: race discovery, details, participants, rider profiles, stage results, and search. Missing team profiles and detailed rider season results, but the essential domain is covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Tour de France 2026 MCP — 21 stages, race phase tracking, stage start times, stage profiles.
Strava MCP tools for AI: athletes, activities, segments, clubs, routes. Powered by HAPI MCP server.
Football-Data.org MCP — soccer competitions, matches, standings
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lewis-mcgillion/procyclingstats-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server