Domotz – Network Monitoring

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`.

compare_config_backup

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.

create_alert_rule

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.

create_contact

Creates an empty device profile in the account. A device profile bundles sensor definitions and credentials that can be applied to devices in one go. The new profile has no modules yet, so applying it changes nothing until content is added to it - report the profile as created, not as ready to apply. Returns the new `id`, which `update_device_profile`, `apply_device_profile` and `delete_device_profile` all take. Reversible via `delete_device_profile`. Names are not unique and this tool is not idempotent: if a call fails without telling you whether the profile was created, check with `list_device_profiles` before calling again, or you will end up with two profiles of the same name.

create_device_profile

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.

create_organization

Open a temporary remote connection to one port of one device behind a collector, and return how to reach it. For `rdp`, `ssh` and `telnet` the answer is a `web_portal` URL that opens a Domotz browser session against the device; `http`/`https` proxy the device's own web interface the same way; `tcp` instead returns a `tcp_endpoint` (host + port) to dial with a local client. TREAT THE RETURNED URL AS A CREDENTIAL: anyone holding it reaches the device with no further authentication until the connection expires, so hand it only to the person who asked and never store it. The connection consumes the customer's remote-access allowance and holds a container until it expires or is closed — close it with `close_remote_connection` as soon as it is no longer needed. Source `device_id` and the open port from `device_inventory` / `get_device_interfaces`. If a web-portal connection for the same device, port and protocol is already open it is returned instead of a second one being created, with `reused: true` and no URL (the one issued at creation cannot be re-derived), so close it and call again for a fresh link. A `tcp` call always opens a new connection: its endpoint only answers the `public_ip` it was opened for, so an existing one cannot be handed to a different caller.

create_remote_connection

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.

create_tag

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`.

cycle_outlet_power

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).

delete_alert_rule

Permanently delete a Contact from the Organization with the given internal `id`. This cannot be undone.

delete_contact

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.

delete_device

Permanently deletes a device profile and everything it contains. This cannot be undone. It does NOT undo anything the profile already applied: sensors and credentials written to devices by earlier applies stay exactly as they are, so deleting a profile is not a way to roll one back. Any schedule on the profile is removed with it, so a scheduled apply stops. Check the profile with `list_device_profiles` first, so you can name what is being deleted.

delete_device_profile

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.

delete_driver

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.

delete_organization

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.

delete_tag

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).

detach_driver

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).

detach_sensor

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.

device_inventory

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.

device_performance

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.

execute_driver

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.

get_account_info

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.

get_audit_log_filters

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.

get_collector_alert_rule_bindings

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.

get_collector_capabilities

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`.

get_collector_credential_coverage

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.

get_config_backup_entry

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.

get_config_backup_status

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.

get_device_alert_rule_bindings

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.

get_device_alerts

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`.

get_device_credentials

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).

get_device_history

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.

get_device_interfaces

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`.

get_device_metrics

Lists device-profile apply jobs for the account: which profile was applied, who submitted it, when it started and ended, how it finished, and which devices failed. Use it to answer whether an earlier apply succeeded without applying anything again. Applies still in progress are included: they come back with `in_flight` true, a non-terminal `status` (PENDING or RUNNING) and no `end_date`. An in-flight row means the apply is still going: wait for it. A second apply of the same profile is refused with a conflict while one is running, so retrying is not just wasteful, it fails. `failed_count` and `failed_device_ids` are present only when `details_recorded` is true; until then the per-device outcome is not written yet and their absence must not be read as nothing having failed. Optional filters: `profile_id`, `status` (RUNNING, COMPLETED, FAILED, CANCELLED), and `limit` (default 20, max 100). `author` is absent when the submitter cannot be named - a deleted user, or an apply no person submitted - so a missing author is not the same as an unattributed apply. IMPORTANT: this returns a bounded, recent slice of the account's apply jobs, not a complete record, and `profile_id` filters that slice rather than searching the profile's whole history. `job_count` 0 therefore means no matching apply is in the slice, NOT that the profile has never been applied - on its own it is never a reason to apply again. A call that fails answers with an `error` field instead, so an empty list is always a real answer and not a hidden failure. A job names its failed devices but not why each one failed.

get_device_profile_job_history

Get how a Collector is linked to a documentation system: the linked organization, the device<->asset bindings, and whether auto-sync is on. Returns a clear 'not linked' status when the collector has no organization linked in that documentation system. Provide `documentation_system_name` (see list_supported_integrations). Use manage_documentation_link to link or unlink.

get_documentation_integration

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.

get_driver_catalog

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`.

get_driver_template

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.

get_interface_traffic

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. The three `discovery_settings` flags are changed with `update_collector_settings`; everything else here has its own write tool (`manage_routed_networks`, `manage_external_hosts`, `manage_ip_scan_policy`, `set_interfaces_policy`). 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.

get_network_configuration

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`.

get_organization