Kiaaccess MCP vs MCP Server Airbnb

A side-by-side look at the Kiaaccess MCP and MCP Server Airbnb MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

Kiaaccess MCP logoKiaaccess MCPTravel & Transportation · Local subprocess (stdio)Kia Access for Claude — vehicle status, location, doors, climate, and charging63GoodAuth: otherMCP Server Airbnb logoMCP Server AirbnbTravel & Transportation · Local subprocess (stdio)Provides tools to search Airbnb and get listing details.61GoodAuth: no auth required

Verdict: choose Kiaaccess MCP for travel & transportation work as a local process; choose MCP Server Airbnb 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?

Kiaaccess MCP logoChoose 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.
Explore Kiaaccess MCP

MCP Server Airbnb logoChoose MCP Server Airbnb 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 airbnb_search, airbnb_listing_details.
Explore MCP Server Airbnb

Feature & specification comparison

Rows where the two servers differ are marked.

SpecKiaaccess MCP logoKiaaccess MCPMCP Server Airbnb logoMCP Server Airbnb
CategoryTravel & TransportationTravel & Transportation
Quality signal63/100 · Good61/100 · Good
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Local subprocess (stdio)
AuthotherNo auth required
PricingFreeFree
Required env varsKIA_USERNAMEKIA_PASSWORDNone listed
Verified ownerCommunity listingCommunity listing
GitHub stars0548
Directory activity 1 views 0 installs 0 upvotes 8 views 0 installs 0 upvotes
Tools162

Tools & capabilities

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

MCP Server Airbnb tools 2

  • airbnb_searchSearch for Airbnb listings with comprehensive filtering options.
  • airbnb_listing_detailsGet detailed information about a specific Airbnb listing.

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.

Kiaaccess MCP

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "kiaaccess-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "kiaaccess-mcp"
      ],
      "env": {
        "KIA_USERNAME": "YOUR_KIA_USERNAME_HERE",
        "KIA_PASSWORD": "YOUR_KIA_PASSWORD_HERE"
      }
    }
  }
}

MCP Server Airbnb

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "openbnb-org-mcp-server-airbnb": {
      "command": "npx",
      "args": [
        "-y",
        "@openbnb/mcp-server-airbnb"
      ]
    }
  }
}

Frequently asked questions

Kiaaccess MCP is categorized under Travel & Transportation and uses a local stdio subprocess. MCP Server Airbnb belongs to Travel & Transportation and uses a local stdio subprocess. Pick Kiaaccess MCP for travel & transportation work and MCP Server Airbnb 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.

Kiaaccess MCP is listed as free. Auth: other. MCP Server Airbnb is listed as free. Auth: no auth required. 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 kiaaccess-mcp and openbnb-org-mcp-server-airbnb as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, Kiaaccess MCP has a quality signal of 63/100 (Good) with 1 views, 0 installs and 0 GitHub stars. MCP Server Airbnb has 61/100 (Good) with 8 views, 0 installs and 548 GitHub stars.