What can you do with this server?

The Rivian MCP server provides read-only access to your Rivian vehicle data through Claude or a terminal CLI. * Authentication: Log in with rivian_login and complete 2FA verification via rivian_submit_otp * Account Info: Retrieve your Rivian account details, linked vehicles, and software versions (rivian_get_user_info) * Vehicle State: Check live status including battery level, range, door locks, tire pressure, location, and climate settings (rivian_get_vehicle_state) * OTA Updates: View your current software version and whether a new update is available (rivian_get_ota_status) * Charging: Monitor active charging sessions (power, battery level, time remaining, cost), historical charging data, and configured schedules (rivian_get_charging_session) * Drivers & Keys: See who has vehicle access, including drivers, phone keys, and key fobs (rivian_get_drivers_and_keys) * CLI Access: Use the rivian command-line interface without Claude (e.g., rivian ota, rivian stats) * Session Persistence: Sessions are saved automatically for 7 days via ~/.rivian-mcp/session.json Note: Strictly read-only — no vehicle commands or settings changes are supported. Requires Node.js 24+ and a Rivian account with a vehicle.

Which integrations are available for this server?

Interacts with Rivian's undocumented GraphQL API to provide real-time vehicle status, battery and charging data, and software update information.

How do I use Rivian MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Rivian MCP What's my current battery level and estimated range?" 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.

Rivian MCP

by PatrickHeneise

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Rivian MCP

Read-only MCP server and CLI for Rivian's undocumented GraphQL API. Check your vehicle's battery, range, OTA updates, charging status, and more — right from Claude or your terminal.

Strictly read-only — no vehicle commands, no settings changes.

Install as Claude Code Plugin

Install the skill so Claude automatically knows how to work with this codebase and the Rivian API — confirmed vehicle state properties, auth flow, formatter patterns, and what fields don't exist.

From the terminal:

claude /plugin marketplace add PatrickHeneise/rivian-mcp
claude /plugin install rivian-mcp@rivian-ai
claude /plugin install rivian-mcp@rivian-ai

Inside Claude Code, type:

/plugin marketplace add PatrickHeneise/rivian-mcp

Then:

/plugin install rivian-mcp@rivian-ai
/plugin install rivian-mcp@rivian-ai

Related MCP server: Tesla Tessie MCP Server

Setup

claude mcp add rivian \
  -e RIVIAN_EMAIL=your@email.com \
  -e RIVIAN_PASSWORD=your-password \
  -- npx rivian-mcp

Add to ~/.claude.json or your project's .mcp.json:

{
  "mcpServers": {
    "rivian": {
      "command": "npx",
      "args": ["rivian-mcp"],
      "env": {
        "RIVIAN_EMAIL": "your@email.com",
        "RIVIAN_PASSWORD": "your-password"
      }
    }
  }
}

Rivian requires 2FA on every new login:

Ask Claude: "Log in to Rivian"
Rivian sends a verification code to your phone/email
Tell Claude the code: "The code is 123456"

Your session is saved to ~/.rivian-mcp/session.json and reused automatically until it expires (7 days).

What you can ask

"What's my battery level?"
"Is there a software update available?"
"Are all the doors locked?"
"Show me the full vehicle status"
"Who has keys to my R1S?"
"Am I currently charging?"
"Show my charging history"
"What's my charging schedule?"

Tools

Tool	What it does
`rivian_login`	Start sign-in (triggers verification code)
`rivian_submit_otp`	Complete sign-in with the verification code
`rivian_get_user_info`	Your account, vehicles, and software versions
`rivian_get_vehicle_state`	Live status — battery, doors, tires, location, climate, OTA
`rivian_get_ota_status`	Current and available software versions
`rivian_get_charging_session`	Active charging session details
`rivian_get_charging_history`	Past charging sessions — energy, cost, location
`rivian_get_charging_schedule`	Your configured charging schedule
`rivian_get_drivers_and_keys`	Drivers and their phone keys / key fobs

CLI

The package also installs a rivian CLI for quick terminal access without Claude.

npx rivian-mcp ota    # OTA software update status
npx rivian-mcp stats  # Full vehicle state

Or install globally:

npm install -g rivian-mcp
rivian ota
rivian stats

Authentication works the same way — credentials from RIVIAN_EMAIL/RIVIAN_PASSWORD env vars or interactive prompts. Session is shared with the MCP server (~/.rivian-mcp/session.json).

Requirements

Node.js 24+
A Rivian account with a vehicle

Support

If you're thinking about getting a Rivian and don't have a referral yet, here's mine — you'll get benefits on your purchase and it helps support this project:

Get a Rivian R1 with referral benefits

