Skip to main content
Glama
thermoslop

thermoslop

by martellj

set_comfort

Idempotent

Hold a home, away, or sleep comfort preset on specified thermostats or an entire house until the schedule resumes, and report whether the setting took effect.

Instructions

Hold a comfort setting until resume_schedule. With house, applies to every thermostat there, each reported on its own (error for one that failed). Reports whether it took effect: some models (ecobee3 lite) ignore it. The comfort setting's temperatures are the thermostat's own presets, which this server's setpoint limits don't cover.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "comfort": "<comfort>"
    },
    "name": "set_comfort"
  }
}

Input Schema

NameRequiredDescriptionDefault
houseNoOnly thermostats in this house, e.g. 'cabin'.
comfortYes
thermostatNoThermostat alias or name prefix, e.g. 'upstairs'. See list_thermostats.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare safe/idempotent/non-destructive, yet the description adds real behavioral detail: per-thermostat independent reporting with per-device errors, the caveat that some models (ecobee3 lite) silently ignore the call and the tool reports whether it took effect, and that comfort presets bypass this server's setpoint limits. That is precisely the context annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and termination condition, then layers scope, error semantics, and caveats in descending order of importance. Dense but every clause carries actionable information; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description correctly skips explaining return values while still warning about the silent-ignore case and per-thermostat errors. The only gap is how `house` and `thermostat` combine when both are supplied, which neither schema nor description addresses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, and the description compensates by explaining what `house` actually does (fan-out across every thermostat, individual error reporting) and by giving the `comfort` enum real meaning as the thermostat's built-in presets outside the server's setpoint limits. Only the `thermostat` parameter and the house/thermostat interaction are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('hold a comfort setting') and an explicit termination condition ('until resume_schedule'), which cleanly separates it from set_temperature and resume_schedule. The scope modifier ('With `house`, applies to every thermostat there') further pins down what the operation entails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'until resume_schedule' phrasing makes the temporary-override use case clear and implicitly routes the agent to resume_schedule to undo it. It doesn't explicitly contrast with set_temperature or state preconditions, but the context is unambiguous for a sibling-aware agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.