Skip to main content
Glama
Sign In
thermoslop

thermoslop

by martellj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

resume_schedule

Idempotent

Clear setpoint or comfort holds and return thermostats to their built-in schedule, for a single thermostat or every thermostat in a house.

Instructions

Clear holds (setpoint or comfort) and return to the thermostat's schedule. With house, applies to every thermostat there, each reported on its own. The schedule's temperatures are the thermostat's own, which this server's setpoint limits don't cover.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "resume_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
houseNoOnly thermostats in this house, e.g. 'cabin'.
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.2/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, idempotent, non-destructive mutation. The description adds meaningful context beyond that: it says what gets cleared (setpoint or comfort holds), explains house-level fan-out reporting, and clarifies that schedule temperatures are not subject to this server's setpoint limits. It stops short of covering error cases or permission requirements, but it adds real behavioral value for a mutation tool.

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

Conciseness5/5

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

Three sentences, front-loaded with the primary action, then scope, then an important caveat. Every sentence carries functional information with no padding.

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?

An output schema exists, so return-value details need not be explained. The description covers the main action, multi-thermostat scope, and the setpoint-limit caveat, which is enough for correct invocation. Minor gaps remain around no-hold edge cases and permissions, but the definition is substantially complete.

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 100%, so the baseline is 3. The description goes beyond the schema by explaining that `house` applies the operation to every thermostat in that house and reports each one separately. That scoping behavior is not obvious from the schema alone and materially improves parameter interpretation.

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?

The description gives a specific verb-and-resource pair: it clears holds (setpoint or comfort) and returns the thermostat to its schedule. That is directly distinguishable from the sibling tools that set temperature, adjust temperature, or set comfort. An agent can tell this is the inverse operation of creating a manual override.

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

Usage Guidelines3/5

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

Usage is implied by the behavior: call this when you want to remove manual holds and revert to schedule. However, the description never explicitly states when to use this versus set_temperature, adjust_temperature, or set_comfort, nor does it mention prerequisites or what happens if no hold is active. The context is clear but alternatives are not named.

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

Deploy Server

Other Tools