Which integrations are available for this server?

Provides tools to interact with Tesla's Owner API, enabling management of vehicles and solar systems, including authentication, vehicle data retrieval, command sending, and solar system monitoring.

How do I use Tesla 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., "@Tesla MCP Server list my vehicles" 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.

Tesla MCP Server

by robcerda

Overview Schema Related Servers Score Discussions

Python

Remote

Tesla MCP Server

Model Context Protocol (MCP) server for connecting Claude with the Tesla Owner API. It provides tools for authentication and data retrieval for Tesla vehicles and solar systems.

Requirements

Python 3.11
Model Context Protocol (MCP) Python SDK
httpx
python-dotenv

Related MCP server: Enphase Solar MCP Server

Setup

1. Install uv (recommended)

curl -LsSf https://astral.sh/uv/install.sh | sh

2. Clone this repository

git clone https://github.com/yourusername/tesla-mcp-server.git
cd tesla-mcp-server

3. Create and activate a virtual environment

# Create virtual environment
uv venv

# Activate virtual environment
# On macOS/Linux:
source .venv/bin/activate
# On Windows:
.venv\Scripts\activate

4. Sync project dependencies

uv sync

Usage

Authentication Setup

This server uses Tesla's Owner API and implements a secure OAuth2 authentication flow. Before using the server with Claude Desktop, you must first run the authentication setup script.

1. Run Authentication Setup

IMPORTANT: You must run this setup script before using the server with Claude:

python setup_auth.py

This script will:

Prompt you to authenticate via your browser
Walk you through the Tesla OAuth2 flow
Create a refresh_token.txt file for future sessions
Test the API connection to ensure everything works

Do not commit refresh_token.txt to version control.

2. Authentication Flow Details

On first run of setup_auth.py, you will be prompted to authenticate via your browser
Follow the instructions in the terminal to complete the OAuth2 flow
After successful authentication, a refresh_token.txt file will be created and used for future sessions
The refresh token will be automatically used by the MCP server for subsequent API calls

Configure Claude Desktop

To use this server with Claude Desktop, you need to add it to your Claude Desktop configuration.

Run the following from the tesla_mcp_server directory to configure Claude Desktop:

mcp install src/tesla_mcp_server/server.py --name "Tesla" --with-editable .

If you open your Claude Desktop App configuration file claude_desktop_config.json, it should look like this:

{
  "mcpServers": {
    "Tesla": {
      "command": "/Users/<USERNAME>/.cargo/bin/uv",
      "args": [
        "run",
        "--with",
        "mcp[cli]",
        "--with-editable",
        "/path/to/tesla-mcp-server",
        "mcp",
        "run",
        "/path/to/tesla-mcp-server/src/tesla_mcp_server/server.py"
      ],
      "env": {
        "LOG_LEVEL": "INFO"
      }
    }
  }
}

Where /path/to/ is the path to the tesla-mcp-server code folder in your system.

Restart Claude Desktop.

Use the MCP server with Claude

Once the server is running and Claude Desktop is configured, you can use the following tools to interact with your Tesla systems:

tesla_auth_status: Check Tesla authentication status
get_vehicles: Get a list of all your vehicles
get_vehicle: Get detailed information about a specific vehicle
send_command: Send a command to a vehicle
get_solar_system: Get status of a solar system
get_solar_history: Get history of a solar system
get_system_summary: Get a summary of all Tesla systems

Re-authentication

If you ever need to re-authenticate, simply delete refresh_token.txt and run python setup_auth.py again.

Development and testing

Install development dependencies and run the test suite with:

uv sync --all-extras
pytest -v tests

Running the server locally

To start the server manually (useful when developing or testing), run:

mcp run src/tesla_mcp_server/server.py

License

The GNU General Public License v3.0

Available Tools

7 tools

get_solar_historyD

Get history of a solar system

ParametersJSON Schema

Name	Required	Description	Default
`site_id`	Yes
`period`	No		day

TDQS

D1.5/5.0

Behavior1/5

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

No annotations provided; description does not disclose read-only nature, authentication requirements, or any behavioral traits beyond 'get history'.

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

Conciseness2/5

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

Extremely concise (one sentence) but sacrifices necessary detail, making it under-informative.

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

Completeness1/5

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

Incomplete for a tool with 2 params, no output schema, and no annotations; does not clarify return format, possible period values, or data content.

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 has 0% description coverage; description adds no meaning to 'site_id' or 'period' parameters, failing to explain accepted values or format.

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

