Bart vs Kiaaccess MCP
A side-by-side look at the Bart and Kiaaccess MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Bart for travel & transportation work as a local process; choose Kiaaccess MCP for travel & transportation as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Bart when
- You need dedicated capabilities in the Travel & Transportation domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
bart_departures, bart_stations, bart_trip_planner.
Choose Kiaaccess MCP when
- You need dedicated capabilities in the Travel & Transportation domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: other.
- You have the keys it needs:
KIA_USERNAME, KIA_PASSWORD. - You want tools like
kia_healthcheck, kia_session_status, kia_start_login.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Travel & Transportation | Travel & Transportation |
| Quality signal | 52/100 · Good | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | No auth required | other |
| Pricing | Free | Free |
| Required env vars | None listed | KIA_USERNAMEKIA_PASSWORD |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 0 |
| Directory activity | 2 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 4 | 16 |
| Full listing | View Bart | View Kiaaccess MCP |
Tools & capabilities
Bart tools 4
bart_departuresReal-time BART San Francisco Bay Area train departures for a station — next train departure times in minutes, per destination, with platform, direction, train length (cars), line color, delay, and bikes allowed. Station accepts a 4-letter BART code ("EMBR", "SFIA") or a station name ("Embarcadero",…bart_stationsList all 50 BART San Francisco Bay Area train stations with 4-letter code, full name, city, street address, and coordinates. Optional filter matches station name or city (e.g. "Oakland", "Berkeley", "airport"). Use to find the station code for departures, trips, or fares. Example: bart_stations({ f…bart_trip_plannerPlan a BART trip between two Bay Area stations — the next trains from origin to destination with departure and arrival times, trip duration, legs (line, transfer stations, bikes), and the fare (Clipper and discount prices). Covers trips like SF to Oakland, Embarcadero to SFO airport, Berkeley to Mi…bart_advisoriesCurrent BART service advisories and delays for the San Francisco Bay Area train system, plus elevator outage status at stations. Answers "is BART delayed right now", "are there BART service alerts", "which BART elevators are out". Example: bart_advisories({})
Kiaaccess MCP tools 16
kia_healthcheckResolves the credential the way real tools do, then makes one authenticated request to Kia Connect. Reports which source supplied the credential, whether Kia Connect accepted it, the round-trip time, and a plain-English hint distinguishing 'no credential' from 'credential rejected' from 'a Kia Connect-side problem'. Read-only; never returns the credential itself. Call this when a real tool fails and you want to know which hop broke.kia_session_statusWhether this server is configured and logged in to Kia: are credentials present, has the one-time MFA bootstrap been completed on this device, and which vehicle commands are registered (KIA_WRITE_MODE). Makes NO network call and returns no secret — the account email is masked, the device id is truncated, and neither the session id nor the remember-me token is ever included. Start here when a Kia tool reports it is not configured.kia_start_loginStep 1 of the ONE-TIME Kia MFA bootstrap (prof/authUser): send the configured credentials and get back the `otpKey` and `xid` the next two steps need. Only needed when kia_session_status reports hasSession:false — once the bootstrap is done the stored remember-me token refreshes sessions silently forever. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call makes NO network call and returns a preview plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). The gate is real: Kia counts failed logins and eventually enforces reCAPTCHA, which breaks server-side login for this account PERMANENTLY — so a rejection is never retried, and a wrong password must be fixed in the environment rather than guessed at.kia_send_otpStep 2 of the Kia MFA bootstrap (cmm/sendOTP): deliver a one-time passcode to the account by SMS or email. Takes the `otpKey` and `xid` from kia_start_login — it cannot run without them, which is why it has no separate confirmation gate. Ask the user which channel they want (kia_start_login reports the masked destinations Kia has on file). The passcode expires in about two minutes; `expiresAt` reports when.kia_verify_otpStep 3 of the Kia MFA bootstrap (cmm/verifyOTP): exchange the passcode for a session. The resulting remember-me token is stored locally and is NOT returned — from here on every Kia tool refreshes its own session silently and MFA is never needed again on this device. Takes the `otpKey` and `xid` from kia_start_login plus the code the user received.kia_forget_sessionDiscard the locally stored Kia session (the remember-me token), so the next Kia call needs the one-time MFA bootstrap again. This is the recovery path when the stored token no longer works — Kia revoked it, the password changed, or the account moved to another device — and the only alternative is deleting the session file by hand. It makes NO network call: Kia is not told anything, only this machine forgets. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call makes NO network call and returns a preview plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Nothing is deleted until it is confirmed.kia_list_vehiclesList the vehicles enrolled on this Kia Owners account (ownr/gvl). Returns each vehicleKey — the id every other Kia tool takes — plus nickname, model year/name/trim, mileage, fuel type and telematics unit. VINs are masked to their last 6 characters.kia_vehicle_statusRead the vehicle's CACHED status (cmm/gvi): door lock, ignition, and the remote-climate block. Fast, but it reports whatever the telematics unit last uploaded — use kia_refresh_status first when freshness matters. Requested with airTempRange/seatHeatCoolOption = "1" so the nested `climate` object is present; when it is still absent the result says so rather than reporting climate as off. Note `ign3` (not `engine`) is the ignition on an EV, and `syncDate` advances on every read, so it never proves anything changed. Per-seat heat/vent state is reported under `climate.seats` as the RAW numbers Kia sends: the `heatVentType`/`heatVentLevel` encoding is UNVERIFIED, so do not tell the user a seat is heating, ventilating or off based on them. An absent seat block means this read carried no seat data — it does NOT mean the car lacks heated seats, which this server cannot currently determine. Pass include_raw for the untrimmed status block (battery/EV detail, doors, tyres, …).kia_refresh_statusAsk the car for a fresh reading (rems/rvs, requestType 0). This WAKES THE TELEMATICS UNIT, so it is much slower than kia_vehicle_status and draws a little power — prefer the cached read unless staleness matters. Kia only acknowledges the request; it does not return the new data and gives no completion signal, so read kia_vehicle_status afterwards to see the refreshed values.kia_vehicle_locationThe vehicle's last known location, from the `location` block of the cached cmm/gvi read. This is where the telematics unit last reported being, not a live GPS fix — run kia_refresh_status first for a recent one. Latitude/longitude and a map link are derived when the block carries `coord.lat`/`coord.lon`; otherwise the raw block is returned as-is (its exact field names are not verified).kia_start_climateStart remote climate control / preconditioning (Kia `rems/start`, live-verified). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call makes NO network call and returns a preview plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Once confirmed it sends the command and re-reads cmm/gvi until the NESTED `climate.airCtrl` reads true (there is no flat `airCtrlOn` field). On an EV `engine` stays false while climate runs — `ign3` is the ignition proxy and is reported alongside. `commandAccepted` (Kia took the request) and `stateConfirmed` (the car actually reads running) are separate; state changes were observed to take 30–60s. TEMPERATURE IS BEST-EFFORT AND UNCONFIRMED: per docs/KIA-API.md a start requesting 70°F still read back 72°F, so the car may report its own last-set target rather than the requested one — do not promise the user a specific cabin temperature. Seat and steering-wheel/rear-window heating are not sent at all: the request body deliberately omits `heatVentSeat` (Kia validates seat capability per car) and leaves every `heatingAccessory` field at 0.kia_stop_climateStop remote climate control (Kia `rems/stop`, live-verified). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call makes NO network call and returns a preview plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Once confirmed it sends the command and re-reads cmm/gvi until the NESTED `climate.airCtrl` reads false (there is no flat `airCtrlOn` field); `ign3` — the EV ignition proxy — is reported alongside. `commandAccepted` (Kia took the request) and `stateConfirmed` (the car actually reads stopped) are separate. State changes were observed to take 30–60s.- +4 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Bart
{
"mcpServers": {
"bart": {
"command": "npx",
"args": [
"-y",
"@pipeworx/mcp-bart"
]
}
}
}
Kiaaccess MCP
{
"mcpServers": {
"kiaaccess-mcp": {
"command": "npx",
"args": [
"-y",
"kiaaccess-mcp"
],
"env": {
"KIA_USERNAME": "YOUR_KIA_USERNAME_HERE",
"KIA_PASSWORD": "YOUR_KIA_PASSWORD_HERE"
}
}
}
}
Frequently asked questions
Bart is categorized under Travel & Transportation and uses a local stdio subprocess. Kiaaccess MCP belongs to Travel & Transportation and uses a local stdio subprocess. Pick Bart for travel & transportation work and Kiaaccess MCP for travel & transportation.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Bart is listed as free. Auth: no auth required. Kiaaccess MCP is listed as free. Auth: other. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add bart and kiaaccess-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Bart has a quality signal of 52/100 (Good) with 2 views, 0 installs and 0 GitHub stars. Kiaaccess MCP has 63/100 (Good) with 1 views, 0 installs and 0 GitHub stars.