How do I use f1-mcp-server?

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., "@f1-mcp-server Who won the 2023 Monaco Grand Prix?" 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.

f1-mcp-server

by GovIndLok

Overview Schema Related Servers Score Discussions

Python

Hybrid

Formula 1 MCP Server

A Model Context Protocol (MCP) server that empowers AI assistants (such as Claude Desktop, Cursor, or custom agents) to inspect, explore, and query Formula 1 data hosted on AWS.

Built using FastMCP, this server integrates natively with AWS Glue Data Catalog (schema metadata) and Amazon Athena (serverless SQL execution over S3 Parquet tables).

Relationship to Upstream Data Pipeline

This repository is designed as a downstream AI consumption layer built directly on top of the Formula 1 Enterprise Data Pipeline (aws-f1-pipeline).

How It Fits into the End-to-End Architecture

                            UPSTREAM DATA PIPELINE
                          (GovIndLok/aws-f1-pipeline)
            ┌─────────────────────────────────────────────────────┐
            │          Amazon S3 Data Lake (dbt-athena)           │
            │               Bronze ➔ Silver ➔ Gold                │
            └──────────────────────────┬──────────────────────────┘
                                       │ (Table & Schema Metadata)
                                       ▼
                           ┌───────────────────────┐
                           │ AWS Glue Data Catalog │
                           │    (Gold Database)    │
                           └───────────┬───────────┘
                                       │
═══════════════════════════════════════╪═══════════════════════════════════════
                         DOWNSTREAM AI INTERFACE
                            (This Repository)
                                       │
                                       ▼
                         ┌───────────────────────────┐
                         │       f1-mcp-server       │
                         │  - FastMCP (Python)       │
                         │  - Boto3 (Glue & Athena)  │
                         └─────────────┬─────────────┘
                                       │ (stdio / SSE JSON-RPC)
                                       ▼
                         ┌───────────────────────────┐
                         │        AI Clients         │
                         │ (Claude Desktop / Cursor) │
                         └───────────────────────────┘

Upstream Pipeline (aws-f1-pipeline):
- Transforms Formula 1 race and telemetry data using dbt-athena across Medallion layers (Bronze $\rightarrow$ Silver $\rightarrow$ Gold), materializing optimized Apache Parquet tables in Amazon S3.
- Registers dimensional models, facts, and analytical marts into the AWS Glue Data Catalog.
Downstream Application (f1-mcp-server):
- Connects directly to the curated Gold schema in AWS Glue.
- Translates high-level agent intents into validated Athena queries.
- Exposes structured tools that allow LLMs to explore schemas, sample records, and perform multi-table joins without writing SQL by hand or needing direct AWS console access.

Related MCP server: MCP Server F1Data

Gold Data Schema

The server queries the gold database generated by the upstream pipeline, organized into a Star schema:

Layer	Tables	Description
Dimensions (`dim_*`)	`dim_driversdim_constructorsdim_circuitsdim_races`	Reference data containing driver details, teams, circuits, track coordinates, and race calendars.
Facts (`fct_*`)	`fct_resultsfct_lap_timesfct_pit_stopsfct_qualifyings`	Granular race events, grid positions, finishing results, lap timing, and pit stop durations.
Marts (`mart_*`)	`mart_drivers_season_statsmart_constructors_season_stats`	Pre-aggregated standings and championship points for fast retrieval.

MCP Tools

The server registers 4 tools under the FastMCP framework:

1. `list_tables`

Discovers tables available in the Gold schema, automatically grouped by marts, facts, and dimensions.

Argument: table_type (optional): Filter by "marts", "facts", or "dims".
Returns: Dictionary listing tables and their descriptions.

2. `tables_schema`

Fetches column names and data types for one or more tables from the Glue Data Catalog.

Argument: table_s: List of table names, e.g. ["dim_drivers", "fct_results"].
Returns: Dictionary mapping table names to their column definitions.

3. `get_sample_data`

Previews the top 10 rows of a table with schema-validated column filters.

Arguments:
- table_name: Name of the table to sample.
- filters (optional): List of filter rules: [{"column": "nationality", "operator": "=", "value": "British"}]. Supported operators include =, !=, >, <, >=, <=, IN, BETWEEN, LIKE.
- join_logic (optional): Combine multiple filters using "AND" (default) or "OR".
Returns: JSON object containing sample rows.

4. `run_a_query`

Executes custom analytical queries joining fact and dimension tables on Athena.

