weconnect_mvp
Related Servers
Alternatives to weconnect_mvp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityDmaintenanceAn 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.MIT
- AlicenseAqualityBmaintenanceA Model Context Protocol (MCP) server that connects LLMs to vehicle data via the Eclipse Kuksa Databroker, enabling AI assistants to read and write vehicle signals using the standardized COVESA Vehicle Signal Specification.9Apache 2.0
- AlicenseNot gradedqualityAmaintenanceA Model Context Protocol server for the TeslaFi API that lets MCP clients query live vehicle data, drive and charge history, commute patterns, and optionally send commands.2MIT
- AlicenseAqualityDmaintenanceAn unofficial MCP (Model Context Protocol) server that exposes a Vaillant heat pump's data to AI assistants like Claude. Query outdoor and room temperatures, hot water status, energy consumption, COP estimates, schedules, and diagnostics through natural conversation.4MIT
- AlicenseAqualityBmaintenanceA local-first, read-only MCP server for vehicle diagnostics that exposes structured OBD-II tools for reading PIDs, DTCs, and ECU snapshots without raw protocol access.7Apache 2.0
- AlicenseAqualityAmaintenanceA Model Context Protocol (MCP) server that provides access to your TeslaMate database, allowing AI assistants to query Tesla vehicle data and analytics.18139MIT
TDQS
Scored across 3 tools
get_vehicles is clearly the discovery step, but get_vehicle_info and get_charging_status overlap significantly: both return charging flags, plug status, range, and last-seen data. The extra SoC and charging_state details in get_charging_status help, but an agent could easily pick the wrong one for a status query.
All three tools follow a consistent get_<resource> or get_<resource>_<detail> pattern with lowercase snake_case. The naming makes the data hierarchy clear: vehicles, then vehicle info, then charging status.
Three tools is small but appropriate for a narrow read-only MVP focused on vehicle discovery and status. Each tool has a distinct enough purpose, though the set is minimal and leaves no room for operations beyond reads.
The read-only discovery and status workflow is covered: list vehicles, get vehicle info, get charging status. However, there are no control or management operations, and the overlap between get_vehicle_info and get_charging_status leaves some status capabilities split rather than cleanly layered.