References

Rivian API Docs — community-maintained
rivian-python-client — Python client this is based on
home-assistant-rivian — Home Assistant integration

Available Tools

9 tools

rivian_get_charging_historyB

View past charging sessions — energy, cost, duration, and location for every charge.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations exist, and the description only indicates it is a read operation ('View'). It does not disclose any constraints, authentication needs, data limits, or return structure beyond listing a few fields.

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, front-loaded sentence that efficiently conveys the tool's purpose and output information without redundancy.

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 tool is simple with no parameters, but the lack of an output schema means the agent does not know the exact structure of the returned data. Additionally, there is no guidance on how this tool differs from its siblings. The description is minimally adequate.

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 schema coverage is trivially 100%. The description adds value by listing the returned fields (energy, cost, duration, location), which helps the agent understand what data to expect.

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

Purpose4/5

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

The description clearly states the tool views past charging sessions and lists relevant fields (energy, cost, duration, location). However, it does not explicitly differentiate from similar siblings like rivian_get_charging_session or rivian_get_charging_schedule.

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 its siblings. There is no mention of contexts or alternatives.

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

rivian_get_charging_scheduleA

See your charging schedule — what times and days your vehicle is set to charge.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided, so description must carry the burden. It implies a read-only operation but does not explicitly state no side effects or disclose any behavioral traits like authentication requirements or rate limits. Adequate but minimal.

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

Conciseness5/5

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

Single, clear sentence with no wasted words. Front-loaded with the core action ('See your charging schedule'). Extremely efficient.

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 zero parameters and no output schema, the description is minimal but functional. Lacks usage guidelines and behavioral disclosure, which reduces completeness for a tool with siblings.

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?

No parameters exist, so schema coverage is 100%. Baseline for zero parameters is 4, and description adds no param info, which is appropriate since none are needed.

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

Purpose5/5

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

Description clearly states the tool's purpose: viewing the charging schedule. Uses a specific verb ('see') and resource ('charging schedule'), and distinguishes from siblings like charging history and session 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 on when to use this tool versus alternatives (e.g., rivian_get_charging_history or rivian_get_charging_session). The description does not provide context for selection.

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

rivian_get_charging_sessionA

Check on an active charging session — power, battery level, time remaining, and cost.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries burden. It states it checks an active session, implying it may fail if none active, but does not disclose error handling or authentication needs. Adequate but minimal.

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

Conciseness5/5

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

Single sentence, front-loaded with purpose, concise and to the point. No extraneous information.

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

Completeness4/5

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

Given no parameters and no output schema, the description covers the core functionality and return fields. Could mention potential errors or response format, but sufficient for a simple read 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?

Input schema has zero parameters and 100% coverage, so description need not add parameter info. Baseline score of 4 is appropriate for a parameterless tool.

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 verb 'check' and resource 'active charging session', and lists specific data returned (power, battery level, time remaining, cost). It distinguishes from sibling tools like rivian_get_charging_history by focusing on the active session.

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?

Usage is implied by 'active charging session', but no explicit guidance on when to use alternatives or prerequisites. For a simple read tool, the implication suffices, but explicit context would be helpful.

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

rivian_get_drivers_and_keysA

See who has access to your vehicle — drivers, phone keys, and key fobs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, and the description only implies read-only behavior ('See who has access'). It does not disclose any additional behavioral traits such as authentication requirements, rate limits, or data freshness. Given the low complexity, this is adequate but not enriching.

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

Conciseness5/5

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

The description is a single concise sentence that front-loads the key information. Every word contributes to the purpose, with no unnecessary details.

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

Completeness5/5

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

Given the tool has no parameters and no output schema, the description sufficiently explains what the tool does. It is complete for the user to understand its functionality without ambiguity.

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 the description does not need to add parameter meaning. Per guidelines, 0 parameters warrants a baseline of 4. No additional information is required.

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 explicitly states the tool's purpose: to list drivers and keys with access to the vehicle. It uses a clear verb ('see') and resource, effectively distinguishing it from sibling tools like rivian_get_charging_history or rivian_get_user_info.

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

Usage Guidelines4/5

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

While no explicit when-to-use or when-not-to-use guidance is provided, the simplicity of the tool (no parameters, read-only) and the clear distinction from siblings make the usage context obvious. A score of 4 reflects that guidance is not critical but would be beneficial for clarity.

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

rivian_get_ota_statusA

Check for software updates — what version you're running and whether a new one is available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided. Description indicates a non-destructive 'check' operation, but does not mention authentication requirements or other behavioral traits (e.g., rate limits). For a tool requiring login (sibling rivian_login exists), this is a gap.

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

