weconnect_mvp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP port (default: 8080) | 8080 |
| VW_SPIN | Yes | 4-digit S-PIN | |
| MCP_API_KEY | Yes | Bearer token clients must send for authentication | |
| VW_PASSWORD | Yes | VW WeConnect account password | |
| VW_USERNAME | Yes | VW WeConnect account e-mail | |
| CORS_ORIGINS | No | Comma-separated allowed origins (default: *) | * |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {
"tasks": {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
},
"prompts": {
"get": {}
},
"resources": {
"read": {}
}
}
}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_vehiclesA | List all vehicles paired to the connected Tibber account (VIN, name, model). Read-only discovery step -- call this first to learn which vehicle_id values (VIN or name; names match by case-insensitive substring) the other two tools accept. Results are cached for 5 minutes. An empty result includes a hint explaining that pairing happens in the Tibber app, not through any tool here. A {"error": "server_unavailable", "error_type": ...} response means the server itself needs attention (e.g. re-authorization), not a bad request. |
| get_vehicle_infoA | Get a vehicle's identity plus a quick energy snapshot: manufacturer, model, name, VIN, online/connection state, last-seen timestamp, electric range (km), charging flag, plug-connected flag. vehicle_id accepts a VIN or a partial, case-insensitive name -- the response's own vin/name confirm exactly which vehicle matched. {"error": "..."} means no vehicle matched vehicle_id; {"error": "server_unavailable", "error_type": ...} means the server itself needs attention instead (e.g. re-authorization). Cached for 5 minutes. Read-only -- no vehicle setting can be changed and nothing can be started or stopped. |
| get_charging_statusA | Get charging/plug status for an electric vehicle: whether charging is running right now (is_charging, charging_state), plug-connected flag, target and current state of charge (%), electric range (km), last-seen timestamp -- plus the resolved vehicle's vin/name, since vehicle_id accepts a partial, case-insensitive name. {"error": "..."} means no vehicle matched vehicle_id or it has no charging data; {"error": "server_unavailable", "error_type": ...} means the server itself needs attention instead (e.g. re-authorization). Cached for 5 minutes. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| safe_start_charging | [USABLE with Tibber: read-only check — actually starting the charge is not possible via the Tibber Data API (no write endpoint); the user must do it from the vehicle's own app] Check whether the vehicle is ready to begin charging |
| check_vehicle_health | [USABLE with Tibber: vehicle info, state, and battery status are all supported] Health check with vehicle identity, connection state, and battery status |
| monitor_charging_session | [USABLE with Tibber: read-only status polling — actually stopping charging must be done via the vehicle's own app, since the Tibber Data API has no write endpoint] Monitor charging progress until target SOC is reached |
| charging_schedule_feasibility | [PARTIALLY USABLE with Tibber: charging/battery status works; the vehicle's current location must come from the user since Tibber has no GPS data] Verify if current charging allows meeting user's schedule considering travel time |
| range_anxiety_advisor | [PARTIALLY USABLE with Tibber: battery status works; the vehicle's current location must come from the user since Tibber has no GPS data] Assess range adequacy for planned trip using battery status, route, weather, and charging infrastructure |
| smart_preconditioning_advisor | [PARTIALLY USABLE with Tibber: battery/charging status works; vehicle location must come from the user, and preconditioning itself is advisory only — the Tibber Data API cannot start climate control] Optimize battery preconditioning based on weather, trip requirements, and electricity pricing |
| automated_travel_readiness_check | [PARTIALLY USABLE with Tibber: battery status works; vehicle location must come from the user, and any preparation (climate, door check) is advisory only — Tibber has no door/GPS/climate data or commands] Comprehensive pre-departure check combining vehicle state, weather, traffic, and route conditions |
| intelligent_charging_plan | [PARTIALLY USABLE with Tibber: charging/battery status works; vehicle location must come from the user, and starting/stopping charging is advisory only — Tibber has no write endpoint] Create a cost-optimised charging schedule considering electricity spot prices, weather (cold reduces range), vehicle state, and user calendar. |
| trip_optimizer | [PARTIALLY USABLE with Tibber: energy/range status works; vehicle location must come from the user, and starting charging is advisory only — Tibber has no write endpoint] Optimise departure timing, en-route charging stops, or fuel stops based on user calendar, vehicle range, and live traffic. |
| zone_entry_restriction_check | [PARTIALLY USABLE with Tibber: manufacturer/model and battery status work, but model year (needed for Euro-standard lookup) is unsupported by the read-only Tibber backend] Check whether the vehicle is allowed to enter a destination area considering environmental zones, EV-only zones, and congestion zones. |
| battery_health_optimizer | [PARTIALLY USABLE with Tibber: charging/battery status and model info work (this prompt is advisory-only, no commands needed); vehicle location for the temperature lookup must come from the user since Tibber has no GPS data] Analyse current and ongoing charging behaviour and suggest optimisations to maximise battery longevity: target SOC, charge rate, and schedule. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.