# How to connect Domotz MCP with ChatGPT Work

```json
{
  "title": "How to connect Domotz MCP with ChatGPT Work",
  "toolkit": "Domotz MCP",
  "toolkit_slug": "domotz_mcp",
  "framework": "ChatGPT Work",
  "framework_slug": "chatgpt",
  "url": "https://composio.dev/toolkits/domotz_mcp/framework/chatgpt",
  "markdown_url": "https://composio.dev/toolkits/domotz_mcp/framework/chatgpt.md",
  "updated_at": "2026-09-03T05:38:48.626Z"
}
```

## Introduction

### How to connect Domotz MCP with ChatGPT Work
[ChatGPT Work](https://openai.com/chatgpt-work/) is an agent inside ChatGPT built for your most ambitious work. It takes action across your apps and files, stays with a project for hours, and turns a goal into finished materials like sheets, slides, and docs - not just answers.
In this guide, I will explain the easiest and most secure way to connect your Domotz account to ChatGPT Work via Composio Connect, so it can inspect devices, list active alerts, query site status, acknowledge incidents, and retrieve device diagnostics through natural language commands without ever putting your account credentials at risk.

## Also integrate Domotz MCP with

- [Claude Cowork](https://composio.dev/toolkits/domotz_mcp/framework/claude-cowork)
- [Hermes](https://composio.dev/toolkits/domotz_mcp/framework/hermes-agent)

## TL;DR

### Why use Composio over default connectors?
- Apps with read and write access. Default connectors mostly can read your data. Composio's Domotz integration lets ChatGPT Work take actions like creating drafts, sending updates, labeling records, and more.
- 1,000+ SaaS toolkits out of the box. Composio gives you instant access to a vast catalog of pre-built connectors, from Gmail and Slack to Notion, Linear, and Salesforce.
- One MCP server for every app. Connect any of your applications on demand through a single endpoint, rather than juggling a separate server for each app.
- Smart, context-aware tool loading. Unlike traditional MCP servers that dump every available tool into the LLM context window, Composio searches for and loads only the tools relevant to the task at hand.
- Cross-app automation. Chain actions across multiple apps in a single run - fetch a thread, summarize it in Notion, and post highlights to Slack without leaving the conversation.

## Connect Domotz MCP to ChatGPT Work

### Prerequisites
- A ChatGPT account with access to ChatGPT Work (rolling out across Pro, Enterprise, Edu, Plus, and Business plans). We will use the [ChatGPT desktop app](https://openai.com/chatgpt/download/), which is available on every plan.
- Access to the Domotz workspace you want to connect.
- [Composio MCP](https://dashboard.composio.dev/login?utm_source=toolkits&utm_medium=framework_template&utm_campaign=chatgpt&utm_content=composio_connect&next=%2F~%2Forg%2Fconnect%2Fclients%2Fchatgpt).
Note: Composio connects through OAuth. You will be asked to sign in and approve specific permissions. Review the permission screen carefully if you are using a work account.
### Step-by-step: Connect Domotz to ChatGPT Work
### 1. Open the MCP settings
In ChatGPT Work, go to Settings and open the Plugins section. Inside the Plugins page, click the MCP tab.
### 2. Add the server
Click Add server. In the Name field enter Composio, for Type select Streamable HTTP, and in the URL field paste the Composio MCP server URL:

```bash
https://connect.composio.dev/mcp
```

## What is the Domotz MCP server, and what's possible with it?

The Domotz MCP server is an implementation of the Model Context Protocol that connects your AI agent and assistants like Claude, Cursor, etc directly to your Domotz account. It provides structured and secure access so your agent can perform Domotz operations on your behalf.

## Supported Tools

| Tool slug | Name | Description |
|---|---|---|
| `DOMOTZ_MCP_APPLY_DEVICE_PROFILE` | Apply device profile | 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 (the confirmation prompt discloses this when relevant). 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. |
| `DOMOTZ_MCP_ATTACH_DRIVER` | Attach driver | 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. |
| `DOMOTZ_MCP_ATTACH_SENSOR` | Attach sensor | 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. |
| `DOMOTZ_MCP_BIND_ALERT_RULE_TO_COLLECTOR` | Bind alert rule to collector | 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. |
| `DOMOTZ_MCP_BIND_ALERT_RULE_TO_DEVICE` | Bind alert rule to device | 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. |
| `DOMOTZ_MCP_BIND_COLLECTOR_TO_ORGANIZATION` | Bind collector to organization | 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. |
| `DOMOTZ_MCP_BIND_TAGS` | Bind tags | 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. |
| `DOMOTZ_MCP_COLLECTOR_DISCOVERY_STATUS` | Collector discovery status | Returns the discovery dashboard data for a collector, including initial discovery progress, device statistics, collector issues, and device categories. Use this after a collector comes online to monitor network discovery. |
| `DOMOTZ_MCP_COLLECTOR_OVERVIEW` | Collector overview | Fetch a high-level overview of a collector including its identity, health status, software version, uptime/downtime intervals, device counts, security issues, speed test results, and IP conflict status. Pass `lookback` (in days, 1-90, default 7) to widen or narrow the uptime window. Note: when the collector is OFFLINE, live fields populated by the collector (speed test, IP conflict) coalesce to null — null means 'no recent push' rather than 'never ran'. Counters and uptime stay populated server-side. Use as the first call to understand the overall state of a collector before diving deeper. |
| `DOMOTZ_MCP_COMPARE_CONFIG_BACKUP` | Compare config backup | Compares two configuration backup snapshots of the same device. `config_type` selects which side(s) to compare: `running` (default), `startup`, or `both`. Returns a unified diff (LCS) when both sides are <= 5000 lines; falls back to a set-based added / removed listing otherwise. When MD5s match, `diff_strategy` is `md5_match` and the summary is empty. `max_diff_lines` (default 200) caps the returned `diff_text`. |
| `DOMOTZ_MCP_CREATE_ALERT_RULE` | Create alert rule | Create an alert rule. The rule fires when the named metric matches the given condition against the provided operands. `function` accepts a name (e.g. 'GREATER_THAN', 'LESS_THAN', 'RANGE') or a numeric function_id (e.g. '2'). Call `list_metric_functions` first to discover valid functions and their required operand count for the chosen metric. severity must be one of: Critical / High / Warning / Info. channel_ids must list at least one notification channel — a rule without channels notifies no one (use `list_communication_channels` to discover valid IDs). The rule's `metric` is IMMUTABLE after creation: changing the target metric requires deleting the rule via the UI and creating a new one. After creation, use `bind_alert_rule_to_device` to bind the rule to specific devices or variables. |
| `DOMOTZ_MCP_CREATE_CONTACT` | Create contact | Add a Contact to the Organization with the given internal `id`. `name` and `email` are required; `mobile_phone` and `phone` are optional. Returns the new contact_id. Contacts belong to a single Organization. |
| `DOMOTZ_MCP_CREATE_ORGANIZATION` | Create organization | Create a new Organization for the calling account. Returns the new internal `id`. `organization_id` is an optional caller-defined reference (e.g. a CRM id); it is stored as-is and is not used to address the organization. Reversible via delete_organization. Requires MCP access on the account. |
| `DOMOTZ_MCP_CREATE_TAG` | Create tag | Create a new user-defined tag. `color` is cosmetic and user-visible: do not pick one yourself -- ask the user which colour they want, and omit the parameter when you cannot ask (omitted means gray). Valid values are in the `color` enum, and `update_tag` can recolour later without affecting any bindings. The new tag becomes immediately usable as a filter in search_devices / search_collectors, as an assignable id in `bind_tags`, and can be renamed or recoloured with `update_tag`. Reversible with delete_tag. For MSP accounts the tag namespace is account-wide. Requires the manage_device_tags permission; callers without it receive a permission error. |
| `DOMOTZ_MCP_CYCLE_OUTLET_POWER` | Cycle outlet power | Power-cycle a single outlet on a host device (PoE switch / PDU). The powered device will experience a brief outage while the outlet turns OFF and back ON. Although the outlet itself returns to its prior ON state, the device may suffer config corruption or data loss during the cycle — treat as a recovery action of last resort. The cycle is dispatched asynchronously (HTTP 202): the response confirms dispatch, not completion. Source `host_device_id` and `outlet_id` from the `power_source` block returned by `device_inventory` for the powered device; that block is present only when the device is on a managed PoE switch or PDU and is the indicator that power-cycling is supported. Re-query `device_inventory` afterwards to inspect `power_source.link_freshness`. |
| `DOMOTZ_MCP_DELETE_ALERT_RULE` | Delete alert rule | Delete an alert rule by ID. Irreversible — the rule and all its device/collector/variable bindings are removed. Use `list_alert_rules` to discover valid IDs. Idempotent: deleting a non-existent rule returns status=NOT_FOUND (no error). |
| `DOMOTZ_MCP_DELETE_CONTACT` | Delete contact | Permanently delete a Contact from the Organization with the given internal `id`. This cannot be undone. |
| `DOMOTZ_MCP_DELETE_DEVICE` | Delete device | PERMANENTLY delete one or more device records from a collector: the device and its history are removed entirely. This is IRREVERSIBLE - deleted devices cannot be recovered (though a device may be rediscovered later if it is still present on the network). Accepts a single device_id (int) or a list of device_ids (list[int]) for bulk deletion - all devices must belong to the same collector. Devices that no longer exist are reported as not-found and skipped (no error). Use `search_devices` to find device_ids before deleting. |
| `DOMOTZ_MCP_DELETE_DRIVER` | Delete driver | Permanently delete a driver from the account. This is IRREVERSIBLE: the driver disappears for every device it was attached to, all existing bindings are removed, and the scheduler stops running it everywhere. Persisted metrics and configuration backups produced before deletion remain in their respective stores — only the driver definition and its bindings are removed. ALWAYS confirm with the user before calling; in particular, list the devices that currently have the driver attached so the user understands the blast radius. Use `get_driver_catalog` for the driver catalog and `list_device_drivers` per device to enumerate bindings. If the intent is just to stop running the driver on ONE device, use `detach_driver` instead. |
| `DOMOTZ_MCP_DELETE_ORGANIZATION` | Delete organization | Permanently delete an Organization. Any Collectors bound to it are unlinked (not deleted). Fails if it is the account's only Organization. This cannot be undone. |
| `DOMOTZ_MCP_DELETE_TAG` | Delete tag | Delete a user-defined tag by ID. Irreversible — the tag is removed and unbound from every device and collector it was assigned to. Use `list_tags` to discover valid IDs. Idempotent: deleting a non-existent tag returns status=NOT_FOUND (no error). Fails with `TAG_IN_USE` if the tag is still referenced by one or more custom filters; the response lists the blocking filters so the caller can edit or remove them first. Requires the manage_device_tags permission. |
| `DOMOTZ_MCP_DETACH_DRIVER` | Detach driver | Remove the binding between a driver and a device on the given collector. The driver itself stays in the account and remains attached to other devices — only THIS device's binding is removed. The scheduler will stop running the driver on this device; any metrics already emitted are preserved. CONFIGURATION_MANAGEMENT drivers: previously persisted backups remain in storage and the device's CONFIGURATION_MANAGEMENT purpose row stays in the credential store (rotate or delete credentials via set_device_credential / UI if needed). To delete the driver everywhere instead, use `delete_driver`. Pass device_id+collector_id+driver_id; if no binding exists, the tool returns result=NOT_ATTACHED (idempotent — safe to call repeatedly). |
| `DOMOTZ_MCP_DETACH_SENSOR` | Detach sensor | Detach a preconfigured (overlay) sensor from a device. Irreversible — the overlay link is removed and the sensor stops collecting. Use `list_device_sensors` to discover the `overlay_id` for currently attached overlay sensors. Only overlay (preconfigured) sensors can be detached via MCP: TCP-port sensors and custom OID sensors must be removed via the UI in this beta. Idempotent: detaching a non-attached overlay returns status=NOT_FOUND (no error). |
| `DOMOTZ_MCP_DEVICE_INVENTORY` | Device inventory | Returns detailed information about a single device: identity, status, capabilities, protocol coverage, attached sensors/drivers/profiles, OS info, location, power source, and end-of-life (EOL) status for firmware, software, and hardware. Includes `collector_id` and `collector_name` — the numeric id (and display name) of the collector that monitors this device; needed for any subsequent metric tool call. The `power_source` section (when present) carries `host_device_id`, `outlet_id`, `outlet_type`, `link_source`, `link_freshness`, `available_power_actions` and, when no action is available, `power_actions_unavailable_reason`. `available_power_actions` lists what `set_device_power` accepts for this device right now (`on`, `off`, `cycle`, `software_reboot`); use `host_device_id` + `outlet_id` only for the older `cycle_outlet_power`. The `protocol` field describes how the device is represented: 'ip' (a standard network device with its own IP address); 'grouped' (a device that merges multiple network interfaces (NICs) on the same physical host into one logical device - it is online if any of its member interfaces is online, and the member interfaces are represented by this single grouped device); 'logical' (a manually-managed placeholder device with no IP - its status is set manually, not auto-monitored). Use for questions about what a device is, its hardware/software, installed services, where it is, how it is powered, or whether it has reached end-of-life. When presenting results, always refer to devices by name, not just by ID. |
| `DOMOTZ_MCP_DEVICE_PERFORMANCE` | Device performance | Fetch device performance metrics including round-trip delay, packet loss, uptime, SNMP sensor values, and disk usage over the last 7 days. Use for questions about device health, availability, resource utilization, or network performance. |
| `DOMOTZ_MCP_EXECUTE_DRIVER` | Execute driver | Run an action of a driver against a device. The tool auto-selects mode based on whether the driver is attached to the device: - NOT attached → DRY-RUN. The action runs on the device (real network, real credentials) but nothing is persisted: no metric stored, no backup row created, no binding made. Use this to smoke-test newly created drivers BEFORE attach_driver. Response includes `mode: 'dry-run'`. - ATTACHED → LIVE. Standard execution against the existing binding. Results are persisted by the scheduler/backend as usual. Response includes `mode: 'live'`. The binding must have `code_is_valid: true` and `status: ENABLED`. REQUIRED authoring workflow: save_driver → set_device_credential (if needed) → execute_driver (validate) → execute_driver (get-status \| backup) → confirm both outcome=success → attach_driver. The first two execute_driver calls auto-run as dry-run because no binding exists yet. After attach_driver, future execute_driver calls run live. `action_id` values: `validate`, `get-status`, `backup`, `restore`, `custom-N`. For GENERIC drivers dry-run `validate` then `get-status`; for CONFIGURATION_MANAGEMENT dry-run `validate` then `backup`. `params` is a list of {name, value} pairs; types are derived from the driver's parameter schema. `credentials` (SEPARATE top-level argument — DO NOT put inside `params`): pass `{username: str, password: str, store?: bool}` to use ad-hoc credentials for this single execution instead of (or in addition to) any credentials previously saved via `set_device_credential`. Useful in the dry-run loop to try a credential without persisting it. `store` defaults to false in dry-run, true in live mode — set explicitly to override. Passwords are redacted in audit logs. 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 IGNORED by the authentication path — the call then fails with INVALID_CODE/PRECONDITION because no real credentials reached the sandbox. The tool rejects this shape with WRONG_FIELD_SHAPE so you can resubmit with the top-level `credentials` arg. Logs are capped at 100 lines. DRY-RUN OUTPUT: when `mode: 'dry-run'`, the response also surfaces what the driver WOULD emit, so you can verify before attaching: `metrics` (GENERIC metric table), `variables` (legacy scalar variables), `tables`, and `backup` (CONFIGURATION_MANAGEMENT `running`/`startup`, each truncated to 4000 chars with a `*_truncated: true` flag). These keys appear only when present and only in dry-run; live runs persist results and omit them. |
| `DOMOTZ_MCP_GET_ACCOUNT_INFO` | Get account info | Returns identity and account context for the currently authenticated user: user ID, email, billing state, trial end date, whether the user is the account owner, and whether RBAC is enabled. For freemium users, also includes current device usage and limits. Use this as the first call to understand who you are acting as and what account capabilities are available. |
| `DOMOTZ_MCP_GET_AUDIT_LOG_FILTERS` | Get audit log filters | Return the set of values available for filtering Domotz audit logs: the operation categories (each with its operation types), source applications, target entities, actor entities, and outcome statuses currently present in the data. Use this to discover valid arguments for `search_audit_logs` before searching. |
| `DOMOTZ_MCP_GET_COLLECTOR_ALERT_RULE_BINDINGS` | Get collector alert rule bindings | List alert rules bound to a specific collector, including bindings at the collector level and bindings to variables owned by that collector. Use to see which alert rules are active on a collector and which metrics they target. |
| `DOMOTZ_MCP_GET_COLLECTOR_CAPABILITIES` | Get collector capabilities | Inspect what the customer's Collector can actually run. Without `driver_id`, returns the Collector's current sandbox module version plus the full supported / unsupported `D.*` symbol lists. With `driver_id`, returns a compatibility diff for that specific driver against this Collector, including a `compatible` flag and any `missing_features`. Use this BEFORE `attach_driver` / `execute_driver` to warn the customer when the Collector is behind on the sandbox version the driver requires — execute will otherwise fail with HTTP 412 inside execute_driver. |
| `DOMOTZ_MCP_GET_COLLECTOR_CREDENTIAL_COVERAGE` | Get collector credential coverage | Collector-wide credential audit. Returns only credential STATUS and metadata (integration status, SNMP reading sub-status). Does NOT return passwords, private keys, or SNMP community strings. Returns every visible device on the collector (including those with `has_working_credentials: false` so missing-credential gaps are visible) along with its enabled integration purposes — SNMP_MANAGEMENT, OS_MONITORING, CONFIGURATION_MANAGEMENT, ONVIF_CAMERA, DEVICE_MANAGEMENT — and whether each purpose's credentials are working (`UNLOCKED`) or not yet validated (`LOCKED`). SNMP_MANAGEMENT integrations include `snmp_reading_status` (CHECKING / NOT_FOUND / NOT_READING_DATA / READING_DATA) when available. `has_working_credentials` is true only when at least one purpose has valid, working credentials. Status mapping to `get_device_credentials`: UNLOCKED = AUTHENTICATED; LOCKED = any of REQUIRED / PENDING / WRONG_CREDENTIALS / NO_AUTHENTICATION. For per-protocol credential drill-down on a specific device (SSH/HTTP/etc.), use `get_device_credentials`. |
| `DOMOTZ_MCP_GET_CONFIG_BACKUP_ENTRY` | Get config backup entry | Returns a single configuration backup snapshot's text for a device. `config_type` selects which block to return: `running`, `startup`, or `both` (default). When running and startup configs are identical, `configs_match` is true and only the `running` block is populated for `both`. Each block carries `text` plus `line_count`, `truncated`, and `returned_lines` so the caller knows whether it was capped. `max_lines` (default 1000) caps each block independently — large enterprise configs can exceed this; raise the cap if a fuller view is needed. |
| `DOMOTZ_MCP_GET_CONFIG_BACKUP_STATUS` | Get config backup status | Lists devices on a collector that have configuration backup ('config backup') enabled, with the active backup driver, mode (READ_WRITE / READ_ONLY / AVAILABLE / INSUFFICIENT_PRIVILEGE / ERROR), status (ENABLED / DISABLED), failed-inspection count, and last inspection time. Devices without a detected backup driver are simply absent — this is not an error. Driver values include CISCO_IOS, CISCO_SG30X, CISCO_CBS, LUXUL_SMBSTAX, WATCHGUARD_FIREWARE_OS, WATCHGUARD_FIREWARE_OS_TFTP, FORTIGATE, FORTIGATE_TFTP, JUN_OS, HP_ARUBA_OS, HP_ARUBA_OS_AP, HP_ARUBA_OS_CX, HP_ARUBA_OS_SWITCH, SONICWALL, MIKROTIK, NETGEAR_OS_SWITCH, DELL_OS_SWITCH. |
| `DOMOTZ_MCP_GET_CREATE_TAG_FORM` | Get create tag form | Shows an interactive form to create a new custom tag, with a name field and a color picker. Use this tool when the user asks to create a new tag. If the user already stated the tag name or the color, pass them as the "name" and "color" arguments so they are pre-selected and the user does not have to enter them twice. Leave an argument out when the user did not mention it: the color then defaults to gray. This tool only creates a tag; it does NOT apply it to devices or collectors, and does NOT list or search existing tags. |
| `DOMOTZ_MCP_GET_DEVICE_ALERT_RULE_BINDINGS` | Get device alert rule bindings | List alert rules bound to a specific device, including device-level bindings and bindings to variables owned by that device. Requires both collector_id and device_id. Use to see which alert rules are active on a device and which metrics they target. Call before bind_alert_rule_to_device to verify the rule is not already bound. |
| `DOMOTZ_MCP_GET_DEVICE_ALERTS` | Get device alerts | Retrieve alert and monitoring configuration status for a specific device. Returns whether shared alerts are configured, event/alert rule counts, alert rule IDs, and setup integrations. Requires a device_id. |
| `DOMOTZ_MCP_GET_DEVICE_CREDENTIALS` | Get device credentials | Per-device credential status drill-down. Returns only credential STATUS and metadata (authentication status, SNMP version, public-key fingerprint, timestamps). Does NOT return passwords, private keys, or SNMP community strings. Covers SNMP version + reachability status, and per-protocol access keys (SSH / TELNET / HTTP / HTTPS / WINRM / ONVIF) with their authentication status and (where available) public-key fingerprint. Status enums — `snmp.status`: CHECKING / NOT_FOUND / NOT_READING_DATA / READING_DATA; `access_keys[].authentication_status`: AUTHENTICATED / REQUIRED / PENDING / WRONG_CREDENTIALS / NO_AUTHENTICATION. `snmp` is null when no SNMP data exists. Status mapping to `get_collector_credential_coverage`: AUTHENTICATED = UNLOCKED; any of REQUIRED / PENDING / WRONG_CREDENTIALS / NO_AUTHENTICATION = LOCKED. For collector-wide credential gap analysis, use `get_collector_credential_coverage`. |
| `DOMOTZ_MCP_GET_DEVICE_HISTORY` | Get device history | Returns the per-device History / Event Log for a single device: the chronological stream of events the device generated, most recent first. Events include availability transitions (`UP`/`DOWN`), `IP_CONFLICT_DETECTION` / `IP_CONFLICT_RESOLUTION`, `CREATED`, `IP_CHANGE`, `CONFIGURATION_CHANGE`, `CONFIGURATION_MISALIGNMENT`. Each entry carries a `timestamp` (ISO 8601) and an `event` name; when the backend recorded extra context (e.g. the IP or MAC address involved) it is returned in a `details` object. Requires `collector_id` and `device_id`. Optional `event_type` filters to a single event name from the fixed set above (case-insensitive). Optional `from`/`to` accept ISO 8601 timestamps and bound the time window; the backend caps a query at 31 days. If neither is given, the most recent events are returned; if only one is given the window defaults to 7 days. This is the device-level event stream, distinct from get_device_alerts (monitoring-profile alert configuration) and search_alerts (fired incidents). |
| `DOMOTZ_MCP_GET_DEVICE_INTERFACES` | Get device interfaces | Lists the SNMP-collected interfaces on a device. Returns id as a string (= ifIndex, pass directly to `get_interface_traffic.interface_ids`), name, alias, description, admin/operational status (IF-MIB enums: up/down/testing/unknown/dormant/notPresent/lowerLayerDown), high-speed (Mbps), type (human-readable IANA ifType label, e.g. 'ethernetCsmacd', 'ieee80211', 'tunnel', 'ieee8023adLag'), and per-interface error/discard counters. Devices without SNMP credentials yield an empty result. `max_interfaces` (default 100) caps the returned list; when truncated, `truncated: true` and `total_count` indicate that more exist. |
| `DOMOTZ_MCP_GET_DEVICE_METRICS` | Get device metrics | Fetch summarised time-series analytics for one or more named metrics on a device within a time range. `metric_names` is capped at 15 per call and the total variables analysed across all metrics is capped at 30 (each metric can fan out to multiple variables, each analysed independently by the time-series analysis backend). Numeric variables are returned under `variables` with full analytics; text variables (e.g. status strings, hostnames, firmware versions) are returned under `text_variables` with `latest`, `count`, and `distinct_values` instead — they have no statistical analysis, so `include_anomalies` and `include_change_points` are ignored for them. `view=summary` (default) returns scalar stats only ({min, max, avg, latest, count, std, trend_slope, seasonality}); `view=timeseries` adds bucketed time/values arrays per variable, trimmed to `max_datapoints` (default 50). `include_anomalies` adds rolling-MAD anomaly points. `include_change_points` adds PELT segment break-points. `from`/`to` accept ISO 8601 timestamps; default window is the last 7 days (the time-series analysis backend needs a multi-day baseline for anomalies and change-points). Source `metric_names` from `list_collector_metrics` or `list_device_sensors`. |
| `DOMOTZ_MCP_GET_DRIVER_CATALOG` | Get driver catalog | Lists the account-wide catalog of drivers available for attaching and executing on devices. Each entry returns the `id` (use as `driver_id` in `attach_driver` / `execute_driver`), `name`, `description`, `type`, `minimal_sample_period`, `last_saved_time`, and a `parameters` array describing each input (`name`, `label`, `value_type`, default `value`) — empty when the driver declares none. `code_is_valid: false` ⇒ the driver will fail at execute time and should not be attached. `credentials_required: true` ⇒ the device must have credentials configured before the driver can run; if absent, attach will fail. |
| `DOMOTZ_MCP_GET_DRIVER_TEMPLATE` | Get driver template | Fetch a single driver template, including its full JS code body and requirement metadata (`requirements.sandbox_version`, etc.). Use the returned `code` as the starting point for `inspect_driver` and `save_driver`. |
| `DOMOTZ_MCP_GET_INTERFACE_TRAFFIC` | Get interface traffic | Returns traffic counters for one or more device interfaces over a time range. Octets are reported in bps (per-period delta). `interface_ids` accepts strings or integers (pass the `id` values returned by `get_device_interfaces` directly); capped at 5 per call. `view=summary` (default) returns avg/max bps and total errors/discards; `view=timeseries` adds downsampled time/values arrays per interface, capped at `max_datapoints` (default 50) and limited to in/out octets unless `include_error_series=true`. `from`/`to` accept ISO 8601 timestamps; default window is the last 24 hours. |
| `DOMOTZ_MCP_GET_NETWORK_CONFIGURATION` | Get network configuration | Fetch what a collector actually scans, to answer 'why isn't this device discovered?'. Read-only. Returns: - `discovery_settings`: the three flags bounding the scan. `broadcast_discovery` is the decisive one: ON means the collector sweeps its subnets and picks up devices as they connect; OFF means it only probes the IPs already known to the cloud plus the forced ones, so a new device is never found and a known device that changes IP via DHCP just goes offline (ONVIF, SSDP/UPnP and mDNS discovery stop too; external hosts keep being probed). `scan_all_interface_ips` OFF means only the FIRST address of each network interface defines a subnet to scan, so secondary addresses and VLAN sub-interfaces are never scanned - the usual cause on a multi-homed collector. `dhcp_device_discovery` ON reports devices seen asking for a DHCP lease but never answering a scan (they appear with no IP); it needs the collector to sit in the same broadcast domain. - `interfaces`: `attached` are the interfaces the collector is physically attached to - the subnet of each is scanned with ARP ping at layer 2, and `vlan_id` is the VLAN it is tagged with (null when untagged), so the VLANs the collector sits on are the non-null ones. `routed` mirrors the routed networks below. - `routed_networks`: subnets NOT reachable at layer 2, only through a router, so they are scanned without ARP ping and answered at layer 3 only. `scan_probes` is the probe set nmap runs for that network (ICMP echo/timestamp, TCP SYN or TCP ACK on given ports); null means the collector's default set, which is ICMP echo only - `advanced_discovery` is what adds the extra TCP probes. Those extra probes are one collector-wide configuration copied onto every network with the flag on, so `scan_probes` is identical across them - the per-network choice is only whether they apply. Devices found this way carry a synthetic MAC starting `CS:TM:` followed by the IP in hex. Public ranges cannot be routed networks. - `external_hosts`: single monitored addresses, the equivalent of a /32 routed network; they accept a hostname or an IP and may be public, and appear with a `EX:TN:` MAC. `external_host_scan_policy` is the ICMP/TCP probe set deciding whether they are up - one value for ALL external hosts of the collector, not per host. - `ip_scan_policy`: subsets of addresses to scan (layer 2 and layer 3 alike) - forced IPs or IP ranges, used to monitor specific addresses instead of whole subnets. - `interfaces_policy`: `policy` plus `rules`, patterns on the interface name where `*` is a wildcard. With `deny`, a matching interface is NOT scanned (no rule = every interface is scanned, the default); with `allow`, ONLY matching interfaces are scanned (no rule = nothing is scanned at all). - `unavailable`: sections whose backend read failed. They are returned empty as a fallback, so an empty section listed here means 'not read', NOT 'nothing configured' - never diagnose from it. Typical causes of a missing device: broadcast_discovery off, a subnet that needs a routed network, an interface excluded by the interfaces policy, or an address outside the IP scan policy. |
| `DOMOTZ_MCP_GET_ORGANIZATION` | Get organization | Get the full details of a single Organization by its internal `id`: name, `organization_id` (the caller-facing reference), its Contacts, and the ids of the Collectors bound to it. Use search_organizations or list_organizations first to resolve a name or organization_id to an `id`. |
| `DOMOTZ_MCP_GET_SNMP_CREDENTIALS_FORM` | Get snmp credentials form | Shows an interactive form to set or update SNMP credentials on a specific device.Only use this tool when the user explicitly asks to set, update, or change SNMP credentials for a deviceDo NOT use for listing, searching, or querying devices or collectors. |
| `DOMOTZ_MCP_GET_UPTIME` | Get uptime | Returns uptime stats for a collector or device over a time range: total uptime percentage, online_seconds, total_seconds, and the list of downtime intervals. If `device_id` is omitted the response covers collector uptime; if provided, it covers device uptime (with `agent_uptime` showing how much of that range the collector itself was online). The backend caps individual queries at 31 days; obi splits longer ranges into 31-day chunks (parallel) and merges them, with an obi-side ceiling of 90 days. `from`/`to` accept ISO 8601; default window is the last 7 days. |
| `DOMOTZ_MCP_INSPECT_DRIVER` | Inspect driver | Static analysis of a driver's JS against the Domotz sandbox. Two modes: pass `code`+`type` to analyze a DRAFT statelessly (nothing persisted — use this in the authoring loop while iterating), OR pass `driver_id` to inspect a SAVED driver (returns its stored `code`, code analysis, `code_is_valid`, `required_features`, and its declared `parameters`). Provide exactly one mode — not both, not neither. Returns `is_valid`, the list of analyzer errors, and a summary of which `D.*` APIs the code references. When an error points at a `D.*` symbol you don't recognize, read the per-symbol doc at MCP resource `domotz://sandbox/api/{symbol}` for signature, params, and examples (or `domotz://sandbox/api/catalog` for the full surface). Once `is_valid` is true, call `save_driver` to persist. |
| `DOMOTZ_MCP_LIST_ALERT_RULES` | List alert rules | Lists alert rule definitions in the account. Each rule defines a condition and threshold that, when matched, fires an alert. This tool returns the rule definitions (id, name, metric, function, operands, severity, attached devices/collectors). It does NOT return fired alerts — use `search_alerts` for those. Optional `entity` filter narrows to rules attached to devices (`device`) or collectors (`collector`). The `linked_entities` field shows where the rule is currently attached. `channel_ids` are not returned for existing rules — they're only available at rule creation time. Feeds `create_alert_rule` and `bind_alert_rule_to_device`. |
| `DOMOTZ_MCP_LIST_COLLECTOR_METRICS` | List collector metrics | Enumerate the metrics available on a collector — speed-test thresholds, IP-conflict status, collector uptime, security-issues counts, and the rest of the collector-scoped metric catalog. Use this to discover what can be alerted on at the collector level. Use the returned `metric` values as input to alert rule creation. |
| `DOMOTZ_MCP_LIST_COMMUNICATION_CHANNELS` | List communication channels | List the user's notification channels (email, webhook, Slack, etc.). Each channel has an id, endpoint, description, and type. Use to discover channel_ids before creating an alert rule via create_alert_rule (channel_ids is a required parameter). |
| `DOMOTZ_MCP_LIST_CONFIG_BACKUP_HISTORY` | List config backup history | Lists configuration backup snapshots for a device on a collector, newest first. When `running_md5` differs from `startup_md5` the device has unsaved changes (running config diverges from what would persist across reboot). `label` is user-mutable; `source` (user / custom_driver / internal_driver) records who took the snapshot. Use `next_before` as the `before` cursor to fetch the next page. `snapshot_timestamp` is the chain identifier consumed by `get_config_backup_entry` and `compare_config_backup`. |
| `DOMOTZ_MCP_LIST_DEVICE_DRIVERS` | List device drivers | Lists drivers currently attached to a device. Each binding returns the driver identity, the binding status, parameter values (with secrets pre-masked), and the list of executable actions (e.g. `validate`, `get-status`, `backup`, `restore`, `custom-N`) — pass an action's `action_id` to `execute_driver`. `status: DISABLED` ⇒ the binding cannot be executed even when `code_is_valid: true`; re-enable via the UI before retrying. Empty `actions[]` ⇒ the driver is not executable. |
| `DOMOTZ_MCP_LIST_DEVICE_METRICS` | List device metrics | List everything monitorable on a device. Returns the metric catalog (what CAN be alerted on — always populated, even at discovery time). Pass metric (prefix match) to also include the live variable instances for that metric, with variable_id needed for variable-level binding. When metric is omitted, only the metric catalog is returned — use this to browse what's available before drilling into a specific metric's variables. Follow up with list_metric_functions to discover valid thresholds for a metric, and list_variable_alert_rule_candidates to check whether a suitable alert rule already exists. |
| `DOMOTZ_MCP_LIST_DEVICE_PROFILES` | List device profiles | Lists device profiles in the account. A device profile bundles sensor definitions and credentials that can be applied to one or more devices. Use the returned `id` with `apply_device_profile`. The optional `view` parameter selects detail level: `summary` (default) returns module metadata only; `full` includes the per-module configuration JSON (~5x larger payload). Module types include SNMP_PRECONFIGURED_SENSOR, SNMP_CUSTOM_OID, TCP_SENSOR, CREDENTIAL, CUSTOM_TAG, INFO, SHARED_ALERT. `has_credentials` is true when the profile applies credentials (applying it will overwrite credentials on targeted devices). |
| `DOMOTZ_MCP_LIST_DEVICE_SENSORS` | List device sensors | Lists the sensors currently attached to a device, merged across CUSTOM_OID, TCP, CUSTOM_DRIVER, and PRECONFIGURED kinds. Every entry carries `kind`. CUSTOM_OID entries carry `id`, `name`, `oid`, `description`, `value_type`, `category`, `custom_name` — created via `attach_sensor(sensor_spec={kind:'custom_oid', ...})`. TCP entries carry `name`, `port`, `service`, `status`, `last_update`. CUSTOM_DRIVER entries carry `id` and `driver_name` (drivers, distinct from custom OIDs). PRECONFIGURED entries carry `id`, `name`, and `category` (overlays from `list_preconfigured_sensors`). Sibling tools: `device_inventory` for sensor counts only, `get_device_metrics` for time-series data, `list_preconfigured_sensors` for the account-wide overlay catalog. |
| `DOMOTZ_MCP_LIST_DEVICE_TYPES` | List device types | Returns the device-type catalog used to classify devices (router, switch, AP, server, etc.). Stable across calls within an API version. Each entry has an `id` (used as the `type_id` filter in `search_devices`) and a user-facing `label`. Use to discover valid type filters before constructing a search. |
| `DOMOTZ_MCP_LIST_DRIVER_TEMPLATES` | List driver templates | List shared driver templates the account can start from. Each entry returns `id` (use as `template_id` in `get_driver_template` and `save_driver`), `name`, `category`, `type`, and `version`. Templates are read-only starters; creating a driver from a template still produces a new, account-owned driver. |
| `DOMOTZ_MCP_LIST_METRIC_FUNCTIONS` | List metric functions | List the evaluation functions (e.g. GREATER_THAN, LESS_THAN, RANGE, CHANGED) available for a given metric name. Each function describes the comparison used to evaluate incoming variable values. Use to discover which threshold functions can be applied when creating or describing an alert rule. |
| `DOMOTZ_MCP_LIST_ORGANIZATIONS` | List organizations | List the account's Organizations with their Contacts and bound Collector ids. Each result carries the internal `id` (use it to address an organization) and the caller-facing `organization_id`. Optional filters (applied server-side): `name` (case-insensitive substring), `organization_id` (exact), `collector_id` (only the organization the collector is bound to). Sort by `name` (default) or `id`. |
| `DOMOTZ_MCP_LIST_PRECONFIGURED_SENSORS` | List preconfigured sensors | Returns the account-wide catalog of preconfigured sensors available to attach via `attach_sensor(sensor_spec={kind: 'overlay', overlay_id: ...})`. When `device_ids` is provided, each sensor includes a per-device `attached` flag indicating whether it is already attached to that device. Custom sensors (category=CUSTOM) are excluded. Sorted by `supported_device_count` descending — most-applicable first. Companion to `attach_sensor`. Distinct from `list_device_sensors` (per-device attached) and `get_device_metrics` (time-series data for a device). |
| `DOMOTZ_MCP_LIST_TAGS` | List tags | Returns the account-wide catalog of user-defined tags applied to devices and collectors. Each entry includes id, name, color, and the count of devices and collectors currently using it. For MSP accounts the tag namespace is account-wide (shared across organizations). Use to discover valid tag IDs before filtering in search_devices / search_collectors, assigning tags with `bind_tags`, or editing a tag with `update_tag`. |
| `DOMOTZ_MCP_LIST_VARIABLE_ALERT_RULE_CANDIDATES` | List variable alert rule candidates | List alert rules that could be bound to a specific device variable. Each candidate includes an 'attached' flag: true means the rule is already bound to this variable, false means it could be bound. Use this right before creating a new alert rule, to reuse an existing one when possible. |
| `DOMOTZ_MCP_MANAGE_EXTERNAL_HOSTS` | Manage external hosts | Add or remove an external host on a collector. An external host is a single address - a public or remote IP, or a hostname/FQDN - monitored as one device (the equivalent of a /32 routed network); public addresses are allowed here, unlike routed networks. - action='add': needs `host` (IP or hostname) and `name`. Optionally `device_type_id` (see `list_device_types`; defaults to the generic type). Returns the new `device_id`. - action='remove': needs `device_id`. DESTRUCTIVE and irreversible: it deletes the device record and its history. Get the id from `get_network_configuration` (external_hosts). Only external hosts can be removed here - an id that is not one is refused, use `delete_device` for a regular device. How external hosts are probed (the ICMP/TCP probe set deciding whether they are up) is NOT settable here: it is a single collector-wide value shared by every external host, so it cannot be changed for one of them. Read it with `get_network_configuration` (`external_host_scan_policy`) and change it from the web app. Adding an external host consumes the account's external-host and managed-device allowance; the backend rejects the call when either is exhausted. |
| `DOMOTZ_MCP_MANAGE_IP_SCAN_POLICY` | Manage ip scan policy | Manage the collector's forced IP scan policy: extra addresses the collector must probe on top of what it discovers by itself. Use it for a device that never answers a normal discovery scan (silent host, outside the interface's own subnet, ignores ARP/ICMP broadcast) so the collector keeps polling that address explicitly. This is an INCLUDE-only list: there is no way to exclude an address here - to reduce what gets scanned use `set_interfaces_policy`. - kind='ip', action='set': `ip_addresses` REPLACES the whole forced address list. Read the current one with `get_network_configuration` and send it back with your additions, or you will drop the others. - kind='ip', action='remove': removes the single `ip_address`. - kind='range', action='set': `ip_ranges` (list of {'start': ..., 'end': ...}) REPLACES the whole forced range list. start must be lower than end. - kind='range', action='remove': removes the single range identified by `ip_range_id`. Only IPv4. Public addresses are refused unless the account is allowed to use them, and the whole feature is plan-gated - the backend answers 403 when it is not enabled. |
| `DOMOTZ_MCP_MANAGE_ROUTED_NETWORKS` | Manage routed networks | Add, update or remove a routed network on a collector. A routed network is a subnet the collector cannot reach at layer 2 (no ARP), only through a router, so it is probed at layer 3 only; devices found there appear with a synthetic MAC address. Use it to monitor a subnet that lives behind a router. - action='add': needs `address`, `subnet_mask` and `name`. `subnet_mask` takes a dotted quad ('255.255.255.0') or a prefix length ('24'); it must be /24 or narrower, the range must be private (public ranges are rejected) and must not overlap an existing routed network nor one of the collector's own attached subnets. - action='update': needs `routed_network_id` plus the full new `address`/`subnet_mask`/`name` - it replaces, it does not patch. `advanced_discovery` is part of that replace: omit it and the network keeps the value it has now, pass it to change it. - action='remove': needs `routed_network_id`. DESTRUCTIVE: it also deletes every device discovered inside that subnet, with its history. `advanced_discovery` (add/update) widens the probe set from ICMP echo only to ICMP plus a few TCP probes, finding devices that drop ICMP but answer TCP, at the cost of a slower and noisier scan. The flag is the only per-network choice: which probes 'advanced' means is one collector-wide configuration, identical for every routed network that has the flag on, and it cannot be changed from here - read it in `get_network_configuration` (`scan_probes`). Read the current routed networks and their ids with `get_network_configuration` first. |
| `DOMOTZ_MCP_NETWORK_TOPOLOGY` | Network topology | Returns the network topology discovered by a single collector: device-to-device links and per-outlet (port) details. `view` controls detail level — `summary` returns infrastructure-only counts (~10 nodes), `standard` (default) returns full nodes and edges, `full` adds an upstream dependency map plus the inferred root (gateway). `max_links` (default 200) caps the returned edges; when truncated, `truncated: true` and `total_links` indicate that more exist. Use to understand network structure, identify single points of failure, or trace upstream paths. |
| `DOMOTZ_MCP_RESOLVE_ALERT` | Resolve alert | Permanently resolve one or more alert incidents. Resolution is IRREVERSIBLE — once resolved an incident cannot be re-opened. Domotz has no intermediate 'acknowledged-but-not-fixed' state; this tool transitions TRIGGERED / TRIGGERED_NO_AUTOMATIC incidents to RESOLVED. Bulk resolution is supported in a single call (pass an array of `unique_ids`). The optional `note` is captured in the audit trail. Source the UUIDs from `search_alerts.alerts[].unique_id`. |
| `DOMOTZ_MCP_SAVE_DRIVER` | Save driver | Create or update a driver on the account. Omit `driver_id` to CREATE a new driver (requires `name`, `code`, `type`); pass `driver_id` to UPDATE an existing one (only `code`, `description`, `timeout` are mutable — `name`/`type` are immutable here and rejected with `FIELD_NOT_ALLOWED`, change them in the UI). Account-scoped: no `collector_id` here — capability checks happen later via `get_collector_capabilities` or at execute time. On success returns `driver_id`, `code_is_valid`, and `required_features` (the `D.*` APIs the driver uses, useful for warning the customer if the target Collector lacks them), plus `result` (`CREATED` or `UPDATED`). On create, a name clash returns `result=NAME_CONFLICT`; on update, an unknown id returns `result=NOT_FOUND`. Iterate on `inspect_driver` until the code is valid before saving. Optional fields: `description`, `timeout` (0-120s), `credentials_required`, `template_id` (create only — start from a shared template). `credentials_required` (CRITICAL — getting this wrong silently breaks the driver): controls whether the sandbox receives the device's persisted credentials when the driver runs. - Set TRUE if the JS code uses ANY of: `D.device.username()`, `D.device.password()`, `D.device.credentials`, `D.device.sendSSHCommand`, `D.device.sendSSHShellSequence`, `D.device.sendWinRMCommand`, `D.device.sendTelnetCommand`, or HTTP options with `auth: 'basic'` and no inline username/password. - Set FALSE if the driver only makes anonymous HTTP calls, public-community SNMP reads, or passes inline credentials sourced from driver parameters (not from the device's stored creds). - If omitted, this tool auto-infers from the code (in BOTH create and update-with-`code`) by scanning for the patterns above and includes `credentials_required_auto_inferred: true` in the response so you can verify. Override explicitly when the heuristic is wrong (e.g. the code uses encrypted creds via custom params, or credentials are passed inline at execute time only). Why it matters: with `credentials_required=false`, the backend strips `device.device_access_keys` before dispatch — the driver runs but every credential-bearing call sees empty values and fails non-obviously (auth errors, empty username in SSH, etc). Choosing `type` (create only) — REQUIRED decision before writing any code: - `GENERIC`: monitor observable values over time (CPU, temperature, link state, counters, port up/down, service health). Implements validate() + get_status(). Returns metrics via `D.success([D.createMetric({uid, label, value, unit?}), ...])` — ALWAYS use `D.createMetric` as the first pick. `D.createVariable` (and `D.device.createVariable`) are the legacy fallback, used ONLY when the target Collector lacks `SandboxCapabilityMetrics` — confirm via `get_collector_capabilities` before emitting createVariable. Do NOT use GENERIC to capture device configuration text. - `CONFIGURATION_MANAGEMENT`: snapshot the device's configuration (switch/router running-config and startup-config, firewall rules, AP config). Implements validate() + backup(). Returns config blobs via `D.success(D.createBackup({running, startup}))`. Do NOT use this type to emit metrics. Decision rule: is the output numeric/state values to chart over time, or a text blob representing device config? Metrics → GENERIC. Config text → CONFIGURATION_MANAGEMENT. BEFORE writing code, read MCP resources `domotz://sandbox/types` (driver type contracts with `purpose`, `when_to_use`, `output_shape`, and example use cases per type), `domotz://sandbox/skeleton/{driver_type}` (minimal valid starter with inline intent comments), and `domotz://sandbox/api/catalog` (every `D.*` symbol with signature, params, min sandbox version, and examples). Each `D.*` symbol is also readable individually via `domotz://sandbox/api/{symbol}`. |
| `DOMOTZ_MCP_SEARCH_ALERTS` | Search alerts | Search alert history with filters. Returns both active and historical alerts. Each result carries the `unique_id` UUID (the chain identifier into `resolve_alert(unique_ids=[...])`), the `status`, `severity`, `triggered_at`/`closed_at`, the `trigger_function_repr` + `trigger_value` that fired the rule, and a `context` block with device/collector/profile snapshots. status ∈ TRIGGERED / TRIGGERED_NO_AUTOMATIC / CLOSED / RESOLVED — open alerts are TRIGGERED ∪ TRIGGERED_NO_AUTOMATIC. Default sort: triggered_at descending. Pass `unique_ids=[…]` to fetch specific incidents by UUID (exact match) — use this when you already know which incident(s) you want, instead of filtering by device/time and hunting through the result page. |
| `DOMOTZ_MCP_SEARCH_AUDIT_LOGS` | Search audit logs | Search Domotz audit logs for the caller's organization. Filter by time range, operation type/category, target entity, actor, outcome status, and source application. Timestamps may be ISO 8601 strings (e.g. '2026-06-12T10:00:00Z') or integer epoch seconds. Valid `target_entity_type` values: USER, COLLECTOR, DEVICE, DEVICE_PROFILE, USER_CREDENTIALS, ALERT_RULE, ALERT, CUSTOM_FILTER, CUSTOM_TAG (the monitoring appliance is a 'COLLECTOR'). Results are sorted by event_timestamp descending by default. |
| `DOMOTZ_MCP_SEARCH_COLLECTORS` | Search collectors | Search and list Domotz collectors with filtering and pagination (zero-based: first page is page=0). filter_by keys: name, collector_id, status (ONLINE/OFFLINE), health_status (HEALTHY/ISSUES/DOWN), organization_id, tag_ids (list, AND-ed), ip_prefix, owner_name, text_match (fuzzy across name/vendor/IP/owner). Returns data in three detail levels: 'summary' (id, name, status, ip, organization), 'standard' (default - adds tags, counters, platform, mac), 'detailed' (all available fields including licence, monitoring mode, software version). Use this tool to discover which collectors exist and their current state. |
| `DOMOTZ_MCP_SEARCH_DEVICES` | Search devices | Cross-account device search with filters and pagination (zero-based: first page is page=0). Supports filtering by text_match, name, ip_mac, vendor, model, collector_ids, status (ONLINE/OFFLINE), type_ids, tag_ids, organization_id, serial, room, zone, credential_types, credential_status, importance (important or not important), monitoring_state (device managed or device unmanaged), and device_id. Note: ONLINE includes devices within the heartbeat grace period; OFFLINE means the device has been unreachable past the grace period. Returns data in three detail levels: 'summary' (id, name, status, ip, collector_id, type), 'standard' (default - adds mac, vendor, model, importance, tags, organization, first_seen), 'detailed' (all fields including serial_number, zone, credentials/alerts/snmp flags). The 'detailed' view includes a `protocol` field describing how a device is represented: 'ip' (a standard network device with its own IP address); 'grouped' (a device that merges multiple network interfaces (NICs) on the same physical host into one logical device - it is online if any of its member interfaces is online, and the member interfaces are represented by this single grouped device); 'logical' (a manually-managed placeholder device with no IP - its status is set manually, not auto-monitored). Use this tool to discover and filter devices across your network. When presenting results, always refer to devices by name, not just by ID. |
| `DOMOTZ_MCP_SEARCH_ORGANIZATIONS` | Search organizations | List and filter the organizations visible to the calling user. The discovery entry-point for multi-tenant workflows: resolve an organization name to an `id` before scoping subsequent calls (e.g., `search_collectors`, `search_devices`). MSP accounts typically have many organizations; single-org accounts return a single result. `with_offline_collectors_only` narrows to organizations with at least one offline collector. The chain: `search_organizations` → `search_collectors` → `search_devices`. |
| `DOMOTZ_MCP_SET_COLLECTOR_DEFAULT_SNMP_CREDENTIALS` | Set collector default snmp credentials | Set the collector's DEFAULT SNMP credentials — the ones used for devices that have no SNMP credentials of their own. Devices already configured keep theirs: to change one of those use `set_device_credential`. `credential_spec.version` selects the family: V1/V2 require `community` (optional `write_community`); V3_NO_AUTH requires `username`; V3_AUTH_NO_PRIV adds `authentication_protocol` + `authentication_key`; V3_AUTH_PRIV adds `encryption_protocol` + `encryption_key`. Protocol names carry hyphens: MD5 / SHA / SHA-224 / SHA-256 / SHA-384 / SHA-512 for authentication, DES / AES / AES-256B / AES-256R for encryption. OVERWRITES any default previously set on the collector. The feature is licensed: on plans without it the tool returns `error=FEATURE_NOT_AVAILABLE`. Never include the community string or any key in a user-visible message. Use `collector_overview` to read back which version is configured (secrets are never returned). |
| `DOMOTZ_MCP_SET_DEVICE_CREDENTIAL` | Set device credential | Set or overwrite a device credential. `credential_spec.kind` selects the credential family. Access keys (SSH / HTTP / HTTPS / TELNET / WINRM / ONVIF) require {username, password} and accept optional `purpose` (DEVICE_MANAGEMENT default, also CONFIGURATION_MANAGEMENT / CUSTOM_DRIVER_MANAGEMENT / OS_MANAGEMENT). When purpose=CUSTOM_DRIVER_MANAGEMENT you MUST also pass `driver_id`. SNMP variants: SNMPv1/SNMPv2 require `community` (optional `write_community`); SNMPv3_NO_AUTH requires `username`; SNMPv3_AUTH_NO_PRIV adds `authentication_protocol` + `authentication_key`; SNMPv3_AUTH_PRIV adds `encryption_protocol` + `encryption_key`. OVERWRITES the existing credential of the same kind/purpose. Validation is asynchronous on the collector — re-fetch with `get_device_credentials` after a few seconds. If the collector is unreachable the call returns `result=CREDENTIALS_SAVED_VALIDATION_TIMEOUT` — credentials are saved, retry later. Never include secrets in any user-visible message. For SNMP credentials specifically, when the client renders HTML UI (Claude Desktop, Claude.ai web), prefer `get_snmp_credentials_form` for a guided form-based flow; this tool remains the canonical text alternative. |
| `DOMOTZ_MCP_SET_DEVICE_POWER` | Set device power | Change the power state of a device: turn it `on`, hold it `off`, `cycle` it, or issue a `software_reboot`. `on`/`off`/`cycle` act on the outlet of the PoE switch or PDU the device is plugged into; `software_reboot` is a management command sent to the device itself. Unlike `cycle`, an `off` is durable — the device stays powered off until an explicit `on`, so a Power Off / wait / Power On sequence is two calls. The call is asynchronous (HTTP 202): the response confirms DISPATCH, not completion — re-query `device_inventory` or `get_uptime` to confirm the outcome. obi pre-checks the device's power capabilities and returns NOT_SUPPORTED with a `reason` instead of dispatching when the requested action is unavailable. Address the device by its own `device_id`: the host device and outlet are resolved for you. |
| `DOMOTZ_MCP_SET_INTERFACES_POLICY` | Set interfaces policy | Set which of the collector's own network interfaces take part in discovery, by name. Rules are interface-name patterns where `*` is the only wildcard (e.g. 'eth0', 'docker*', 'br-*'); matching is case-insensitive. This REPLACES the current policy - send the full set of rules you want, not a delta. - policy='deny' with rules: every interface is scanned EXCEPT the ones matching. This is how you stop the collector scanning a noisy or irrelevant interface (a container bridge, a VPN tunnel). - policy='deny' with no rules: the default - every interface is scanned. - policy='allow' with rules: ONLY matching interfaces are scanned. - policy='allow' with no rules: nothing at all is scanned, so no device is discovered or monitored on any subnet. Rejected here as it is almost never intended. At most 10 rules, each at most 20 characters. Use `get_network_configuration` first: it lists the collector's actual interface names and the policy in force. |
| `DOMOTZ_MCP_SNOOZE_COLLECTOR_ALERTS` | Snooze collector alerts | Snooze (temporarily mute) all alerting for a collector for a maintenance window. Equivalent to 'Snooze Agent Alerts' in the UI: alerting is suppressed now and automatically resumes when the window ends. Specify the window with EITHER `until` (an absolute ISO 8601 timestamp, e.g. '2026-07-01T18:30:00Z') OR `duration_minutes` (a relative number of minutes from now) - provide exactly one. Snoozing is a collector-level maintenance window and applies to the whole collector (individual devices cannot be snoozed); use `unsnooze_collector_alerts` to resume alerting before the window ends. |
| `DOMOTZ_MCP_SUBMIT_FEEDBACK` | Submit feedback | Submit feedback about a gap in available MCP tools or data. Use this ONLY when you searched for a tool but could not find one, got incomplete results from an existing tool, or a tool was missing a needed parameter. Required: what_i_needed, what_i_tried, gap_type. gap_type must be one of: missing_tool, incomplete_results, missing_parameter, wrong_format, other. |
| `DOMOTZ_MCP_UNBIND_ALERT_RULE_FROM_COLLECTOR` | Unbind alert rule from collector | Unbind an alert rule from a collector. Removes the bindings of all of the collector's variables to the rule — the rule definition itself stays. Use after `bind_alert_rule_to_collector` or to clean up a rule that is no longer relevant for the collector. Idempotent: unbinding a rule that is not bound returns status=NOT_FOUND (no error). |
| `DOMOTZ_MCP_UNBIND_ALERT_RULE_FROM_DEVICE` | Unbind alert rule from device | Unbind an alert rule from a device. Removes the bindings of all of the device's variables to the rule — the rule definition itself stays. Use after `bind_alert_rule_to_device` or to clean up a rule that is no longer relevant for the device. Idempotent: unbinding a rule that is not bound returns status=NOT_FOUND (no error). |
| `DOMOTZ_MCP_UNBIND_COLLECTOR_FROM_ORGANIZATION` | Unbind collector from organization | Unbind a Collector from an Organization (addressed by its internal `id`). The Collector is not deleted, only detached from the Organization. |
| `DOMOTZ_MCP_UNSNOOZE_COLLECTOR_ALERTS` | Unsnooze collector alerts | Resume alerting on a collector immediately, cancelling any active snooze/maintenance window set by `snooze_collector_alerts`. Safe to call even if the collector is not currently snoozed. |
| `DOMOTZ_MCP_UPDATE_ALERT_RULE` | Update alert rule | Update an existing alert rule in place, preserving its device/collector/variable bindings and alert history (unlike deleting and recreating). Only the fields you pass are changed; omitted fields keep their current value. Editable fields: `name`, `severity` (Critical / High / Warning / Info), `function` (a name like 'GREATER_THAN' or a numeric function_id), `operands`, `operands_unit`, and `channel_ids` (the full set of notification channels the rule should use; channels not listed are detached, so an empty list is rejected). When changing `function`, call `list_metric_functions` first to confirm the valid functions and their required operand count. The rule's target `metric` is IMMUTABLE and cannot be changed here: retarget by deleting the rule and creating a new one. Use `list_alert_rules` to discover valid IDs. Updating a non-existent rule returns status=NOT_FOUND (no error). |
| `DOMOTZ_MCP_UPDATE_COLLECTOR_METADATA` | Update collector metadata | Update editable metadata on a collector (the on-site monitoring agent). Editable fields: `name` (the collector's display name), `time_zone` (an IANA time zone such as 'Europe/Rome'), and the postal address fields `address` (street address), `city`, `state`, `country`, `post_code`. This is a partial update: only the fields you pass are changed, the rest are left untouched. Pass at least one field -- empty calls are rejected. Use `search_collectors` to find the `collector_id`. |
| `DOMOTZ_MCP_UPDATE_COLLECTOR_MONITORING_SETTINGS` | Update collector monitoring settings | Update how the collector monitors, as opposed to what it monitors. This is a partial update: only the fields you pass are changed. Pass at least one — empty calls are rejected. `sensor_hourly_frequency` is how many readings per hour every sensor on the collector takes, SNMP sensors included. It is READINGS PER HOUR, not minutes, and only the five cadences the product supports are accepted — users and the web app talk in minutes, so convert: 2 = every 30 minutes, 4 = every 15 minutes, 6 = every 10 minutes, 12 = every 5 minutes, 30 = every 2 minutes. The licence caps the maximum: above it the tool returns `error=FREQUENCY_EXCEEDED` and nothing is changed — lower the value or tell the user their plan does not allow that cadence. Read the current value back with `collector_overview`. |
| `DOMOTZ_MCP_UPDATE_CONTACT` | Update contact | Update a Contact on the Organization with the given internal `id`. `name` and `email` are required (the full contact is replaced); `mobile_phone` and `phone` are optional. |
| `DOMOTZ_MCP_UPDATE_DEVICE_METADATA` | Update device metadata | Update editable metadata fields on a device: `name`, `importance` (important or not important), `zone`, `room`, `serial`, `notes` (max 256 chars). To clear a field, pass the sentinel value `"__clear__"` (passing an empty string also works but may be dropped by some clients). Tags can be managed with `add_tag_ids` / `remove_tag_ids`. Per-field outcomes are reported in the response so partial successes are visible. Pass at least one field — empty calls are rejected. |
| `DOMOTZ_MCP_UPDATE_DEVICE_MONITORING_STATE` | Update device monitoring state | Manage or unmanage one or more devices by changing their monitoring state. This is the ONLY way to manage or unmanage devices. When the user asks to 'manage', 'start monitoring', 'add to monitoring', or 'enable monitoring' for devices, use this tool with monitoring_state='managed'. When they ask to 'unmanage', 'stop monitoring', 'remove from monitoring', or 'disable monitoring', use monitoring_state='unmanaged'. Accepts a single device_id (int) or a list of device_ids (list[int]) for bulk operations — all devices must belong to the same collector. Managed devices consume a licence slot and are actively monitored (alerts, uptime tracking, etc.); unmanaged devices are visible in the network inventory but not actively monitored. IMPORTANT: monitoring_state (managed/unmanaged) is NOT the same as importance (important/not important). They are independent properties. 'not important' means low-priority, 'unmanaged' means not monitored at all. When the result is LIMIT_EXCEEDED and a checkout_url is present, always ask the user if they want to see the upgrade link — do not silently discard it. Fails with LOCATION_BASED_LICENSING when the collector uses location-based licensing (all devices are automatically monitored). Use `search_devices` to check the current monitoring_state before calling this tool. |
| `DOMOTZ_MCP_UPDATE_ORGANIZATION` | Update organization | Update an existing Organization by its internal `id`. Only the fields you pass are changed (omit a field to leave it untouched). Updating just the name will not clear the organization_id. `organization_id` is the caller-facing reference (organa's external_reference). |
| `DOMOTZ_MCP_UPDATE_TAG` | Update tag | Rename an existing user-defined tag, change its colour, or both. This is a partial update: omit a field to leave it untouched, and pass at least one -- empty calls are rejected. `color` is cosmetic and user-visible, so change it only when the user asked for a specific colour; valid values are in the `color` enum. Devices and collectors already carrying the tag keep it; only its name and colour change. A name already used by another tag returns ALREADY_EXISTS. Use `list_tags` to discover valid IDs. Requires the manage_device_tags permission. |

## Supported Triggers

None listed.

## Creating MCP Server - Stand-alone vs Composio SDK

Once connected, ChatGPT Work can access the Domotz MCP server via Composio to run actions that you authorize, directly in your workspace.

## Complete Code

None listed.

## How to build Domotz MCP Agent with another framework

- [Claude Cowork](https://composio.dev/toolkits/domotz_mcp/framework/claude-cowork)
- [Hermes](https://composio.dev/toolkits/domotz_mcp/framework/hermes-agent)

## Related Toolkits

- [Supabase](https://composio.dev/toolkits/supabase) - Supabase is an open-source backend platform offering scalable Postgres databases, authentication, storage, and real-time APIs. It lets developers build modern apps without managing infrastructure.
- [Codeinterpreter](https://composio.dev/toolkits/codeinterpreter) - Codeinterpreter is a Python-based coding environment with built-in data analysis and visualization. It lets you instantly run scripts, plot results, and prototype solutions inside supported platforms.
- [GitHub](https://composio.dev/toolkits/github) - GitHub is a code hosting platform for version control and collaborative software development. It streamlines project management, code review, and team workflows in one place.
- [1password](https://composio.dev/toolkits/_1password) - 1Password is a password manager and digital vault for storing logins, secrets, notes, and secure documents. It helps individuals and teams protect credentials, share access safely, and reduce password risk.
- [Ably](https://composio.dev/toolkits/ably) - Ably is a real-time messaging platform for live chat and data sync in modern apps. It offers global scale and rock-solid reliability for seamless, instant experiences.
- [Abuselpdb](https://composio.dev/toolkits/abuselpdb) - Abuselpdb is a central database for reporting and checking IPs linked to malicious online activity. Use it to quickly identify and report suspicious or abusive IP addresses.
- [Alchemy](https://composio.dev/toolkits/alchemy) - Alchemy is a blockchain development platform offering APIs and tools for Ethereum apps. It simplifies building and scaling Web3 projects with robust infrastructure.
- [Algolia](https://composio.dev/toolkits/algolia) - Algolia is a hosted search API that powers lightning-fast, relevant search experiences for web and mobile apps. It helps developers deliver instant, typo-tolerant, and scalable search without complex infrastructure.
- [Anchor browser](https://composio.dev/toolkits/anchor_browser) - Anchor browser is a developer platform for AI-powered web automation. It transforms complex browser actions into easy API endpoints for streamlined web interaction.
- [Apiflash](https://composio.dev/toolkits/apiflash) - Apiflash is a website screenshot API for programmatically capturing web pages. It delivers high-quality screenshots on demand for automation, monitoring, or reporting.
- [Apiverve](https://composio.dev/toolkits/apiverve) - Apiverve delivers a suite of powerful APIs that simplify integration for developers. It's designed for reliability and scalability so you can build faster, smarter applications without the integration headache.
- [Appcircle](https://composio.dev/toolkits/appcircle) - Appcircle is an enterprise-grade mobile CI/CD platform for building, testing, and publishing mobile apps. It streamlines mobile DevOps so teams ship faster and with more confidence.
- [Appdrag](https://composio.dev/toolkits/appdrag) - Appdrag is a cloud platform for building websites, APIs, and databases with drag-and-drop tools and code editing. It accelerates development and iteration by combining hosting, database management, and low-code features in one place.
- [Appveyor](https://composio.dev/toolkits/appveyor) - AppVeyor is a cloud-based continuous integration service for building, testing, and deploying applications. It helps developers automate and streamline their software delivery pipelines.
- [Authyo](https://composio.dev/toolkits/authyo) - Authyo is a REST API service for passwordless authentication, OTP verification, session management, and transactional notifications. Use it to add secure login flows and user verification without building auth infrastructure from scratch.
- [AWS Marketplace MCP](https://composio.dev/toolkits/aws_marketplace_mcp) - AWS Marketplace MCP provides MCP access to AWS Marketplace's cloud software, data, and services catalog. Use it to discover, compare, and evaluate 30K+ AWS Marketplace listings faster.
- [Backendless](https://composio.dev/toolkits/backendless) - Backendless is a backend-as-a-service platform for mobile and web apps, offering database, file storage, user authentication, and APIs. It helps developers ship scalable applications faster without managing server infrastructure.
- [Baserow](https://composio.dev/toolkits/baserow) - Baserow is an open-source no-code database platform for building collaborative data apps. It makes it easy for teams to organize data and automate workflows without writing code.
- [Bench](https://composio.dev/toolkits/bench) - Bench is a benchmarking tool for automated performance measurement and analysis. It helps you quickly evaluate, compare, and track your systems or workflows.
- [Better stack](https://composio.dev/toolkits/better_stack) - Better Stack is a monitoring, logging, and incident management solution for apps and services. It helps teams ensure application reliability and performance with real-time insights.

## Frequently Asked Questions

### What are the differences in Tool Router MCP and Domotz MCP?

With a standalone Domotz MCP server, the agents and LLMs can only access a fixed set of Domotz tools tied to that server. However, with the Composio Tool Router, agents can dynamically load tools from Domotz and many other apps based on the task at hand, all through a single MCP endpoint.

### Can I use Tool Router MCP with ChatGPT Work?

Yes, you can. ChatGPT Work fully supports MCP integration. You get structured tool calling, message history handling, and model orchestration while Tool Router takes care of discovering and serving the right Domotz tools.

### Can I manage the permissions and scopes for Domotz while using Tool Router?

Yes, absolutely. You can configure which Domotz scopes and actions are allowed when connecting your account to Composio. You can also bring your own OAuth credentials or API configuration so you keep full control over what the agent can do.

### How safe is my data with Composio Tool Router?

All sensitive data such as tokens, keys, and configuration is fully encrypted at rest and in transit. Composio is SOC 2 Type 2 compliant and follows strict security practices so your Domotz data and credentials are handled as safely as possible.

---
[See all toolkits](https://composio.dev/toolkits) · [Composio docs](https://docs.composio.dev/llms.txt)