Conciseness5/5

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

Single sentence, front-loaded with primary action, no extraneous words. Efficient and clear.

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?

No output schema exists. Description hints at return content (version, update availability) but does not specify structure or additional fields. Adequate for a simple tool, but could be more complete.

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

Parameters4/5

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

Input schema has zero parameters, so baseline is 4. Description adds no param info, but none needed since schema coverage is 100%.

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

Purpose5/5

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

Description clearly states the tool checks for software updates, reports current version, and indicates availability of a new one. Distinct from sibling tools (charging, keys, etc.), which are about different vehicle functions.

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

Usage Guidelines3/5

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

No explicit when-to-use or alternatives guidance. Given the tool is a simple status check, the usage context is implied, but no exclusions or sibling comparisons are mentioned.

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

rivian_get_user_infoA

Look up your Rivian account — your vehicles, software versions, and account details.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It describes a read operation ('Look up') and specifies the output includes vehicles, software versions, and account details. No side effects or auth requirements mentioned, but for a simple read tool it's sufficiently transparent.

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

Conciseness5/5

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

The description is a single clear sentence that conveys the tool's purpose and output without extraneous information.

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

Completeness4/5

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

Given zero parameters and no output schema, the description adequately explains the tool's result: vehicles, software versions, and account details. It could be more detailed about structure, but is sufficient for a simple lookup.

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% coverage, so the description need not add parameter info. The description explains what the tool does without parameters, which is appropriate.

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 specifies the tool's purpose: looking up Rivian account details including vehicles, software versions, and account info. This explicitly differentiates it from sibling tools which focus on charging, OTA status, vehicle state, etc.

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

Usage Guidelines4/5

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

The description states the tool is for retrieving account info, which implies when to use it. However, it does not provide explicit when-not-to-use or alternative tool suggestions, though siblings cover distinct functionalities.

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

rivian_get_vehicle_stateA

Check your vehicle's current status — battery, range, doors, windows, tires, location, climate, seat heat/vent, steering wheel heat, software versions, security, trailer status, and more.

ParametersJSON Schema

Name	Required	Description	Default
`properties`	No	Specific properties to check. Leave empty for a full status report.

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided. The description implies a read-only operation by listing status items but does not disclose behavioral traits such as real-time data, authentication needs, or side effects.

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?

A single sentence with a clear verb-object structure. It is front-loaded with 'Check your vehicle's current status' but includes a lengthy list with 'and more' which could be trimmed.

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 description lists many status categories but does not specify the output format (e.g., JSON structure). Given no output schema, the description could be more complete about what the returned data looks like.

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 schema already describes the 'properties' parameter at 100% coverage. The description adds value by enumerating example property categories (battery, range, doors, etc.), which helps the agent understand what can be queried.

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 'Check your vehicle's current status' and lists numerous specific categories like battery, range, doors, etc. It distinguishes from siblings which cover charging, OTA, drivers, etc.

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 when to use (to check vehicle status) but does not explicitly exclude scenarios or mention alternatives like rivian_get_ota_status for software updates.

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

rivian_loginA

Log in to your Rivian account. Rivian will send a verification code to your phone or email — use rivian_submit_otp to complete sign-in.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Given no annotations, the description discloses that Rivian will send a verification code to phone or email, a key side effect. This helps the agent model the tool's behavior beyond just 'login'.

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

Conciseness5/5

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

Two sentences, clean and front-loaded: first sentence states purpose, second provides guidance. No extraneous words.

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 tool with no parameters and no output schema, the description covers the essential context: what the tool does, what happens next, and the role of a sibling tool. It is complete enough.

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 zero parameters, the baseline is 4 per guidelines. The description adds meaning by explaining the login process and the follow-up step, which is more than just restating the name.

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

Purpose5/5

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

The description clearly states it is for logging into a Rivian account, a specific verb-resource pair. It distinguishes itself from sibling tools by naming rivian_submit_otp as the follow-up step, leaving no ambiguity.

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

Usage Guidelines4/5

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

The description explicitly instructs the agent to use rivian_submit_otp after receiving the verification code, providing a clear workflow. It does not mention when not to use it, but for a login initiation tool this is sufficient.

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

rivian_submit_otpA

Complete Rivian sign-in with the verification code sent to your phone or email.

ParametersJSON Schema

Name	Required	Description	Default
`otp_code`	Yes	The verification code

TDQS