Purpose2/5

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

Description 'Get history of a solar system' is vague; does not specify what type of history (e.g., energy production, events) and fails to differentiate from sibling tools like 'get_solar_system' or 'get_system_summary'.

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 alternatives; lacks context for appropriate usage scenarios.

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

get_solar_systemC

Get status of a solar system

ParametersJSON Schema

Name	Required	Description	Default
`site_id`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, and description lacks behavioral details such as whether this is read-only, any side effects, authentication requirements, or what 'status' entails. Minimal disclosure beyond the core action.

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 it is under-specified. There is no waste, but the brevity sacrifices necessary information.

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?

Given the absence of output schema and annotations, the description should provide more context about what 'status' contains, any prerequisites, or return format. It is insufficient for an agent to fully understand the tool's behavior.

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 has 0% description coverage for the only parameter (site_id). The tool description provides no additional meaning about site_id, such as format, source, or constraints.

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?

Description clearly states verb 'Get' and resource 'status of a solar system'. However, it does not differentiate from sibling tools like get_solar_history or get_system_summary, which may have similar purposes.

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 alternatives. The description solely states functionality 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_system_summaryC

Get a summary of all Tesla systems

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description bears full responsibility. It only states 'Get a summary' but does not disclose whether the operation is read-only, any performance implications, or data freshness. The behavioral details are insufficient.

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. However, for a tool with no parameters, it could still include more contextual information without being wasteful. The brevity is acceptable but not exemplary.

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?

The description lacks detail about what the summary contains (e.g., status of systems, metrics) and which systems are included. Without output schema, the description is the only source, and it is inadequate for full understanding.

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?

There are no parameters, and schema coverage is 100% trivially. The description does not add parameter information, but with zero parameters, a baseline of 4 is appropriate as there is nothing to add.

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 retrieves a summary of all Tesla systems, distinguishing it from sibling tools like get_solar_system or get_vehicle which are system-specific. However, 'all Tesla systems' is somewhat broad and could be more specific about scope.

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 such as get_solar_system or get_vehicle. The description does not mention any prerequisites or contexts where this tool is preferred.

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

get_vehicleC

Get detailed information about a specific vehicle

ParametersJSON Schema

Name	Required	Description	Default
`vehicle_id`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavior. It only states 'get detailed information' without mentioning side effects, authentication needs, rate limits, or what 'detailed' includes.

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 efficient sentence with no redundancy. However, it is so brief that it lacks substance, preventing a higher score.

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?

Given the lack of output schema and annotations, the description should provide more context about return values or prerequisites. It is incomplete for a tool with one required parameter.

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 the description does not elaborate on the vehicle_id parameter—no format, source, or validation details. The single parameter is mentioned only implicitly.

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 action 'Get detailed information' and the resource 'a specific vehicle'. It distinguishes from sibling tools like 'get_vehicles' by specifying '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 provided on when to use this tool versus alternatives, such as prerequisites like obtaining a vehicle ID from get_vehicles first.

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

get_vehiclesA

Get list of all vehicles

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits beyond the basic retrieval operation. It fails to mention that it is a read-only, non-destructive action or any authentication requirements.

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, clear sentence with no unnecessary words. It is appropriately front-loaded and concise.

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?

For a simple list tool with no parameters or output schema, the description is minimally adequate. However, it could provide more context, such as the nature of the returned data (e.g., summary vs. full details) or how it relates to 'get_vehicle'.

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?

The input schema has no parameters and 100% schema coverage, so the baseline is 4. The description does not need to add parameter details since none exist.

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 'Get list of all vehicles' uses a specific verb and resource, clearly indicating the tool retrieves a collection of all vehicles. It naturally distinguishes from sibling tools like 'get_vehicle' (singular) and solar-related 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?

No guidance is provided on when to use this tool versus alternatives, such as 'get_vehicle' for a specific vehicle. The description lacks any when-to-use or when-not-to-use context.

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

send_commandC

Send a command to a vehicle

ParametersJSON Schema

Name	Required	Description	Default
`vehicle_id`	Yes
`command`	Yes
`parameters`	No

TDQS

C2.3/5.0

Behavior2/5

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

No annotations provided, so the full burden falls on the description. It only states 'send a command' without disclosing side effects, authentication needs, or whether it is destructive, leaving the agent underinformed.

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

Conciseness2/5

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

The description is a single sentence, but it is under-specified. It lacks necessary details to be useful, making it too concise to the point of inadequacy.

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