Arguments:
- main_table: Primary table to query (e.g. "fct_results").
- columns: Dictionary mapping tables to requested column names, e.g. {"fct_results": ["position", "points"], "dim_drivers": ["forename", "surname"]}.
- join (optional): List of joins: [{"table": "dim_drivers", "join_column": "driver_id", "on_column": "driver_id"}].
- filters (optional): Filter criteria with automatic type and operator formatting.
- filter_logic (optional): "AND" (default) or "OR".
- limit (optional): Maximum rows to return (default: 20, max: 500).
Validation:
- Ensures every table referenced in columns is either the main_table or explicitly joined.
- Formats strings with single quotes, tuples for IN, and numeric bounds for BETWEEN.

Environment Configuration

Copy .env.example to .env and provide your AWS and Athena details:

cp .env.example .env

Configuration reference:

# AWS Configuration
AWS_PROFILE=your-aws-profile
AWS_REGION=your-aws-region

# Athena & Glue Settings
GLUE_DATABASE=gold
S3_RESULTS_BUCKET=s3://<your-athena-query-results-bucket>/staging/query-results/
QUERY_TIMEOUT_SECONDS=15

# MCP Server Settings
MCP_SERVER_HOST=127.0.0.1
MCP_SERVER_PORT=8000

Getting Started

1. Prerequisites

Python 3.12+
uv (recommended) or standard pip
Valid AWS credentials with permissions for Athena (StartQueryExecution, GetQueryExecution, GetQueryResults), Glue (GetTables, GetTable), and S3 (read/write access to query results bucket).

2. Installation

# Clone the repository
git clone https://github.com/GovIndLok/f1_mcp_server.git
cd f1_mcp_server

# Install dependencies using uv
uv sync

# Activate the virtual environment
source .venv/bin/activate

3. Running the Server

Standard Input/Output (`stdio`) — Default for local AI clients:

source .venv/bin/activate
python -m src.server.mcp_server --transport stdio

Server-Sent Events (`sse`) — For network or containerized setups:

source .venv/bin/activate
python -m src.server.mcp_server --transport sse --port 8080

Client Integration

Claude Desktop

Add the server definition to your claude_desktop_config.json:

{
  "mcpServers": {
    "f1-mcp-server": {
      "command": "/path/to/f1_mcp_server/.venv/bin/python",
      "args": ["-m", "src.server.mcp_server", "--transport", "stdio"],
      "cwd": "/path/to/f1_mcp_server",
      "env": {
        "AWS_PROFILE": "your-aws-profile",
        "AWS_REGION": "your-aws-region",
        "GLUE_DATABASE": "gold",
        "S3_RESULTS_BUCKET": "s3://<your-athena-query-results-bucket>/staging/query-results/"
      }
    }
  }
}

Cursor

In Cursor Settings $\rightarrow$ Features $\rightarrow$ MCP Servers, add:

Name: f1-data
Type: command
Command: python -m src.server.mcp_server --transport stdio

Deployment

For containerized or remote deployments, run the server using the SSE transport (--transport sse --port 8080). It can be deployed as an AWS ECS Fargate container behind an Application Load Balancer (ALB) or API reverse proxy, with an IAM Task Role configured for least-privilege access to Athena, Glue, and S3.

Available Tools

4 tools

get_sample_dataA

Get sample data (top 10 rows) from a table with optional filters.

Args: table_name: Name of the table to query filters: List of filters with format [{"column": "col_name", "operator": "=", "value": "value"}].(Make sure value is proper format int/string/float) join_logic: Combine filters with "AND" or "OR"

ParametersJSON Schema

Name	Required	Default
`filters`	No
`join_logic`	No	AND
`table_name`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the transparency burden. It does disclose useful behavior: the result is capped at 10 rows, filtering is optional, and join_logic combines filters with AND/OR. However, it does not state whether the operation is read-only, what columns are returned, or how errors are handled, leaving some behavioral ambiguity.

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 one-sentence purpose is front-loaded, followed by a compact Args block where each parameter earns its place. There is no redundant or filler text.

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?

For a simple preview tool, the description covers the essential call mechanics: target table, filter shape, and join behavior. It is a little thin on the output side—no explicit statement of returned columns or empty-result behavior—and it does not mention the sibling run_a_query alternative, but the row cap and filter semantics make the tool usable.

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

Parameters5/5

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

The input schema has no property descriptions and only 0% coverage, but the description documents all three parameters: table_name, filters (with a concrete JSON format and a value-type warning), and join_logic (with allowed AND/OR values). This fully compensates for the schema's silence.

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 opening line, 'Get sample data (top 10 rows) from a table with optional filters,' names a specific action, a resource (table), and an explicit row cap. This distinguishes it from sibling tools like list_tables and tables_schema, which return metadata, and from run_a_query, which implies a broader query rather than a capped preview.

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 implies a quick-preview use case but never explicitly says when to choose this over run_a_query or how it differs from list_tables/tables_schema. There are no when-to-use or when-not-to-use statements, so an agent must infer tool selection from the name alone.

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