A4/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 behavioral traits such as rate limits, code expiration, or consequences of wrong input. It only states the action without side effects.

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, well-structured sentence with no unnecessary words, front-loading the key action and context.

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 OTP submission with one parameter and no output schema, the description is fairly complete. It lacks details on success/failure behavior but is sufficient for basic usage.

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 schema covers 100% of the parameter, and the description adds context that the code is sent to phone/email, clarifying its origin beyond the schema description.

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

Purpose5/5

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

The description clearly states the tool completes Rivian sign-in using a verification code, distinguishing it from rivian_login.

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

Usage Guidelines4/5

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

The description implies usage after receiving the code, and the sibling tool name 'rivian_login' provides context. However, no explicit when-not-to-use or alternative guidance.

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.

6 tool updatesv1.5.4May 4, 2026
- Addedrivian_get_charging_history
- Addedrivian_get_charging_schedule
- Changedrivian_get_charging_session3 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / vehicle_id
```
Removed value: -{
-  "description": "Vehicle ID from your account info",
-  "type": "string"
-}
```
  - removedInput schema / required
```
Removed value: -[
-  "vehicle_id"
-]
```
- Changedrivian_get_drivers_and_keys3 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / vehicle_id
```
Removed value: -{
-  "description": "Vehicle ID from your account info",
-  "type": "string"
-}
```
  - removedInput schema / required
```
Removed value: -[
-  "vehicle_id"
-]
```
- Changedrivian_get_ota_status3 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / vehicle_id
```
Removed value: -{
-  "description": "Vehicle ID from your account info",
-  "type": "string"
-}
```
  - removedInput schema / required
```
Removed value: -[
-  "vehicle_id"
-]
```
- Changedrivian_get_vehicle_state2 fields changed
  - removedInput schema / properties / vehicle_id
```
Removed value: -{
-  "description": "Vehicle ID from your account info",
-  "type": "string"
-}
```
  - removedInput schema / required
```
Removed value: -[
-  "vehicle_id"
-]
```
7 tool updatesv1.0.0Feb 25, 2026
- First observedrivian_get_charging_session
- First observedrivian_get_drivers_and_keys
- First observedrivian_get_ota_status
- First observedrivian_get_user_info
- First observedrivian_get_vehicle_state
- First observedrivian_login
- First observedrivian_submit_otp

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose. The three charging tools are well-differentiated: history for past sessions, schedule for future plans, and session for active charging. No overlap between any tools.

Naming Consistency5/5

All tools follow a consistent pattern: 'rivian_' prefix, with most using 'get_' for read operations, and two auth tools using action verbs. Naming is uniform, snake_case, and predictable.

Tool Count5/5

9 tools is appropriate for a vehicle management server. It covers essential areas (vehicle state, charging, access, updates, account, login) without being excessive or sparse.

Completeness3/5

The tool set is heavily read-only, covering status queries well but lacking write operations like setting charging schedules, locking/unlocking doors, or adjusting climate. This is a notable gap for a vehicle management domain.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

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
WHOOP — MissingMCPOAuth
com.missingmcp
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Health & Wellness Fitness Tracking
24
keithah-tessie-mcp
ai.smithery
Unofficial integration! ## ✨ Key Features ### 💰 Financial Intelligence - **Smart Charging Cost An…
Finance Travel & Transportation App Automation
27
validatethat-mcp
io.github.RyanByrne
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Research & Data Product Management
2

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 a month ago (2026-08-09 13:43 UTC)
5
7
MIT
Tesla Tessie MCP Server
Home Automation & IoT Monitoring
EzeLLM
F
license
Not graded
quality
D
maintenance
Provides access to Tesla vehicle telemetry data via the Tessie API, enabling real-time monitoring of battery status, charging state, climate controls, location, and other vehicle metrics through 30+ tools with intelligent caching.
Updated 7 months ago (2026-01-23 14:12 UTC)
-
Unoffical Polestar 2 MCP
Energy Travel & Transportation
holger1411
A
license
Not graded
quality
D
maintenance
An MCP (Model Context Protocol) server that exposes Polestar 2 vehicle data to AI assistants like Claude. Query your car's battery status, vehicle info, and health data through natural conversation.
Updated 3 months ago (2026-05-31 16:40 UTC)
MIT
TeslaMate MCP Server
Databases Location Services Weather Services
6547709
A
license
Not graded
quality
A
maintenance
Enables reading Tesla vehicle data from a TeslaMate PostgreSQL database, including status, trips, charging, efficiency, weather integration, and more, via 38 tools for MCP-compatible clients like Claude Code.
Updated a month ago (2026-08-04 10:43 UTC)
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/PatrickHeneise/rivian-mcp'

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

Rivian MCP

Install as Claude Code Plugin

Setup

First-time login

What you can ask

Tools

CLI

Requirements

Support

References

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API