Toyota & Lexus
PYPI · TOYOTA-MCP · SCANNED SEP 20
Toyota & Lexus vehicles: fuel, range, location, trips, health, climate, charging, commands
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security49
- Malware scan not yet available for this package.Unverified
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 9 of 65 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency32
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: no license is declared. See how to fix → Fail
- Actively maintained (last published 2 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability90
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Tool/resource definitions use about 2136 tokens (~82/item across 26 items; 26 tools + 0 resources), lean.Pass
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management73
- Stability observed for 22 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 27 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
How do I install the Toyota & Lexus MCP server?
Toyota & Lexus runs locally as a PyPI package, launched with uvx toyota-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · toyota-mcp
claude mcp add zepgram-toyota -- uvx toyota-mcp
{
"mcpServers": {
"zepgram-toyota": {
"command": "uvx",
"args": [
"toyota-mcp"
]
}
}
} {
"servers": {
"zepgram-toyota": {
"command": "uvx",
"args": [
"toyota-mcp"
]
}
}
} codex mcp add zepgram-toyota -- uvx toyota-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"zepgram-toyota": {
"type": "local",
"command": [
"uvx",
"toyota-mcp"
],
"enabled": true
}
}
} openclaw mcp add zepgram-toyota --command uvx --arg toyota-mcp
mcp_servers:
zepgram-toyota:
command: "uvx"
args: ["toyota-mcp"] {
"McpServers": {
"zepgram-toyota": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"toyota-mcp"
]
}
}
} assistant mcp add zepgram-toyota -t stdio -c uvx -a toyota-mcp
{
"mcpServers": {
"zepgram-toyota": {
"command": "uvx",
"args": [
"toyota-mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 70 to 73. That category is still filling its 30-day observation window: 21 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.
- 18 Sept 26 +1
- Package version: 0.3.4 → 0.3.5 functional
- 16 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.
- 15 Sept 26 −15
- Malware scan: pass → unverified ▼ security
- 14 Sept 26 +16
- Malware scan: unverified → pass ▲ security
- 12 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.
- 10 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.
- 7 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Analysed pypi/toyota-mcp@0.3.5
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 65 packages
| Packages resolved | 65 |
|---|---|
| Stale | 8 |
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
toyota_charge_now Start charging now ~91
Start charging the plug-in battery immediately, ahead of any schedule. Plug-in hybrids and electric vehicles only; the car must be plugged in. Only when the user explicitly asked; preview with confirm=false when in doubt. Verified against the charging state the car reports.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | true sends the command to the car; false (default) only previews what would happen and sends nothing. |
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
toyota_close_windows Close the windows ~67
Close all power windows, then verify against the state the car reports. Not every model supports it; Toyota answers 'vehicle not supported' when not.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | true sends the command to the car; false (default) only previews what would happen and sends nothing. |
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
toyota_find_car Flash the hazard lights ~59
Flash the hazard lights briefly so the user can spot the car — silent. Verified by the car reporting back.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | true sends the command to the car; false (default) only previews what would happen and sends nothing. |
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
toyota_find_fuel_stations Cheapest fuel stations near the car ~119
Cheapest stations selling a given fuel around the car's last parked position. Use for: where can I fill up cheaply near the car? France only: prices come from the French government open-data feed and need the server started with --addresses fr.
| Name | Type | Req | Description |
|---|---|---|---|
| fuel | string | – | Fuel to price: e10, sp95, sp98, e85, gazole (diesel) or gplc. |
| limit | integer | – | Number of stations. |
| radius_km | integer | – | Search radius in km. |
| Name | Type | Req | Description |
|---|---|---|---|
| around | – | yes | The car's last parked position. |
| freshness | – | yes | – |
| fuel | string | yes | – |
| note | string | yes | – |
| radius_km | integer | yes | – |
| stations | array | yes | Cheapest first. |
No examples provided.
toyota_get_charging Charging state and schedules ~78
Plug-in battery: charge level, charging status, EV range, time to full, schedules. Use for: is it charging? how much EV range? when is the next scheduled charge? Plug-in hybrids and electric vehicles only — other powertrains get an explicit "not applicable" error (use toyota_get_energy).
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| battery_level_percent | – | yes | – |
| can_set_next_charging_event | – | yes | – |
| charging_status | – | yes | Raw Toyota status, e.g. 'none', 'charging'. |
| ev_range | – | yes | – |
| ev_range_with_ac | – | yes | – |
| freshness | – | yes | – |
| fuel_level_percent | – | – | Plug-in hybrids only. |
| next_charging_event | – | – | Type and time of the next scheduled charging event. |
| next_scheduled_window | – | – | Next active schedule window (start → end), if any. |
| note | string | yes | – |
| powertrain | string | yes | – |
| remaining_charge_minutes | – | – | Minutes until fully charged, when charging. |
| schedules | array | yes | – |
No examples provided.
toyota_get_climate Remote climate state and preset ~83
Remote pre-conditioning state (running or stopped, temperatures) and the saved preset a remote start would apply (target temperature, duration, defrosters, heated seats). Use for: is the climate running? what temperature is the preset? Starting or stopping it is done with toyota_start_climate / toyota_stop_climate when remote commands are enabled.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| current_temperature | – | yes | – |
| duration_minutes | – | – | Programmed run time of the current session. |
| freshness | – | yes | – |
| is_on | – | yes | – |
| note | string | yes | – |
| preset | – | yes | What a remote start would apply. |
| started_at | – | yes | – |
| status | – | yes | Raw Toyota state, e.g. 'stopped', 'running'. |
| target_temperature | – | yes | – |
No examples provided.
toyota_get_energy Fuel, range and battery ~69
Remaining fuel, driving range and (when applicable) battery state. Use for: how much range is left? how full is the tank? is it charging? On self-charging full hybrids Toyota exposes no battery data — the response says so explicitly in battery_note instead of returning nulls.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| battery | – | – | Plug-in battery state; only for PHEV/EV powertrains. |
| battery_note | – | – | Why battery data is absent, when it is. |
| freshness | – | yes | – |
| fuel_level_percent | – | – | Fuel tank level, percent. |
| fuel_range | – | – | Range on fuel alone. |
| powertrain | string | yes | – |
| total_range | – | – | Total remaining range reported by the car. |
No examples provided.
toyota_get_health Vehicle health and maintenance ~50
Warning lights, oil indicators, recent notifications and the service history. Use for: any alerts on the car? when was it last serviced? Toyota exposes service history, not upcoming maintenance deadlines.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| engine_oil_indicators | array | yes | Raw oil-quantity indicators reported by the car; empty means nothing flagged. |
| freshness | – | yes | – |
| last_service | – | yes | – |
| notifications | array | yes | Latest 10, newest first. |
| service_history | array | yes | All recorded services, newest first. |
| service_note | string | yes | – |
| warning_lights | array | yes | – |
| warning_lights_caveat | string | yes | – |
No examples provided.
toyota_get_last_trip Last trip details ~57
Most recent trip: distance, duration, consumption, hybrid mode split, places. Use for: how was the last trip? what did the last drive consume? Start/end addresses need the server started with --addresses osm or fr.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| freshness | – | yes | – |
| trip | – | yes | – |
No examples provided.
toyota_get_location Last parked position ~77
Last parked position of the vehicle: coordinates, Google Maps link, address. Use for: where is the car? The address needs the server started with --addresses osm or fr. The position updates only when the car parks — while driving it shows the last parking spot; cite freshness.vehicle_reported_at when answering.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| address | – | – | Postal address; needs --addresses osm or fr. |
| freshness | – | yes | – |
| google_maps_url | string | yes | – |
| latitude | number | yes | – |
| longitude | number | yes | – |
| place | – | – | Named place from --places within 200 m, e.g. 'home'. |
| place_label | – | – | Toyota's place name, if any. |
No examples provided.
toyota_get_odometer Odometer reading ~31
Total distance on the odometer. Use for: how many kilometers/miles are on the car?
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| freshness | – | yes | – |
| odometer | – | yes | – |
No examples provided.
toyota_get_status Vehicle doors, windows and locks ~93
Doors, windows, trunk, hood, lock state, lights and rear-seat reminder. Use for: is the car locked? are windows or doors open? did I leave the lights on? Lock state is pushed by the car when parked and can lag — always cite freshness.vehicle_reported_at when answering. Warning lights are NOT here; use toyota_get_health for alerts and maintenance.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| all_locked | string | yes | 'locked' if every reporting door is locked, 'unlocked' if any reporting door is unlocked, 'unknown' if no door reported a lock state. |
| doors | – | yes | – |
| freshness | – | yes | – |
| hood | string | yes | – |
| lights | – | – | Hazard, tail and head lights — 'on' means left on while parked. |
| overall_status | – | – | Toyota's aggregate verdict for the car, e.g. 'ok'. |
| rear_seat_reminder | – | – | – |
| warning_count | – | – | – |
| windows | – | yes | – |
No examples provided.
toyota_get_trip_summary Driving statistics over a period ~125
Aggregated driving statistics over a rolling window or a calendar period. Use for: average consumption over the last 7 days, EV-mode share this month, total distance this year. Consumption is recomputed over the whole window (total fuel vs total distance), not a mean of daily means. Pass period to match the app's calendar figures.
| Name | Type | Req | Description |
|---|---|---|---|
| days | integer | – | Calendar days to cover, ending today (inclusive). |
| period | – | – | Calendar period as shown in the MyToyota app (today, this_week, this_month, this_year); overrides days. |
| Name | Type | Req | Description |
|---|---|---|---|
| average_consumption | – | – | Recomputed over the whole window (total fuel vs total distance). |
| average_speed | – | – | – |
| countries | array | yes | ISO 3166-1 alpha-2 codes of countries driven in. |
| days_with_driving | integer | yes | – |
| ev_distance | – | yes | – |
| ev_duration_hours | – | – | – |
| ev_ratio_percent | – | – | Share of the distance driven in electric mode. |
| ev_time_ratio_percent | – | – | Share of the driving time spent in electric mode. |
| freshness | – | yes | – |
| fuel_consumed | – | yes | – |
| note | – | – | Set when the window contains no trips. |
| period | – | – | Set when the window is a calendar period (as in the app). |
| total_distance | – | yes | – |
| total_duration_hours | number | yes | – |
| window_from | string | yes | – |
| window_to | string | yes | – |
No examples provided.
toyota_get_trips Recent trips ~92
Individual trips over a recent window, newest first. Use for: list this week's trips, when did the car last drive? For averages over a period, prefer toyota_get_trip_summary. For windows beyond 92 days, use toyota_get_trip_summary.
| Name | Type | Req | Description |
|---|---|---|---|
| days | integer | – | Calendar days to cover, ending today (inclusive). |
| limit | integer | – | Maximum number of trips to return. |
| Name | Type | Req | Description |
|---|---|---|---|
| freshness | – | yes | – |
| note | – | – | Set when the window is empty or the list was truncated by limit. |
| retention_note | string | yes | – |
| returned_count | integer | yes | – |
| total_in_window | integer | yes | Trips recorded in the window before applying limit. |
| trips | array | yes | Newest first. |
| window_from | string | yes | – |
| window_to | string | yes | – |
No examples provided.
toyota_get_vehicle_info Vehicle identity and capabilities ~77
Model, year, plate, colour, first-use date, connected-services subscriptions and which remote capabilities Toyota declares for this car. Use for: what car is this? when was it registered? is the connected subscription still active? can it be locked remotely? Capability flags are indicative only — see remote_capabilities.note.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| alias | – | yes | – |
| colour | – | yes | – |
| connected_services_status | – | yes | – |
| date_of_first_use | – | yes | – |
| fuel_type_code | – | yes | Raw Toyota code, e.g. 'B' for petrol. |
| image_url | – | yes | – |
| manufactured_on | – | yes | – |
| model | – | yes | – |
| model_year | – | yes | – |
| powertrain | string | yes | – |
| registration_number | – | yes | – |
| remote_capabilities | – | yes | – |
| remote_services_status | – | yes | – |
| subscriptions | array | yes | – |
| vin_suffix | string | yes | Last four characters of the VIN. |
No examples provided.
toyota_list_vehicles Vehicles on the account ~44
Every vehicle on the connected account, and which one the tools act on. Use for: which cars can I ask about? Choosing one is toyota_select_vehicle.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| note | – | – | – |
| selected | – | yes | vin_suffix of the vehicle the tools act on. |
| vehicles | array | yes | – |
No examples provided.
toyota_lock_doors Lock the doors ~82
Lock the doors, then verify against the state the car reports. Only when the user explicitly asked to lock the car. Call with confirm=false first when in doubt; the report says whether the car confirmed the new state.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | true sends the command to the car; false (default) only previews what would happen and sends nothing. |
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
toyota_lock_trunk Lock the trunk ~52
Lock the trunk only, then verify against the state the car reports.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | true sends the command to the car; false (default) only previews what would happen and sends nothing. |
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
toyota_refresh_data Refresh vehicle data ~76
Re-fetch status, telemetry and location from Toyota's cloud. Rarely needed — the car pushes new data only at ignition-off, so answers refresh themselves as the car is driven. Use only when the user just parked and wants the very latest position or status. This reads Toyota's cloud; it never wakes the car.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| freshness | – | yes | – |
| note | string | yes | – |
| refreshed | boolean | yes | – |
No examples provided.
toyota_select_vehicle Choose the vehicle to act on ~63
Point every other tool at one vehicle of the account, and remember it. Use when the account holds several vehicles, or to switch between them.
| Name | Type | Req | Description |
|---|---|---|---|
| vin | string | yes | VIN of the vehicle, or the last four characters shown by toyota_list_vehicles. |
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | – |
| note | string | yes | – |
| powertrain | string | yes | – |
| vin_suffix | string | yes | – |
No examples provided.
toyota_sound_horn Sound the horn briefly ~73
Sound a short horn signal to locate the car — audible to everyone around it; prefer toyota_find_car unless the user asked for sound. Verified by the car reporting back.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | true sends the command to the car; false (default) only previews what would happen and sends nothing. |
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
toyota_start_climate Start remote climate ~116
Start remote pre-conditioning with the saved preset (duration, defrosters, seats). On a hybrid this runs the engine — never start it in an enclosed space. Only when the user explicitly asked; preview with confirm=false unless the user already confirmed. Verified against the climate state the car reports.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | true sends the command to the car; false (default) only previews what would happen and sends nothing. |
| temperature_celsius | – | – | Target cabin temperature; defaults to the saved preset. |
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
toyota_stop_climate Stop remote climate ~68
Stop remote pre-conditioning, then verify against the climate state the car reports. Only when the user explicitly asked; preview with confirm=false when in doubt.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | true sends the command to the car; false (default) only previews what would happen and sends nothing. |
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
toyota_unlock_doors Unlock the doors ~84
Unlock the doors, then verify against the state the car reports. Security-sensitive: only when the user explicitly asked to unlock the car in this conversation, never on your own initiative. Preview with confirm=false unless the user already confirmed.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | true sends the command to the car; false (default) only previews what would happen and sends nothing. |
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
toyota_unlock_trunk Unlock the trunk ~73
Unlock the trunk only (doors stay locked), then verify against the state the car reports. Only on the user's explicit request; preview with confirm=false unless the user already confirmed.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | true sends the command to the car; false (default) only previews what would happen and sends nothing. |
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
toyota_wake_vehicle Wake the car and re-read its state ~87
Ask the car to report its current state right now, then re-read doors and climate. The passive reads only see what the car pushed when it parked; this sends the same wake request the MyToyota app uses. It costs the car a little 12 V battery and cellular time — use it when the user needs the state as of now, not routinely.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| charging | – | – | – |
| climate | – | – | – |
| command | string | yes | – |
| detail | string | yes | – |
| doors | – | – | – |
| elapsed_seconds | – | – | – |
| status | string | yes | 'needs_confirmation' = nothing was sent; 'verified' = the car reported the new state; 'accepted' = Toyota accepted the command but the car has not confirmed it yet; 'failed' = the car rejected it. |
No examples provided.
What is the Toyota & Lexus MCP server?
Toyota & Lexus is an MCP server listed in the public MCP registry as io.github.zepgram/toyota. Toyota & Lexus vehicles: fuel, range, location, trips, health, climate, charging, commands. This page covers its PyPI package (toyota-mcp).
Is the Toyota & Lexus MCP server safe to use?
Toyota & Lexus scores 66 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Toyota & Lexus MCP server expose?
Toyota & Lexus exposes 26 tools: toyota_list_vehicles, toyota_select_vehicle, toyota_get_vehicle_info, toyota_get_status, toyota_get_energy, and 21 more. Their descriptions and schemas cost roughly 1,986 tokens of context every time the server is loaded.
Is the Toyota & Lexus MCP server still maintained?
Toyota & Lexus is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.