Completeness1/5

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

Given no output schema, no annotations, and 0% parameter description coverage, the description is severely incomplete. It fails to provide essential context for a 3-parameter tool, especially regarding expected commands and return values.

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 explanations for the three parameters (vehicle_id, command, parameters). The agent cannot infer valid values or format.

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 action 'send a command' and the resource 'vehicle', which is specific. However, it does not distinguish from sibling tools, and 'command' is vague without further context.

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 alternatives. It lacks prerequisites, context, or exclusions, leaving the agent to guess.

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

tesla_auth_statusB

Check Tesla authentication status

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full burden but reveals no behavioral details (e.g., that it is a read-only operation, or what happens if not authenticated). It is too minimal to inform the agent about side effects or requirements.

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 with no wasted words. It is front-loaded and to the point, though it lacks additional structure or elaboration.

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 simplicity of the tool (no params, no output schema), the description is adequate but could be more complete by specifying what the status indicates (e.g., boolean, string) or any related state. It meets minimum viability but leaves gaps.

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?

There are no parameters, so the baseline is 4. The description does not add anything beyond the schema (which is empty), but no additional meaning is needed since there are no parameters to describe.

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 'Check Tesla authentication status' clearly states the verb 'Check' and the resource 'Tesla authentication status', making the purpose easy to understand. It also distinguishes itself from sibling tools like get_vehicle or get_solar_system, which deal with other resources.

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. There is no mention of prerequisites, when not to use it, or any context about authentication flow.

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

Install Server

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

TDQS

C2.6/5.0

Disambiguation4/5

Most tools target distinct resources (solar history, solar status, system summary, vehicle detail, vehicle list, auth status, and a general command sender). However, 'get_system_summary' might overlap with vehicle and solar status tools, causing some potential confusion.

Naming Consistency3/5

Tool names use mixed patterns: most start with 'get_', one with 'send_', and one with 'tesla_auth_status' (no verb prefix). This inconsistency could hinder agent prediction of similar operations.

Tool Count4/5

With 7 tools, the server covers both vehicle and solar domains without being overwhelming. The count feels appropriate for a focused Tesla integration.

Completeness3/5

Basic retrieval is covered for vehicles and solar, and vehicle commands are supported via a generic tool. However, missing operations like solar command/settings or vehicle-specific action tools (e.g., lock, climate) leave notable gaps.

Maintenance

ActivityInactive

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

mytesla.io
io.mytesla
Control your Tesla from your AI assistant - climate, charging, access, and security.
Home Automation & IoT Travel & Transportation
2
UluP Spaces
com.ulupspaces.www
Connect Claude AI to UluP Spaces via MCP — create projects, nodes, and tasks with OAuth 2.0.
Project Management Workplace & Productivity
1
platform7n
tech.p7n
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Communication Project Management Workplace & Productivity
2
Fitness AI ConnectorOAuth
io.github.fmp-projects
Garmin data in Claude & ChatGPT via the Garmin Health API. OAuth sign-in, no password sharing.
Health & Wellness Fitness Tracking
21

Related MCP Servers

Tessie MCP Extension
Location Services Search
keithah
A
license
B
quality
A
maintenance
Enables Claude Desktop to access Tesla vehicle data through the Tessie API. Users can query their car's location, battery level, mileage, driving history, and charging status using natural language.
Updated 24 days ago (2026-08-09 13:43 UTC)
5
7
MIT
Enphase Solar MCP Server
Energy Home Automation & IoT
xianman
A
license
Not graded
quality
D
maintenance
Connects Claude Desktop to the Enphase Developer API v4 for read-only access to solar production, consumption, battery, and EV charger data, with optional write tools for battery settings and EV charging.
Updated 4 months ago (2026-05-05 02:50 UTC)
MIT
Strava MCP Server
Health & Wellness Fitness Tracking Sports
manojanasuri16
F
license
B
quality
D
maintenance
Connects Claude or any MCP client to the Strava API v3, enabling access to fitness data such as activities, athletes, clubs, segments, routes, and streams.
Updated 6 months ago (2026-03-07 18:57 UTC)
37
remote-mcp-oauth-github
Version Control Security
tubone24
A
license
Not graded
quality
D
maintenance
Enables Claude to authenticate with GitHub OAuth and access tools for user information, calculations, and GitHub repositories.
Updated 10 months ago (2025-11-17 03:48 UTC)
5
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/robcerda/tesla-mcp-server'

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