Domoticz MCP Server

Overview Schema Source Related Servers Discussions Admin

Create event script

create_event

Create a Domoticz event by defining its name, interpreter, event type, and source XML. Optionally enable or disable the event upon creation.

Instructions

Create script. Cross-ref: domoticz://docs/dzvents_syntax.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	New event script name
`event_type`	Yes	Domoticz event type
`eventstatus`	No	1 to enable the event, 0 to disable it	1
`interpreter`	Yes	Domoticz event interpreter
`xmlstatement`	Yes	Event source or Blockly XML

Output Schema

TableJSON Schema

Name	Required	Description	Default
`title`	No	Optional Domoticz response title
`status`	Yes	Status returned by Domoticz, normally OK

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.4.0Sep 14, 2026
- changedOutput schema / additionalProperties
```
Previous value: -trueNew value: +false
```
Changed21 schema fields changedv1.3.1Jul 26, 2026
- addedInput schema / properties / event_type / description
```
Added value: +"Domoticz event type"
```
- addedInput schema / properties / event_type / maxLength
```
Added value: +50
```
- addedInput schema / properties / event_type / minLength
```
Added value: +1
```
- addedInput schema / properties / eventstatus / description
```
Added value: +"1 to enable the event, 0 to disable it"
```
- addedInput schema / properties / eventstatus / enum
```
Added value: +[
+  "0",
+  "1"
+]
```
- addedInput schema / properties / interpreter / description
```
Added value: +"Domoticz event interpreter"
```
- addedInput schema / properties / interpreter / maxLength
```
Added value: +50
```
- addedInput schema / properties / interpreter / minLength
```
Added value: +1
```
- addedInput schema / properties / name / description
```
Added value: +"New event script name"
```
- addedInput schema / properties / name / maxLength
```
Added value: +200
```
- addedInput schema / properties / name / minLength
```
Added value: +1
```
- addedInput schema / properties / xmlstatement / description
```
Added value: +"Event source or Blockly XML"
```
- addedInput schema / properties / xmlstatement / maxLength
```
Added value: +1000000
```
- addedInput schema / properties / xmlstatement / minLength
```
Added value: +1
```
- 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: -"create_eventOutput"New value: +"DomoticzToolResult"
```
First observedv1.1.0May 4, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows this is a non-idempotent write operation. The description adds no behavioral detail beyond 'Create script' – it does not mention failure modes, duplicate name handling, or side effects. The cross-reference is about syntax, not behavior. No contradiction with annotations.

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 – two short sentences, with the core action 'Create script' front-loaded and the cross-reference as a secondary note. No wasted words, though it could be seen as under-specified rather than efficiently concise. It is structured well for a quick scan.

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 tool with 5 parameters (4 required) including a complex xmlstatement field, the description is inadequate. It does not explain what an event script is, what event_type options exist, how to construct xmlstatement, or what the tool returns (though an output schema exists). The cross-reference to docs may help, but the description is not self-contained and leaves the agent to infer too much. Given the schema and annotations, it is still not complete enough to use confidently.

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 each parameter already has a description. The tool description adds no extra meaning about parameters, such as how event_type and interpreter relate, or what a valid xmlstatement looks like. Since the schema covers the basics, a baseline of 3 is appropriate; the description does not compensate beyond that.

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 verb ('Create') and resource ('script'), and the title clarifies it is an event script. It is distinguishable from siblings like update_event (create vs. update) and search_scripts_tool (create vs. search), though it does not explicitly mention those distinctions. The cross-reference to dzvents_syntax adds context about what kind of script is created.

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. It does not mention that this creates a new event as opposed to updating an existing one, nor does it reference any prerequisites or related tools. The only hint is the cross-reference to syntax docs, which is not usage guidance.

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