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., "@iRacing Data MCP Server find the career statistics for driver Max Verstappen"
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 Node.js Model Context Protocol (MCP) server that provides seamless access to iRacing's racing simulation data API. This project serves as both a standalone CLI tool and an MCP server for AI assistant integration.
AI Assistant Ready: Seamlessly integrate with Claude, ChatGPT, and other AI assistants
Real-time Data Access: Live access to iRacing's comprehensive racing data
Automatic Authentication: Handles login and session management automatically
Type-safe Operations: Full TypeScript support with Zod schema validation
Member Profiles: Detailed driver information including licenses and ratings
Team Information: Comprehensive team data and statistics
Career Statistics: Complete racing career history and achievements
Season Recaps: Detailed season performance and progression
Driver Lookup: Search and find drivers by name
API Documentation: Built-in access to iRacing's API documentation
MCP Server: For AI assistant integration
CLI Tool: For direct command-line access and automation
Related MCP server: OpenF1 MCP Server
To use this MCP server with AI assistants like Claude Desktop, add the following configuration to your MCP settings file:
For Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"iracing-data-mcp-server": {
"command": "npx",
"args": [
"iracing-data-mcp-server@latest",
"@modelcontextprotocol/server-filesystem",
"/path/to/your/cookie-jar-file"
]
"env": {
"COOKIE_JAR": "/path/to/your/cookie-jar-file",
"EMAIL": "your.email@example.com",
"API_KEY": "your_api_key_here"
}
}
}
}The server will run and provide the following tools to AI assistants:
Tool | Description | Parameters |
| Authenticate with iRacing | None |
| Get member profile data |
|
| Retrieve team information |
|
| Get season recap data |
|
| Get career statistics |
|
| Search for drivers |
|
Create a .env file in your project directory:
# Required: Path to store authentication cookies
COOKIE_JAR=./cookies.txt
# Required: Your iRacing account credentials
EMAIL=your.email@example.com
# Option 1: Use your iRacing password
PASSWORD=your_password
# Option 2: Use pre-generated API key (recommended for security)
# API_KEY=your_api_key_hereBefore using the cli, authenticate with iRacing:
npm run loginUse the command-line interface for direct data access:
# Single member
npm run api member 123456
# Multiple members
npm run api member 123456,789012npm run api team 123456npm run api member-career 123456# Current season recap
npm run api member-recap --member-id 123456
# Specific year and season
npm run api member-recap --member-id 123456 --year 2024 --season 1npm run api driver-lookup "Max Verstappen"npm run api documentationNode.js 24+
npm
iRacing account with active subscription
git clone https://github.com/yourusername/iracing-data-mcp-server.git
cd iracing-data-mcp-server
npm installRecommended: Use an API key for enhanced security:
Generate API Key:
const crypto = require('crypto');
const apiKey = crypto.createHash('sha256')
.update(password + email)
.digest('base64');Set in Environment:
API_KEY=your_generated_api_key
# Remove PASSWORD variable when using API_KEYThe server automatically manages authentication cookies:
Stores cookies in the path specified by COOKIE_JAR
Automatically refreshes expired sessions
Handles authentication errors gracefully
| Name | Required | Description | Default |
|---|---|---|---|
| driver_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| member_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| member_id | Yes | ||
| year | No | ||
| season | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| member_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.3.2driver_lookupget_member_careerget_member_recapget_members_profileget_teamloginThe tools are mostly distinct in purpose (e.g., driver_lookup vs. get_team vs. login), but there is some overlap between get_member_career, get_member_recap, and get_members_profile, which all seem to retrieve member-related data with unclear boundaries. Without descriptions, it's ambiguous whether these tools serve different aspects of member information or could be consolidated.
The naming follows a consistent snake_case pattern throughout, with a mix of verb_noun (e.g., driver_lookup, get_member_career) and noun-only (e.g., login) styles. While not perfectly uniform in verb usage, the structure is readable and predictable, with only minor deviations from a strict convention.
With 6 tools, the count is reasonable for a data server focused on iRacing, covering key operations like login, member data retrieval, and team info. It's slightly lean but not overly sparse, as it includes essential functions without obvious bloat, though more tools might be expected for a comprehensive racing data service.
The tool set is significantly incomplete for an iRacing data server, lacking obvious gaps such as tools for race results, standings, schedules, or car/track data. It focuses narrowly on member and team profiles without covering broader racing data, which will likely cause agent failures when trying to perform common tasks like fetching race outcomes or event details.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Anonymous read-only Formula 1 tools, resources, prompts, completion, and interactive dashboard.
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
Web search and page-reading for AI agents. One-click OAuth connect, or a Caesar API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/emilioSp/iracing-data-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
