A Model Context Protocol (MCP) server that exposes your TeslaMate database to AI assistants over stdio and streamable HTTP.
TeslaMate MCP presents a well-structured dataset-query server with strong naming conventions, comprehensive descriptions, and proper schema definitions. Tool names uniformly follow verb_noun patterns (get_*, show_*, run_*). All 14 tools have substantive descriptions (avg 150+ chars) that clearly explain WHAT the tool does, WHEN to use it, and any prerequisites. Input schemas are fully defined with type annotations and parameter descriptions. However, there are gaps in output schema documentation (no explicit return type specs visible in most tools), limited error guidance for edge cases, and the write tool lacks confirmation/dry-run safeguards. Tool composition is sound, each tool has one clear responsibility, names are disambiguated (show_charging_curve vs get_charging_curve), and chaining metadata is present (IDs returned for follow-up calls). Security is delegated to database-layer controls; tool-level validation is minimal.
Aggregate charging totals per car: session count, total energy, average session size, and cumulative cost.
Efficiency (as percent of range consumed) bucketed by outside temperature, showing how cold and hot weather affect real-world Wh/km.
Static metadata per car: name, model, trim, color, marketing name, and supercharging eligibility.
Track monthly battery rated-range trends to assess long-term capacity degradation across vehicles.
Latest battery metrics per vehicle: current state of health percentage, usable/ideal/estimated range, and raw battery level.
Charging sessions grouped by geofence, with session count, total kWh, and cost metrics per location.
Output schemas not documented. Tools return data (rows, lists) but no explicit schema is visible for what fields LLMs should expect. This forces LLMs to infer structure from first results, risking misplanning downstream calls.
set_charging_cost is a write tool (WRITE risk) with no confirmation or dry-run support. Description mentions enable_charging_writes=true flag but does not warn agents of irreversibility or advise confirmation patterns. Agents could accidentally overwrite billing data.
run_sql tool description lacks explicit input validation guidance. No mention of which SQL keywords are blocked, what statement timeout is applied, or how the LIMIT injection works. This creates ambiguity for agents attempting complex queries.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 74 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 15 | - | v1 |
Retrieve charging session data with timestamps, battery levels, and power readings for visualization or analysis.
Explore the TeslaMate database schema. Without arguments: a compact list of every table with its column count. With `table`: full column detail (name, data type, nullability, position) for that table. Use this to discover available columns before writing custom SQL with `run_sql`. Pass refresh=true to re-read the schema after DDL changes.
Retrieve GPS coordinates and telemetry (speed, battery, power) sampled along a drive's route for mapping and analysis.
Execute custom SQL queries against the TeslaMate database with read-only protections, statement timeouts, and automatic LIMIT injection.
Update the cost of a completed charging session (requires enable_charging_writes=true and database UPDATE grant on charging_processes.cost).
Render an interactive battery-degradation trend chart, displayed directly in the conversation (monthly average and best rated range at full charge, one line per car, with hover readouts and a data table). Returns the same rows as get_battery_degradation_over_time, so it also works as a plain data tool. Prefer this over get_battery_degradation_over_time when the user wants to SEE the trend.
Render an interactive charging-curve chart for one charging session, displayed directly in the conversation (battery level and charging power over time, with hover readouts and a data table). Returns the same rows as get_charging_curve, so it also works as a plain data tool. Prefer this over get_charging_curve when the user wants to SEE the curve. Find session ids with search_charging_sessions.
Render an interactive route map for one drive, displayed directly in the conversation (the GPS track with start/end markers, hover readouts for time, speed, and battery, and a waypoint table). Returns the same rows as get_drive_route, so it also works as a plain data tool. Prefer this over get_drive_route when the user wants to SEE the route. Find drive ids with search_drives.
Error handling and recovery guidance absent from tool descriptions. If get_database_schema or run_sql fails, agents have no direction on what to try next (retry, check connection, list tables first, etc.).
show_* tools return raw data rows in addition to rendering charts. Description states 'Returns the same rows as get_*' but does not clarify whether the response is the chart HTML, the data, or both. Ambiguous response structure.
get_database_schema refresh parameter and run_sql timeout behavior not visible in code snippet. Cannot verify whether these produce user-facing errors with actionable next steps or raw exceptions.