list_tablesA

List tables in Gold Schema, optionally filtered by type (marts, facts, dims).

ParametersJSON Schema

Name	Required	Description	Default
`table_type`	No

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It clearly communicates that this is a read-only listing operation and mentions the optional filter scope, but it does not disclose return format, ordering, or pagination behavior. For a simple list tool this is adequate but not rich.

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?

A single sentence that front-loads the verb and resource, states the optional filter, and wastes no words. Every element contributes to understanding the tool's function.

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?

For a tool with one optional parameter and no output schema, the description provides enough information to call it correctly. The main gap is the lack of explicit routing versus sibling tools, but this is minor given the simplicity of the operation.

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?

With 0% schema description coverage, the description compensates by explaining that table_type filters results and enumerating the valid categories ('marts, facts, dims'). The word 'optionally' signals that null means unfiltered, though the exact default behavior is not explicitly stated.

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 uses a specific verb ('List'), a clear resource ('Gold Schema'), and a scope ('optionally filtered by type (marts, facts, dims)'). It is clear enough to distinguish from siblings like tables_schema, run_a_query, and get_sample_data, but it does not explicitly name the alternatives.

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 implies the usage context: list tables in Gold Schema, optionally narrowing by table type. However, it provides no explicit guidance on when to choose this tool over tables_schema or run_a_query, nor any exclusions or prerequisites.

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

run_a_queryA

Execute custom queries with joins and filters on F1 data tables.

Args: main_table: Name of the main table to query (e.g 'fct_lap_times', 'fct_results' etc) columns: Dictonary mapping table name to list of columns. Format: {'table_name': ['col1','col2']}. Main table must be included joins: List of joins. Format:[{"table": "dim_table", "join_column": "id", "on_column": "fk_id"}] filters: List of filters. Format: [{"column": "col_name", "operator": "=", "value": "value"}]. (Make sure value is proper format int/string/float) (Use list[number, number] for between operator) filter_logic: Combine filters with "AND" or "OR" limit: Max rows to return (default: 20, max)

ParametersJSON Schema

Name	Required	Default
`join`	No
`limit`	No
`columns`	Yes
`filters`	No
`main_table`	Yes
`filter_logic`	No	AND

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals constraints such as 'Main table must be included', value formatting requirements, and a default limit of 20, but it does not explicitly state whether the operation is read-only, what the response format is, or what 'max' means in the limit line.

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 front-loaded with a clear summary followed by an organized Args list. It includes valuable examples and constraints without excessive prose. Minor issues like the typo 'Dictonary' and the ambiguous 'limit: default: 20, max' keep it from being perfect.

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?

The parameter coverage is strong and the nested structures are explained, but the absence of an output schema and annotations leaves gaps: no description of the returned data shape, no clarity on whether queries are read-only, and the limit maximum value is unspecified. These are meaningful gaps for a query tool.

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

Parameters5/5

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

Schema description coverage is 0%, so parameter documentation falls entirely on the description. It provides concrete formats and examples for all six parameters, including nested join/filter structures and the special between-operator syntax, fully compensating for the schema's silence.

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 opens with a specific action and resource: 'Execute custom queries... on F1 data tables.' It also names the key capabilities (joins and filters) that set it apart from sibling tools like list_tables and get_sample_data, making its role unambiguous.

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 explains how to use the tool through its args list, but it does not explicitly state when to choose this tool over the siblings or when it is not appropriate. Usage is implied ('custom queries'), with no exclusions or alternative routing.

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

tables_schemaC

Schema for a table or multiple tables

ParametersJSON Schema

Name	Required	Description	Default
`table_s`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, what the returned schema structure looks like, or how errors are handled. The description is not misleading, but it reveals almost no behavioral detail.

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 short phrase with no filler or redundancy. It is easy to parse and front-loads the core subject, though it is minimal enough that brevity is not a substitute for missing detail.

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?

For a simple one-parameter tool the description states the core subject, but with no annotations, no output schema, and no parameter clarification, it leaves the agent to infer both how to call it and what to expect in return. It is not fully inadequate, but it has clear gaps.

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?

The single parameter table_s has 0% schema description coverage, and the description only implies through 'multiple tables' that more than one table may be involved. It does not explicitly clarify that table_s contains table names, how names should be formatted, or what happens for unknown or invalid tables.

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 identifies the resource ('schema') and scope ('a table or multiple tables'), and it is distinguishable from sibling tools that handle sample data, table listing, and query execution. However, it lacks an explicit verb such as 'returns' or 'fetches', so it is clear but not fully specific.

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 about when to use this tool versus list_tables, get_sample_data, or run_a_query. It does not mention prerequisites, limitations, or expected input context, leaving the agent to infer usage entirely.

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.

4 tool updatesv0.1.0Sep 5, 2026
- First observedget_sample_data
- First observedlist_tables
- First observedrun_a_query
- First observedtables_schema

Install Server

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

TDQS

B3.3/5.0

Disambiguation3/5

list_tables and tables_schema are clearly distinct, but get_sample_data and run_a_query overlap significantly—both can query a single table with filters, and run_a_query can reproduce sample-style queries with limit. The descriptions hint at different use cases (quick sample vs. custom joins), but the boundary is not sharply defined.

Naming Consistency3/5

Names are snake_case and somewhat readable, but styles are mixed: list_tables and get_sample_data use a verb+noun pattern, run_a_query adds an article, and tables_schema uses a noun phrase with no verb. Overall it is still predictable enough to navigate, but not a clean consistent convention.

Tool Count4/5

Four tools is small but appropriate for a read-only F1 data exploration server. Each tool covers a meaningful step: discover tables, inspect schemas, sample data, and run custom queries. It does not feel padded or trivially thin.

Completeness4/5

The set covers the core read-only workflow well: list available tables, understand their schema, preview data, and execute arbitrary queries. Minor gaps include no pagination/offset support and no explicit relationship metadata, but agents can work around these via run_a_query and tables_schema.

Maintenance

ActivityMaintained

ResponsivenessNo issues

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

Race Calendar F1 A
app.racecalendar
Anonymous read-only Formula 1 tools, resources, prompts, completion, and interactive dashboard.
Sports Open Data
152
Databricks B
io.github.mcp-dir
Your Databricks Lakehouse in natural language: run SQL on your SQL warehouses, track long-running qu
Data Platforms Databases
171
Dot - AI Data AnalystOAuth
io.github.zurferr
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Search Databases Data Visualization
2
mcp-server AOAuth
io.quanti
Query BigQuery, Snowflake, Redshift & Azure Synapse with natural language
Databases Search Data Platforms
2

Related MCP Servers

AWS Athena MCP Server
Databases Cloud Platforms
ZackFairTS
A
license
A
quality
D
maintenance
Enables AI assistants to execute SQL queries against AWS Athena databases, check query status, retrieve results, and manage saved queries with support for both local and remote deployment via Lambda.
Updated 8 months ago (2026-01-07 12:32 UTC)
5
504
MIT
MCP Server F1Data
Sports Open Data Search
Maxbleu
A
license
Not graded
quality
D
maintenance
Enables interaction with Formula 1 data through LLM interfaces like Claude. Provides access to F1 information including circuits, constructors, drivers, grand prix, manufacturers, races, and seasons.
Updated 8 months ago (2026-01-21 18:16 UTC)
Apache 2.0
mcp-f1analisys
Sports Research & Data
Maxbleu
A
license
Not graded
quality
D
maintenance
Enables Formula 1 data analysis through natural language, providing tools like track dominance, lap time analysis, and team performance comparisons.
Updated 9 months ago (2025-12-03 11:19 UTC)
Apache 2.0
S3 Data Lake MCP Server
Cloud Storage Databases Search
anespo
A
license
Not graded
quality
C
maintenance
Enables AI agents to query S3 data lakes using natural language, with support for CSV, JSON, Parquet and tools for data discovery, analysis, and metadata exploration.
Updated 8 months ago (2026-01-02 18:42 UTC)
1
MIT

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/GovIndLok/f1-mcp-server'

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

Formula 1 MCP Server

Relationship to Upstream Data Pipeline

How It Fits into the End-to-End Architecture

Gold Data Schema

MCP Tools

1. list_tables

2. tables_schema

3. get_sample_data

4. run_a_query

Environment Configuration

Getting Started

1. Prerequisites

2. Installation

3. Running the Server

Standard Input/Output (stdio) — Default for local AI clients:

Server-Sent Events (sse) — For network or containerized setups:

Client Integration

Claude Desktop

Cursor

Deployment

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `list_tables`

2. `tables_schema`

3. `get_sample_data`

4. `run_a_query`

Standard Input/Output (`stdio`) — Default for local AI clients:

Server-Sent Events (`sse`) — For network or containerized setups: