heatpump-mcp
Provides voice-controlled access to a Fujitsu heat pump through the FGLair cloud, allowing users to read status and request confirmed changes to power, mode, temperature, and fan settings.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@heatpump-mcp how warm is it in the living room?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
heatpump-mcp
Voice control for a Fujitsu heat pump through the FGLair cloud, as an MCP server and a claude-voice plugin.
You ask "how warm is it in the living room?", and the voice reads the answer from the heat pump: whether it is on, what it is doing, the temperature it is set to, the room and outdoor temperatures, and the fan.
Try it without a heat pump
The pretend unit touches no network, and every answer says it is simulated:
$ uv run heatpump-mcp status --simulate
Simulated: The heat pump is on, heating to 21 degrees. The room is 20.5 degrees, and it is 3 degrees outside. The fan is on auto.The same tools are served to a voice session over stdio, and the server stops when its input closes:
$ uv run heatpump-mcp serve --simulate < /dev/nullRelated MCP server: mcp-server-tuya
The real heat pump
The real unit is reached through Fujitsu's FGLair cloud, the same way Home Assistant's built-in FGLair integration reaches it (ADR-HM-001). It needs the login of the FGLair app, in two files that only the owner can read:
mkdir -p ~/.config/heatpump-mcp && cd ~/.config/heatpump-mcp
printf '%s' 'the-email-you-sign-in-with' > fglair-username
printf '%s' 'your-fglair-password' > fglair-password
chmod 600 fglair-username fglair-passwordAn optional config.toml beside them holds region (eu, the default;
default for the Americas and elsewhere; or cn) and unit, the unit's
name in the FGLair app, which is needed only when the account has more than
one. A file anyone else can read is refused.
Until the login is there, the server still starts, and every answer says what to set up:
$ uv run heatpump-mcp status --config-dir /nonexistent
The heat pump's login is not set up: Write the FGLair login to /nonexistent/fglair-username, one value per file, then chmod 600 it.With the login in place, uv run heatpump-mcp serve serves the real unit,
and uv run heatpump-mcp status reads it once.
The tools
Tool | What it does |
| Reads the unit, changing nothing. A reading is reused for 30 seconds. |
| Checks one change (power, mode, temperature or fan) and returns a question to read aloud, with a token. Changes nothing. |
| Sends that change, with the token, after the owner's spoken yes, then reads the unit back. |
Every answer has say, a sentence to read aloud as it is, and success,
which a program can read. After a change, success is true only when the
unit, read back, shows it; otherwise say tells the owner it is not
confirmed.
The safety rules
Nothing changes without a question and a spoken yes. A token works for the most recent question only, once, for 30 seconds; a wrong one cancels the question.
Temperatures from 16 to 28 °C only; anything else is refused.
At most one change every 10 seconds.
Only power, mode, temperature and fan. Nothing in the code touches the unit's firmware, Wi-Fi, schedules, timers or the cloud account, and a test refuses any code that so much as names them.
A change that never reached the unit can be confirmed again with the same token while it is fresh; nothing is retried on the plugin's own initiative.
The gates
Every one of these runs in continuous integration, and all of them run here:
$ uv run ruff check .
All checks passed!uv run ruff format --check . # layout
uv run mypy src # types
uv run pytest -q # behaviour
python scripts/mutate.py # that each rule's own test can failCONTRIBUTING.md says what each one is for, and
decisions/ records the choices that shaped them,
including how a change is made here.
Licence
GPL-3.0-or-later. See LICENSE.
Available Tools
3 toolsheatpump_set_confirmA
Make it, after a yes. Send the change asked about. Call only with the token from the most recent heatpump_set_request, and only after the owner has said yes to its question. A wrong or old token is refused and cancels the question. The unit is read back afterwards: success is true only when it shows the change. Read 'say' aloud.
Inputs: token (required). Returns: object
heatpump_set_requestA
Ask before one change. Ask to change one setting: power (on, off), mode (heat, cool, dry, fan, auto), temperature (16 to 28 degrees) or fan (quiet, low, medium, high, auto). Changes nothing. Returns a question ('say') to read to the owner, with a token, or a refusal ('say') to read aloud.
Inputs: value (required), setting (required). Returns: object
heatpump_statusARead-only
Read the unit; no change. Say whether the heat pump is on, its mode (heat, cool, dry, fan, auto), the temperature it is set to, the room and outdoor temperature, and the fan speed. A reading is reused for 30 seconds. Read 'say' aloud.
Inputs: no named parameters. Returns: object
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 3 tools
Each tool has a clearly distinct role: read-only status, request a proposed change with token/question, and confirm execution after a yes. The set_request/set_confirm split is explicitly described and prevents confusion.
All tools share the heatpump_ prefix and readable action-oriented suffixes. The only minor inconsistency is that status is a noun while set_request and set_confirm follow a verb_noun pattern.
Three tools are well-scoped for a narrow heat pump control domain: read status, ask for a change, and confirm it. Each tool earns its place in enforcing a safe two-step change flow.
Core lifecycle coverage is present: read state and change power, mode, temperature, or fan with confirmation. Minor gaps include no explicit cancel tool for a pending request and no way to change multiple settings in one confirmed action.
Maintenance
Related MCP Connectors
Control your Tesla from your AI assistant - climate, charging, access, and security.
Home energy for AI assistants: live Power flow, Energy history, solar forecast, and device control.
Superseded by io.github.f-tiger/hvac-btu-heat-klimaanlage — same server, same URL.
Superseded by io.github.f-tiger/hvac-btu-heat-klimaanlage — same server, same URL.
Related MCP Servers
- AlicenseCqualityDmaintenanceEnables you to manage and automate interactions with Nature Remo devices, including listing devices and appliances, and operating TVs and air conditioners through natural language commands.44 npm8MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to control Tuya/Smart Life smart home devices via tools like on/off, brightness, color, and custom commands.1055 PyPI1MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to control Sonoff smart-home devices through the eWelink Cloud API, with tools for device listing, switching, thermostat control, and sensor data retrieval.1-
- FlicenseNot gradedqualityDmaintenanceEnables LLMs to control Home Assistant devices, including lights, switches, and climate devices, through natural language commands.-