Domotz MCP + Stream Deck

Applies a device profile (a saved bundle of sensors, and optionally credentials) to one or more devices. Apply runs as a background job — the tool blocks for up to poll_timeout_seconds (default 60s, max 120s) waiting for completion. If the job finishes within that window, per-device results are returned. If it times out, a partial state is returned; you can wait and call this tool again with the same arguments — apply is idempotent in REPLACE mode. IMPORTANT: a successful call does NOT mean every requested device was configured. Report the apply as complete only when applied_count covers every requested device; any other count being non-zero means it is not. Consult retryable rather than your own judgement before calling again. Devices on collectors you lack the Device Management permission on are skipped: they come back with result WITHHELD and an explanation. Whenever the apply is dispatched, every requested device carries exactly one verdict in per_device — OK, FAIL, WITHHELD, NOT_APPLIED (the job did not cover it), UNKNOWN (outcome undeterminable) or PENDING — and the per-verdict counts add up to the devices you asked for. Sometimes no job is created at all — job_status is NOT_STARTED, retryable is false and calling again cannot change the outcome; the cause varies (every device withheld, no devices matched, the profile has no modules), so relay the message instead of assuming a permission problem. other_issues carries anything the backend reported about something other than a device; it is normally empty, and a non-empty one is worth relaying rather than ignoring. If the profile contains credential modules, applying it WILL OVERWRITE existing credentials on the targeted devices, and this tool does not warn you when it does: read has_credentials from list_device_profiles before applying, and tell the user what will be overwritten. For applying alert rules to devices, use bind_alert_rule_to_device instead. Devices named in failed_device_ids carry no reason for their failure; WITHHELD devices, and devices affected by a job that failed or was cancelled as a whole, do carry one. Input-validation and dispatch errors return an error with a message and retryable, and no per-device detail.

Attach a driver to a device. THIS IS A LIVE OPERATION: the backend runs the driver's validate() action against the device during attach and, once the binding is persisted, the scheduler will trigger the real (non-dry-run) actions (get_status for GENERIC, backup for CONFIGURATION_MANAGEMENT) on the device's sample period. PRECONDITION: execute_driver must have returned outcome=success for every mandatory action (validate + get-status for GENERIC, validate + backup for CONFIGURATION_MANAGEMENT) against this (driver_id, collector_id, device_id) tuple. Because the driver is not yet attached, those execute_driver calls run in dry-run mode automatically and persist nothing — they exist precisely to catch failures before this attach. Skipping them and relying on attach_driver's implicit validate() alone hides failures of get_status / backup until the next scheduled run. Provide params as a list of {name, value} pairs matching the driver's PARAMETER SCHEMA (the inputs declared on the driver — NOT for credentials). The tool resolves names to internal parameter IDs before dispatch (unknown names are rejected). Sample period defaults to the driver's minimum; that's not configurable in this beta. To remove the binding later use detach_driver; to delete the driver everywhere use delete_driver. credentials (SEPARATE top-level argument — DO NOT put inside params): {username: str, password: str, store?: bool}. Used for the validate() call that runs during attach. On a successful attach, the backend's result reporter persists these credentials in the credential store AND seeds the device's purpose row (CUSTOM_DRIVER_MANAGEMENT for GENERIC drivers, CONFIGURATION_MANAGEMENT for CM drivers). After that, set_device_credential(purpose=...) works for rotation. For CONFIGURATION_MANAGEMENT drivers on devices that don't already have a CM purpose row, you MUST pass credentials here — calling set_device_credential first will fail with 412 (scope missing). Common LLM mistake: passing credentials as an entry in params like {name: 'credentials', value: {username, password}}. That goes to the driver's parameter list and is NOT used for authentication. The tool rejects this shape with WRONG_FIELD_SHAPE so you can resubmit with the top-level credentials arg. If the driver is already attached, returns result=ALREADY_ATTACHED with the existing binding_id. If the backend rejects the attach for another reason (e.g. driver validation error), returns result=CONFLICT with the error details. If the driver's validate() action fails, returns result=VALIDATION_FAILED with the driver error and a remediation hint.

Attach a sensor to a device. sensor_spec.kind selects the variant: overlay applies a preconfigured sensor (use list_preconfigured_sensors to discover overlay_id, optional selected_fields to subset its fields); tcp_port monitors a TCP port on the device (port 1..65535); custom_oid defines a per-device custom SNMP-OID sensor — required: oid (dotted notation, e.g. 1.3.6.1.2.1.1.3.0), name (short identifier), value_type (1|STRING, 2|NUMERIC, 3|ENUM — accepted as int id or label), description (human-readable text); optional: custom_name. Each custom_oid call creates a new per-device sensor entity — the same OID attached to multiple devices yields independent sensors. Sensor limits per collector apply; duplicate overlay attachments return a structured FAIL with a clear reason. No detach in this beta — remove via the UI.

Bind an existing alert rule to a collector. Use this for collector-scoped metrics such as agent_status or agent_performance/*. Already-bound combinations return status=ALREADY_BOUND rather than an error (idempotent retry-safe). Use after create_alert_rule (with the returned id) or after picking an existing rule from list_alert_rules. Before binding, call get_collector_alert_rule_bindings to verify the rule is not already bound to this collector.

Bind an existing alert rule to a specific device. The system will then watch every variable on that device whose metric matches the rule and raise incidents when the rule's condition is met. Use after create_alert_rule (with the returned id) or after picking an existing rule from list_alert_rules. Before binding, call get_device_alert_rule_bindings to verify the rule is not already bound to this device (binding-level dedupe). For variable-level dedupe — checking whether a suitable rule already exists for a specific variable — use list_variable_alert_rule_candidates before creating a new rule. Already-bound combinations return status=ALREADY_BOUND rather than an error (idempotent retry-safe). SENSOR CHECK: verify device has sensor data for the metric before binding (see alert_rule_id parameter). ICMP CAVEAT: latency/packet-loss rules require ICMP — check device_performance for 100% packet_loss_percent before binding, as many devices (firewalls, hardened hosts) block ICMP. BINARY METRIC: bind only one rule per binary metric (device_status, heartbeat) per device to avoid duplicate incidents.

Bind a Collector to an Organization (addressed by its internal id). A Collector can belong to one Organization at a time. Reversible via unbind_collector_from_organization.

Bind tags to a device or to a collector, setting which tags it carries. Pass device_id to tag a device (with the collector_id that monitors it), or omit device_id to tag the collector itself. This REPLACES the target's whole tag set - send every tag it should end up with, not just the new one, or the omitted tags are removed. Read the current set first from search_devices / search_collectors (field custom_tags), and use list_tags for the catalog of valid ids. An empty tag_ids removes every tag from the target. The tags themselves are never deleted - use delete_tag for that. Tagging a device requires the manage_devices permission on its collector; tagging a collector requires manage_configuration.

Close a remote connection opened with create_remote_connection, invalidating its URL and releasing the collector's remote-access allowance immediately. Any browser tab or client still using it drops, so close only what the user is done with. Connections also expire on their own (at most an hour), but until then they stay reachable by anyone holding the URL — closing an unneeded one is the only way to revoke it. Source session_id and device_id from list_remote_connections.