heatpump-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
SIMULATED: this is a pretend heat pump, not a real one. Say so when you report on it. Controls the owner's heat pump through the Fujitsu cloud. Every answer has 'say': read it aloud as it is. heatpump_status tells whether it is on, its mode, the temperature it is set to, the room and outdoor temperature, and the fan. Never change anything without asking: for a change, call heatpump_set_request, read its 'say' question to the owner exactly, and call heatpump_set_confirm with its token only if the owner clearly answers yes. If they say anything else, do not confirm. One change per request; never ask again while a question is open. Temperatures from 16 to 28 degrees only, and at most one change every 10 seconds. Read every refusal and result aloud; 'not confirmed' means the unit did not show the change when read back.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| heatpump_statusA | 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. |
| 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. |
| heatpump_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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.