Skip to main content
Glama
claymore666

debmatic-mcp

by claymore666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Set Value

set_value
DestructiveIdempotent

Change a HomeMatic device's datapoint (e.g. STATE, LEVEL) on a specified channel by providing address, valueKey, and value; interface and type auto-resolve, and the previous value is returned for undo.

Instructions

Set a single datapoint value on a device channel. Only address, valueKey, and value are required — interface and type are auto-resolved. Returns the previous value for undo. Use describe_device_type to find valid valueKeys and ranges.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoValue type override (auto-resolved if omitted)
valueYesValue to set
addressYesChannel address (e.g. '000A1BE9A71F15:1')
confirmNoSet true to authorize this write against a protected CCU target (e.g. prod). Unlocks writes to that target for the rest of the session.
valueKeyYesDatapoint name (e.g. 'STATE', 'LEVEL', 'SET_POINT_TEMPERATURE')
interfaceNoInterface name override (auto-resolved if omitted)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.11.0
    • removedInput schema / properties / value / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  }
-]
    • addedInput schema / properties / value / type
      Added value: +[
+  "string",
+  "number",
+  "boolean"
+]
  2. Changed1 schema field changedv1.7.0
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Set true to authorize this write against a protected CCU target (e.g. prod). Unlocks writes to that target for the rest of the session.",
+  "type": "boolean"
+}
  3. First observedv1.1.2

TDQS

A4.5/5.0
Behavior4/5

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

With destructiveHint=true already signaling a write/overwrite, the description adds behavioral context by stating that interface and type are auto-resolved and that the previous value is returned for undo. This is valuable beyond annotations because it tells agents how to recover from the mutation. No contradiction with openWorldHint or idempotentHint.

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?

Four short sentences, each carrying distinct information: purpose, required parameter set, undo behavior, and validation guidance. It is front-loaded with the operation and does not waste words.

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

Completeness5/5

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

The description covers the core action, required inputs, auto-resolution behavior, return value, and where to look up valid valueKeys. The confirm parameter's protected-target behavior is fully documented in the schema, so its absence here is acceptable. There is no output schema, but the return value is stated clearly.

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?

While the schema describes all six parameters (100% coverage), the description adds semantic value by emphasizing that only address, valueKey, and value are required and that interface/type need not be supplied because they are auto-resolved. This prevents an agent from over-specifying parameters. It also ties valueKey to valid values via describe_device_type.

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 opens with a specific verb and resource: 'Set a single datapoint value on a device channel.' It clarifies the unique scope ('single datapoint') and distinguishes itself from sibling tools like set_system_variable or put_paramset by targeting a device channel datapoint. The mention of auto-resolution and undo further identifies its specific behavior.

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 statement 'Only address, valueKey, and value are required' gives clear prerequisites, and 'Use describe_device_type to find valid valueKeys and ranges' explicitly routes users to a sibling for pre-validation. It does not mention when not to use this tool, but the intended context—setting a single datapoint—is clear enough to guide selection.

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