Skip to main content
Glama
adrighem

Domoticz MCP Server

by adrighem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Update user variable

update_user_variable
DestructiveIdempotent

Update an existing Domoticz user variable by specifying its name, type, and new value to keep home automation data current.

Instructions

Update var value. Cross-ref: domoticz://user-variables.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesExisting user variable name
valueYesNew user variable value
vtypeYesVariable type: 0 integer, 1 float, 2 string, 3 date, 4 time

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoOptional Domoticz response title
statusYesStatus returned by Domoticz, normally OK

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.0
    • changedOutput schema / additionalProperties
      Previous value: -trueNew value: +false
  2. Changed14 schema fields changedv1.3.1
    • addedInput schema / properties / name / description
      Added value: +"Existing user variable name"
    • addedInput schema / properties / name / maxLength
      Added value: +200
    • addedInput schema / properties / name / minLength
      Added value: +1
    • addedInput schema / properties / value / description
      Added value: +"New user variable value"
    • addedInput schema / properties / value / maxLength
      Added value: +2000
    • addedInput schema / properties / vtype / description
      Added value: +"Variable type: 0 integer, 1 float, 2 string, 3 date, 4 time"
    • addedInput schema / properties / vtype / enum
      Added value: +[
+  0,
+  1,
+  2,
+  3,
+  4
+]
    • addedOutput schema / additionalProperties
      Added value: +true
    • addedOutput schema / description
      Added value: +"A successful Domoticz command response."
    • removedOutput schema / properties / result
      Removed value: -{
-  "title": "Result",
-  "type": "string"
-}
    • addedOutput schema / properties / status
      Added value: +{
+  "description": "Status returned by Domoticz, normally OK",
+  "title": "Status",
+  "type": "string"
+}
    • addedOutput schema / properties / title
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional Domoticz response title",
+  "title": "Title"
+}
    • changedOutput schema / required
      Previous value: -[
-  "result"
-]New value: +[
+  "status"
+]
    • changedOutput schema / title
      Previous value: -"update_user_variableOutput"New value: +"DomoticzToolResult"
  3. First observedv1.1.0

TDQS

C2.9/5.0
Behavior2/5

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

The annotations already indicate destructive and non-read-only behavior, but the description adds almost no behavioral context beyond that. The only extra line is a cross-reference to domoticz://user-variables; it does not disclose side effects, type-change implications, or failure behavior.

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?

The description is extremely concise and front-loaded, with no filler. The cross-reference line is short and potentially useful, though its value is limited since it is not elaborated.

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

Completeness2/5

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

For a destructive mutation tool with siblings for adding and deleting variables, the description lacks key context: no mention that the target variable must already exist, no guidance on type-change behavior, and no routing to alternative tools. The schema and output schema help, but the description alone is insufficient for safe invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3 even though the description itself adds no parameter-level detail. The description does not go beyond the schema to clarify parameter relationships or edge cases.

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

Purpose4/5

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

The description states a clear action ('Update') on a specific resource ('var value'), so an agent can tell it is an update operation. However, it does not explicitly differentiate it from sibling tools like add_user_variable or delete_user_variable, and the informal 'var' is less precise than the title's 'user variable'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as add_user_variable or delete_user_variable. The description does not mention that the variable must already exist, nor does it exclude cases that belong to sibling tools.

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