Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
BLUELINK_PINNoYour Bluelink PIN. Europe needs it for remote commands.
MCP_HTTP_HOSTNoHTTP listen address127.0.0.1
MCP_HTTP_PORTNoHTTP listen port8080
MCP_TRANSPORTNostdio or http (http in Docker)stdio
BLUELINK_BRANDNoBrand: hyundai, kia, genesishyundai
MCP_AUTH_TOKENNoBearer token clients must send. Required for http.
BLUELINK_REGIONNoRegion: europe, europe-cci, usa, canada, australia, nz, india, china, brazileurope
BLUELINK_GEOCODENoAdd a street address to the location via OpenStreetMapfalse
BLUELINK_LANGUAGENoResponse language (Europe)en
BLUELINK_PASSWORDYesYour Bluelink app login (required)
BLUELINK_USERNAMEYesYour Bluelink app login (required)
MCP_ALLOWED_HOSTSNoOptional Host header allow-list for DNS rebinding protection
BLUELINK_TOKEN_FILENoLogin token cache. Set it empty to turn caching off. In Docker: /data/token.json~/.local/state/bluelink-mcp/token.json
BLUELINK_ALLOW_UNLOCKNoAlso register unlock_vehicle (needs writes)false
BLUELINK_ALLOW_WRITESNoRegister the command toolsfalse
BLUELINK_CACHE_SECONDSNoHow long a status read is reused60
BLUELINK_MIN_REFRESH_MINUTESNoMinimum gap between refresh_vehicle_status calls per car10

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_vehiclesA

List the vehicles on the account.

get_vehicle_statusA

Get the car's last reported state: battery and fuel, range, charging, climate, locks, doors, windows, tyres, warnings and charging schedule. Does not wake the car.

refresh_vehicle_statusA

Wake the car and fetch live state, then return it like get_vehicle_status. Uses a little 12V battery and API quota, so it is rate limited.

get_tripsA

Get driving history: trips for a day, or a month's summary with trip counts per day. Not every region supports this (Europe does).

get_energy_usageA

Get daily electric energy use (Wh) split into driving, climate, electronics and battery care, plus regenerated energy and distance. EVs and PHEVs in some regions.

get_command_statusA

Check whether an earlier remote command succeeded (pending, success, failed, timeout).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 6 tools

Disambiguation4/5

The main overlap is between refresh_vehicle_status and get_vehicle_status, but the descriptions explicitly distinguish them (wake vs. cached read), so an agent can choose correctly. All other tools target distinct data (commands, energy, trips, vehicle list).

Naming Consistency5/5

All six tools follow a consistent verb_noun snake_case pattern (get_*, list_*, refresh_*), with no mixing of conventions. get_trips is a minor stylistic deviation but still fits the pattern.

Tool Count5/5

Six tools is well-scoped for a read-oriented vehicle status server, with each tool covering a distinct data domain (status, commands, energy, trips, account). No filler or redundant tools.

Completeness3/5

get_command_status implies remote commands exist, yet there is no tool to issue commands (lock, start climate, charge), creating a dead end. Core read coverage (status, energy, trips, vehicles) is solid, but the command lifecycle is one-sided.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues