[Action1] Create a new organization within the Action1 enterprise. Side effect: creates a new org tenant. The fieldsJson MUST include both `name` and `description` (e.g. {"name":"Contoso","description":"Primary client tenant"}). Use action1_list_organizations afterward to discover the new orgId.

[Action1] Permanently delete an organization. Side effect: irrevocably removes the org and all its endpoints, deployers, automation schedules, and reports. This action CANNOT be undone. Use action1_list_organizations to confirm the orgId before deleting.

[Action1] List organizations within the current Action1 enterprise. Returns org IDs (GUIDs) you'll need for org-scoped tools like action1_list_endpoints, action1_search, and action1_list_endpoint_groups. When admin=true, returns every org the calling user can administer instead of only their default scope. Default 50, max 100. The response includes `next_page` and `prev_page` cursors — pass `next_page.from` as `from` to fetch the next page until no `next_page` is returned. MSPs with more than 100 orgs MUST page through all results when feeding org IDs into cross-org analytics tools.

[Action1] Update properties on an existing organization. Side effect: modifies org metadata. Only include fields you want to change in fieldsJson (e.g. {"name":"New Name","description":"Updated"}). Use action1_list_organizations to find valid orgIds.

[Action1] Retrieve metadata about the current Action1 enterprise (the root tenant that contains all organizations). Returns enterprise name, settings, and pending closure status. Use this to verify connectivity and see top-level branding/policy values.

[Action1] Request closure (deletion) of the entire Action1 enterprise. Side effect: schedules irreversible teardown of every organization, endpoint, and configuration in this tenant. Action1 will retain a closure window during which action1_revoke_enterprise_closure can cancel the request. Use with extreme caution. Vendor requires a non-empty 'reason' explaining why closure is requested.

[Action1] Cancel a previously requested enterprise closure during the grace window. Side effect: aborts the scheduled teardown so the enterprise remains active. Idempotent — replaying after the closure is already revoked is a no-op. Vendor requires a non-empty 'reason' explaining why the closure is being revoked.

[Action1] Update enterprise-level settings. Side effect: modifies global enterprise configuration that affects every organization in the tenant. The vendor's `EnterprisePayload` PATCH schema only accepts `name` and `description` — other enterprise properties are read-only on this endpoint. Only include fields you want to change.

[Action1] Create a new user. Side effect: provisions a new identity in the enterprise. The body must match one of three vendor schemas: (a) Interactive Action1 user — required: email, password, first_name, last_name; (b) Interactive SSO user — required: email (and the SSO IdP must be pre-configured at the enterprise level); (c) API credentials — required: first_name, email, password, enabled, user_type:'API'. The wire field is `user_type`; valid values are 'Interactive' and 'API' (no 'sso' value — SSO is determined by your enterprise IdP config). Verify with action1_list_users afterward.

[Action1] Permanently delete a user from the enterprise. Side effect: removes the user identity and revokes any role assignments and API credentials they own. This cannot be undone. Verify the userId with action1_list_users first.

[Action1] Retrieve the profile of the currently authenticated user (the API credential's owning user). Returns the user's ID, email, timezone, and session timeout. Use this to confirm which identity the connector is using.

[Action1] Retrieve a single user by ID. Returns full user metadata including type, email, status, and timestamps. Use action1_list_users to discover valid IDs.

[Action1] List the roles assigned to a specific user. Returns role IDs and names. Use this together with action1_list_roles to understand a user's permissions footprint.

[Action1] List all users in the enterprise (interactive admins, SSO users, and API service accounts). Returns user IDs, emails, and types. Use the IDs with action1_get_user, action1_list_user_roles, or role-assignment tools. Note: Action1's /users endpoint does not support a sort parameter — narrow results via `filter` or `userType`.

[Action1] Update settings on the currently authenticated user. Side effect: modifies the calling user's preferences. Only `timezone` and `session_timeout` are updatable via this endpoint (e.g. {"timezone":"America/Chicago","session_timeout":3600}).

[Action1] Update an existing user's properties. Side effect: modifies the user record. The PATCH body matches one of three vendor schemas (oneOf) — editable fields differ by user type: API user PATCH only accepts email, password, first_name; Interactive user PATCH accepts email, first_name, last_name, phone, timezone, session_timeout, enabled. Only include fields you want to change. Use action1_get_user first to inspect the current shape, and action1_list_users to find valid IDs.

[Action1] Assign a user to a role. Side effect: grants the user every permission in the role's bundle. Idempotent — re-assigning a user already in the role is a no-op.

[Action1] Clone an existing role into a new role with the same permission set. Side effect: creates a fresh role; rename it via action1_update_role afterwards. No body is sent to this endpoint — replaying creates a new role each time, so the operation is not replay-safe.

[Action1] Create a new role. Side effect: defines a new permission bundle that can be assigned to users. Required fields: `name`, `description`, and `scoped_permissions` (an array of permission grants). Each entry in `scoped_permissions` requires `permission` (e.g. 'view_reports' — list with action1_list_permission_templates), `include_scope` (array — what the permission applies to), and `exclude_scope` (array — exclusions). Optional `restrictions` per entry can cap endpoint counts or types for `run_automations`/`manage_automations` permissions.

[Action1] Permanently delete a role. Side effect: revokes the role from every user that held it, potentially leaving them without administrative access. This cannot be undone. Confirm with action1_list_role_users first.

[Action1] Retrieve a single role by ID, including its full permission set. Use action1_list_roles to discover valid IDs.

[Action1] List the available permission templates Action1 ships with. Use these as building blocks (or starting points) when creating or updating roles via action1_create_role / action1_update_role.

[Action1] List every user assigned to a given role. Returns user IDs and emails. Use this before deleting or modifying a role to understand impact.

[Action1] List all roles defined in the enterprise. Returns role IDs and names. Roles map users to bundles of permissions; use IDs with action1_get_role, action1_list_role_users, or assignment tools. Pass `fields=*` or `fields=users` to retrieve the role's user count.

[Action1] Remove a user's assignment to a role. Side effect: revokes the role's permissions from that user. The user remains in the enterprise but loses any access uniquely granted by this role. Idempotent — re-removing a user already absent from the role is a no-op.

[Action1] Update properties on an existing role (name, description, permission set). Side effect: changes the access granted to every user who holds this role. Only include fields you want to change in fieldsJson.

[Action1] Permanently remove an endpoint from the organization and uninstall its agent. Side effect: irreversibly removes the endpoint. Use action1_list_endpoints first to find valid endpointId values.

[Action1] Returns a download URL for the Action1 agent installer for the specified organization. Use this URL to manually deploy the agent on endpoints; for automated network-wide deployment see action1_get_deployer_installation_url. Note this is the per-endpoint AGENT, not the network Deployer service. Use action1_list_organizations to find valid orgId values.

[Action1] Get full details for a single endpoint including hardware, OS, agent version, custom fields, and group membership. Use action1_list_endpoints first to find valid endpointId values.

[Action1] Returns 'Yes'/'No' indicating whether any endpoints are deployed in the org. Use this as a quick precheck before calling action1_list_endpoints. Use action1_list_organizations to find valid orgId values.

[Action1] List all missing OS and third-party software updates for a single endpoint with offset-based pagination. Returns update IDs, KB numbers, severity, and release dates. Use action1_list_endpoints to find valid endpointId values; for organization-wide missing updates use the patches/updates tools.

[Action1] List all endpoints (managed devices) in the organization with offset-based pagination. Returns endpoint GUIDs, hostnames, OS, last seen timestamps, status, and group membership. Use endpoint IDs with action1_get_endpoint, action1_list_endpoint_missing_updates, and action1_start_remote_session. Use action1_list_organizations to find valid orgId values.

[Action1] Move an endpoint from its current organization to another organization in the same enterprise. JSON body REQUIRED field: target_organization_id (UUID of the destination org). Example: {"target_organization_id":"9844e782-2506-7488-f599-a5693ce52109"}. Side effect: re-parents the endpoint and may re-apply policies. Replaying with the same target_organization_id once the endpoint already lives there is a no-op. Use action1_list_organizations to find both source and destination IDs.

[Action1] Update mutable endpoint properties. Supported writeable fields: name, comment, and any custom: key (the attribute must be predefined in Action1 Advanced Settings). Side effect: modifies endpoint metadata. Examples: {"name":"Conference Room PC"}; {"comment":"Replaced HDD 2026-01"}; {"custom:Graphic Adapter":"NVidia RTX 4080"}. Use action1_list_endpoints first to find valid endpointId values.

[Action1] Create a new endpoint group in the organization. Side effect: creates a new group that can be targeted by automations. JSON body REQUIRED field: name. Optional: description, include_filter (array of {field_name, field_value, mode} criteria objects), exclude_filter (same), include_filter_logic / exclude_filter_logic (boolean expressions like "1 AND (2 OR 3)" referring to 1-based filter positions), uptime_alerts (offline/online notification config). Use action1_modify_group_endpoints AFTER creation to add manual members; criteria-based members are populated automatically from include/exclude filters. Example: {"name":"Windows 11 Production","description":"All Win11 endpoints in HQ","include_filter":[{"field_name":"OS","field_value":"Windows 11","mode":"include"}]}.

[Action1] Permanently delete an endpoint group. Side effect: removes the group; member endpoints are NOT deleted but lose group membership. Any automations targeting this group will need reconfiguration. Use action1_list_endpoint_groups first to find valid groupId values.

[Action1] Get full details for a single endpoint group including name, description, membership rules, and metadata. Use action1_list_endpoint_groups first to find valid groupId values; for the actual member list use action1_list_group_endpoints.

[Action1] List all endpoint groups (logical collections of endpoints) in the organization with offset-based pagination. Returns group IDs, names, descriptions, and member counts. Use group IDs with action1_get_endpoint_group, action1_list_group_endpoints, and as targeting selectors in automation tools. Use action1_list_organizations to find valid orgId values.

[Action1] List all endpoints that are members of a specific group with offset-based pagination. Returns endpoint IDs, hostnames, and basic status. Use action1_list_endpoint_groups first to find valid groupId values; use action1_get_endpoint for full per-endpoint detail.

[Action1] Add or remove endpoint members from a group. JSON body is an ARRAY of operation objects. Each object has a method field ("POST" to add, "DELETE" to remove). POST entries carry a data object — either {"endpoint_id":"<uuid>","type":"Endpoint"} (add by ID) or {"endpoint_name":"WKS232","type":"EndpointName"} (add by name). DELETE entries carry endpoint_id directly. You can mix POST and DELETE in one call. Example: [{"method":"POST","data":{"endpoint_id":"<uuid>","type":"Endpoint"}},{"method":"POST","data":{"endpoint_name":"WKS232","type":"EndpointName"}},{"method":"DELETE","endpoint_id":"<uuid>"}]. Side effect: changes group membership and may re-trigger group-targeted automations. Replaying the same operations is a no-op (already-present POST or already-absent DELETE). If an endpoint name/ID isn't found, the call still succeeds with the missing IDs returned in the response details. Use action1_list_endpoints and action1_list_group_endpoints to find valid endpoint IDs.

[Action1] Update endpoint group properties (name, description, filters). PATCH semantics — fields not present in the body are left unchanged. Important gotcha: include_filter and exclude_filter arrays are REPLACE semantics, not 'add to' — sending a new array replaces the entire previous criteria set. To change manual membership use action1_modify_group_endpoints instead. Use action1_list_endpoint_groups first to find valid groupId values.

[Action1] Get the current state of an active remote session including status (connected field is "yes"/"no"), connected user, monitor_count for multi-display endpoints, and connection metadata. Use action1_start_remote_session first to obtain a sessionId; poll this until connected=="yes".

[Action1] Starts a new browser-based remote-assist session to the endpoint (not RDP). JSON body REQUIRED field: connection_type (must be the literal string "assistance" — only session type currently supported); optional current_ip (your current public IP). Returns a RemoteSession object whose remote_session field is a URL the operator opens in a browser. Side effect: prompts the end user (per org settings) to accept. After this call, poll action1_get_remote_session until the connected field == "yes". Use action1_list_endpoints to find valid endpointId values.

[Action1] Switches the active monitor on a multi-display endpoint during an active remote session. JSON body REQUIRED field: current_monitor (1-based STRING index of the target monitor). Example: {"current_monitor":"2"}. Replaying with the same monitor index is a no-op vendor-side. Use action1_get_remote_session first to read monitor_count for the upper bound.

[Action1] Permanently remove a Deployer service registration from the organization. Side effect: irreversibly removes the deployer record. Already-deployed agents remain installed. If the deployer status is 'Connected' or 'Disconnected', call action1_uninstall_deployer first — this endpoint refuses DELETE unless status is 'Pending Install'. Use action1_list_deployers first to find valid deployerId values.

[Action1] Get the agent deployment settings for the organization, including auto-discovery, network scan ranges, credentials, and deployer behavior. Use action1_list_organizations to find valid orgId values; modify with action1_update_agent_deployment_settings.

[Action1] Get full details for a single Deployer service including host machine, version, status, last contact timestamp, and discovered network ranges. Use action1_list_deployers first to find valid deployerId values.

[Action1] Returns a JSON object containing the download URL for the Action1 Deployer Windows EXE installer for the org. Action1 Deployer is a Windows-only network service: install on one Windows host per network segment to auto-discover and install agents on the other endpoints. Returns JSON with a download_URL field (not the binary itself). For per-endpoint manual installs use action1_get_agent_installation_url. Use action1_list_organizations to find valid orgId values.

[Action1] List all installed Deployer services for the organization with offset-based pagination. Each Deployer is a Windows-only service that auto-discovers and installs agents on networked endpoints. Returns deployer IDs, host machine names, status, and last contact. Use deployer IDs with action1_get_deployer, action1_uninstall_deployer, and action1_delete_deployer.

[Action1] Initiate uninstall of an Action1 Deployer service from the Windows host. Side effect: stops and removes the Deployer service; status transitions to 'Pending Install' once complete. Required workflow: call this BEFORE action1_delete_deployer if the Deployer is currently 'Connected' or 'Disconnected'. Use action1_list_deployers to find valid deployerId values.

[Action1] Update the org's Agent Deployment configuration. Side effect: changes how Deployer services discover and install agents on new endpoints. Available fields (all optional, only include what you want to change): ad_domain ("1"=AD domain mode, "0"=computer list mode); domain_name (comma-separated AD domains); exclude_DCs / exclude_workstations / exclude_servers (each "yes"/"no"); exclude_computer_list_enabled ("yes"/"no"); exclude_computer_list (string[] of computer names to skip); computer_list (string[] of computers to target when ad_domain="0"). Use action1_get_agent_deployment_settings first to inspect current values.

[Action1] Create a new custom data source (a scripting template that queries endpoint data). Required fields: `name`, `status`, `description`, `language`, `script_text`, `columns`. `language` MUST be `"PowerShell"` (only valid value - Bash/Command are NOT valid for data sources, only for Scripts). `status` is `"Published"` or `"Draft"` (vendor warns Draft is currently deferred). `columns` is an array of strings naming the output columns (e.g. `["Endpoint Name", "Display Name"]`). `script_text` is PowerShell that emits objects whose properties match `columns`. Use action1_list_data_sources afterward to discover the new dataSourceId.

[Action1] Permanently delete a custom data source. Side effect: removes the template; reports and automations referencing it will break. This action CANNOT be undone. Built-in data sources cannot be deleted. Use action1_list_data_sources to confirm the dataSourceId before deleting.

[Action1] Get the full definition of a single data source including the script body, output column schema, and built-in/custom flag. Use action1_list_data_sources to find valid dataSourceIds.

[Action1] Lists scripting templates that query endpoint data (built-in + custom). Built-in cannot be modified. Returns vendor-assigned IDs (integers/slugs, not GUIDs) used by reports and automations to collect inventory or telemetry. Use action1_get_data_source for full template details, action1_create_data_source to add a custom script-driven source.

[Action1] Update an existing custom data source's script, schema, or metadata. Side effect: modifies the template; subsequent report runs will use the new definition. Built-in data sources cannot be modified. Only include fields you want to change in fieldsJson. Use action1_get_data_source to inspect current shape before editing.

[Action1] Create a new custom executable script. Required fields: `name`, `language`, `script_text`, `platform`. `language` enum: PowerShell, Command, or Bash. `platform` enum: Windows, Mac, or Linux. Optional: `description`, `reboot_exit_codes` (string like `"1, 3010"`). Note: `params` is read-only/derived from the script text - agents passing `params` on POST will have it ignored. `success_codes` is response-only, not writable. Parameter syntax in script body: `$paramname` (PowerShell), `%paramname%` (Command), none for Bash. Use action1_list_scripts afterward to discover the new scriptId.

[Action1] Permanently delete a custom script. Side effect: removes the script; automations referencing it will break. This action CANNOT be undone. Built-in scripts cannot be deleted. Use action1_list_scripts to confirm the scriptId before deleting.

[Action1] Get the full definition of a single script including its language, body, derived parameter list, and built-in/custom flag. Use action1_list_scripts to find valid scriptIds.

[Action1] Lists ready-to-use PowerShell/CMD/Bash scripts (built-in + custom). Returns vendor-assigned script IDs you can reference from action templates and automation schedules. Use action1_get_script for the full script body and parameters.

[Action1] Update an existing custom script's body or metadata. Side effect: modifies the script; subsequent runs use the new definition. Built-in scripts cannot be modified. Note: `platform` is POST-only; cannot be changed via PATCH. `params` is derived from script_text - re-edit the body to change parameter shape. Use action1_get_script to inspect current shape before editing.

[Action1] Create a new setting value bound to a template at a given scope. Required: `template_id`, `value`, `scope`. `scope` is an ARRAY of SettingScope objects: `[{type: "Enterprise"|"Organization"|"Group", object: "all"|"<orgId>"|"<groupId>"}]` (NOT a flat string). `value` is a string (often a JSON-stringified payload - e.g. `value: "[{"name":"Custom Attribute 11"}]"` is itself a JSON string, not a nested object). Use action1_list_setting_templates first to find a valid template_id and its value schema.

[Action1] Permanently delete a setting. Side effect: removes the configured value; the scope reverts to the template default or higher-scope inheritance. This action CANNOT be undone. Use action1_list_settings to confirm the settingId before deleting.

[Action1] Get a single setting's full detail including the template reference, scope, and current value. Use action1_list_settings to find valid settingIds.

[Action1] Get the full definition of a setting template including the value schema and supported scopes. Note: `scope` on the Setting payload is an array of `{type, object}` objects (not a flat string). Use action1_list_setting_templates to find valid templateIds.

[Action1] Templates that drive what kinds of settings can be created. Returns templateIds and a description of each template's value schema and applicable scope. Use action1_get_setting_template for a single template's full schema, then action1_create_setting to apply a value.

[Action1] List all configured settings (template + applied value at a given scope). Returns settingIds, the template they reference, the scope, and the current value. Use action1_get_setting for a single entry's full detail.

[Action1] Update the value of an existing setting. Side effect: modifies the configuration; agents and policies pick up the new value on their next sync. Only include fields you want to change in fieldsJson (typically `value`). Use action1_get_setting to inspect current shape before editing.

[Action1] Create a new custom report definition. Required fields: `name`, `description`, `data_sources`, `simple_columns`, `summary_columns`, `drilldown_columns`, `filter_set`. Shape: `data_sources` is an array of full URI strings like `/API/data-sources/all/2041`. `simple_columns`/`summary_columns`/`drilldown_columns` are arrays of `{name, enabled: "yes"|"no", sort: "none"|"asc"|"desc", data_source_id: <int>}` (data_source_id is the integer parsed out of the URI). `filter_set` is `{filters: [{name, data_source_id, operator: "="|"<"|">"|"<="|">="|"<>", value}], filter_logic: "1 OR 2"}`. Wildcards (e.g. `Adobe*`) are accepted in `value`. Optional `column_aliases`: `[{data_source_id, original_name, new_name}]`. Use action1_get_data_source for the column list before constructing this body.

[Action1] Permanently delete a custom report definition. Side effect: removes the report; report subscriptions referencing it will break. This action CANNOT be undone. Built-in reports cannot be deleted. Use action1_list_reports to confirm the reportId before deleting.

[Action1] Returns the children of a category, or the resolved-detail of a report when given a report ID. Used to walk the report taxonomy hierarchically. Use action1_list_reports to discover root nodes.

[Action1] Lists report definitions (built-in + custom). Use action1_get_report_data to fetch actual data rows. Returns vendor-assigned reportIds, category, name, and built-in/custom flag. Reports are categorized hierarchically; pass `subtree=Yes` to return the full subtree, or use action1_get_reports_in_category to walk the tree manually.

[Action1] Update a custom report's columns, filters, or metadata via PATCH semantics. Side effect: modifies the report definition; subsequent action1_get_report_data calls return data shaped by the new definition. Built-in reports cannot be edited - this call rejects them. Only include fields you want to change in fieldsJson.

[Action1] Drill into a single report row to retrieve its underlying detail records (e.g. expand an aggregate row into the per-endpoint detail it summarises). Use action1_get_report_data first to discover reportRowIds. Supports paging via from/pageSize plus a substring filter, sort key, and `liveOnly`.

[Action1] Export an Action1 report to CSV or HTML. Returns a short-lived SAS URL (valid for 1 hour) to the file in blob storage - the agent should fetch the file from the URL within the expiry window; do NOT attempt to decode the URL as content. Reports larger than 100 MB fail with HTTP 413. Use action1_list_organizations and action1_list_reports to find valid IDs.

[Action1] Export the drilled-down details for a single report row to CSV or HTML. Returns a short-lived SAS URL (valid for 1 hour) to the file in blob storage - the agent should fetch the file from the URL within the expiry window; do NOT attempt to decode the URL as content. Reports larger than 100 MB fail with HTTP 413. Use action1_get_report_data first to discover reportRowIds.

[Action1] Fetch the data rows produced by a previously generated report for a specific organization. Use action1_list_reports (catalog) to discover reportIds and action1_list_organizations to find orgIds. Supports paging via from/pageSize, optional sort key, and a substring filter. Use `liveOnly=Yes` to skip cached endpoint responses; `details=yes` to expand details (Summary reports only); `endpointId` to scope rows to a single endpoint. Pair with action1_requery_report when you need fresh data before reading.

[Action1] List per-endpoint or per-row errors that occurred while a report was being generated for an organization. Useful for diagnosing why action1_get_report_data is missing rows or shows stale data. Use action1_list_organizations and action1_list_reports to find valid IDs.

[Action1] Triggers async report re-fetch. Pair with action1_get_report_data to read fresh results once requery completes. Returns immediately; the report runs server-side. Optionally pass `endpointId` to requery just one endpoint instead of the whole org. Use action1_list_organizations and action1_list_reports to find valid IDs.

[Action1] Pre-flight check: ask Action1 whether a proposed `app_name_match` regex would collide with another package's version (i.e. would two different versions match the same installed software on the endpoint). Use this regex BEFORE calling action1_create_software_package / action1_create_package_version. Pass the regex you intend to put on the new version's `app_name_match` field.

[Action1] Pre-flight check: ask Action1 whether a proposed `app_name_match` regex would collide with another version of the SAME package. Use BEFORE calling action1_create_package_version. Pass the regex you intend to put on the new version's `app_name_match` field.

[Action1] Duplicate an existing package and all its versions into a new custom package. No body parameters - vendor assigns a new packageId. Use this to fork a built-in package so you can edit its versions afterwards via action1_update_package_version. Note: cloned built-in packages are no longer maintained by Action1.

[Action1] Add a new version (with install/uninstall actions) to an existing software package. Required fields: `version` (e.g. "1.2.3.4"), `app_name_match` (regex matching the installed product as it appears in Apps & Features - e.g. `^Mozilla +Firefox.+$`), `release_date` (YYYY-MM-DD). Common optional fields: `notes`, `update_type`, `security_severity`, `security_CVE`, `silent_install_switches`, `success_exit_codes`, `additional_actions[]`. Windows-only: `install_type` (`msi|exe|msix`), `uninstall_app_name_match`, `silent_uninstall_switches`, `reboot_exit_codes`, `file_name.{Windows_32|Windows_64|Windows_ARM64}` as `{name, type: "cloud"|"unc"}`. Mac-only: `file_name.{Mac_IntelCPU|Mac_AppleSilicon}` (cloud only). The package must already exist (POST action1_create_software_package). The actual binary upload is a separate two-stage flow not exposed by StackJack - use the Action1 console for binary uploads.

[Action1] Register a new software package shell in the org's repository. Required fieldsJson keys: `name`, `vendor`, `description`, `platform` (`Windows` or `Mac`). Optional: `internal_notes`. Versions (with install commands and matching rules) are added separately via action1_create_package_version. Side effect: creates a new (custom) package row; built-in Action1 packages cannot be created this way.

[Action1] Permanently delete a specific version from a software package. Side effect: irrevocably removes the version and its actions; automations targeting this version will fail. Use action1_get_software_package (with fields=*) to confirm versionId before deleting. Built-in package versions cannot be deleted.

[Action1] Permanently delete a software package and ALL of its versions/actions from the org's repository. Side effect: irrevocably removes the package; automations referencing it may fail. Use action1_list_software_packages to confirm packageId before deleting.

[Action1] Permanently delete a single additional action (install / uninstall / detection step) from a CUSTOM package version while keeping the version itself. Side effect: irrevocably removes the action; the version may no longer install or detect correctly. Built-in packages reject this DELETE. Use action1_get_package_version to find actionIds in the additional_actions[] array.

[Action1] Get full detail for a specific version of a software package, including its install / uninstall / detection actions. Use action1_get_software_package (with fields=*) or action1_list_software_packages first to discover versionIds.

[Action1] Get full detail for a single software package. Without `fields=` or `fields=versions` the response omits the versions[] array; pass `fields=` to retrieve the full version list. Use action1_list_software_packages to discover packageIds.

[Action1] Lists packages registered in the org's repository (vendor, product name, latest version, package type). Use the returned packageIds with action1_get_software_package, action1_create_package_version, etc. Use action1_list_organizations to find valid orgIds. Filter parameters use Yes/No strings; matchName/matchVersion accept a regex; fields=*/versions expands version arrays.

[Action1] Update a specific version of a software package (e.g. tweak install command line or detection rule). Side effect: modifies the version row. Only include changed fields in fieldsJson. Use action1_get_package_version to inspect current shape before editing.

[Action1] Update properties on an existing CUSTOM software package (rename, description, internal_notes). Built-in packages reject this call except for `EULA_accepted`. fieldsJson should contain only the fields you want to change.

[Action1] For a specific package version, list every endpoint that is currently missing it. Use action1_list_missing_updates or action1_list_package_updates to discover packageId/versionId pairs first. Pair with action1_apply_automation to remediate.

[Action1] List patches/updates currently missing across endpoints in an organization. Returns one row per missing-update / package combination (rows include severity, KB references, and CVE list). Common filters: approval_status, security_severity, builtin/custom, SLA-window. The `filter` parameter is a plain case-insensitive substring search across visible fields - for severity / approval / etc. use the dedicated parameters. Pair with action1_list_endpoints_missing_update to drill into a specific update before remediation.

[Action1] List the available update versions for a specific package across the organization. Use action1_list_software_packages to discover packageIds, then this tool to see which versions Action1 considers an upgrade target. The `filter` parameter is a plain case-insensitive substring search - for severity / approval / etc. use the dedicated parameters.

[Action1] List the installed software inventory for a single endpoint (vendor, product, version, install date). Use action1_list_endpoints to find valid endpointIds. Supports paging via from/pageSize plus a substring filter and sort key.

[Action1] Returns the per-endpoint errors encountered during installed-software collection. Useful for diagnosing endpoints that failed to report their installed software list. Paginated - use from/pageSize.

[Action1] List all installed software titles aggregated across the org's endpoints, with install counts. Use `liveOnly=Yes` to suppress cached rows. The `filter` parameter is a plain case-insensitive substring search across visible fields. Use action1_get_endpoint_installed_software to drill into a specific endpoint's inventory.

[Action1] Trigger an asynchronous re-scan of installed software for a single endpoint. Returns 200 once queued; does NOT guarantee the endpoint has processed. Online endpoints respond within seconds; offline endpoints process when they next reconnect. Verify freshness via `response_type` field on subsequent list calls (`live` = post-requery, `cache` = pre-requery). Action1 auto-updates inventory every 15 min - only requery for out-of-band changes or real-time needs.

[Action1] Trigger an asynchronous re-scan of installed software across all endpoints in the org. Returns 200 once queued; does NOT guarantee endpoints have processed. Online endpoints respond within seconds; offline endpoints process when they reconnect. Verify freshness via `response_type` field on subsequent list calls (`live` = post-requery, `cache` = pre-requery). Action1 auto-updates inventory every 15 min and immediately after Action1-driven installs/uninstalls - only requery for out-of-band changes or real-time needs.

[Action1] Retrieve a single action template by ID. Returns id, name, description, and applicable_to surface only — the endpoint does NOT return per-template parameter schemas at runtime. The detailed params shape per template_id is documented inside the action1_create_automation_schedule and action1_apply_automation tool descriptions. Use action1_list_action_templates to discover valid IDs.

[Action1] List the available action templates (the reusable building blocks Action1 uses for automations, e.g. install package, run script, reboot). Returns template IDs and names. Use the IDs when constructing automation schedules. Valid template_id values are a closed set: deploy_package, deploy_update, uninstall_program, run_script, reboot, update_ring.

[Action1] Trigger a one-shot automation run. Side effect: creates a new automation instance and starts execution immediately, fanning out install/uninstall/reboot/script work across the targeted endpoints. This call FAILS if orgId is "all". Body is AutomationInstancePayload — required: name, retry_minutes (string), actions[], endpoints[]. Note endpoints[] is REQUIRED for apply (unlike schedule create where it is optional). See action1_create_automation_schedule for the full actions[] / endpoints[] / template_id / reboot_options shapes.

[Action1] Create a scheduled automation (one or more actions executed on a schedule against a scope of endpoints). Side effect: creates a recurring or one-time task. Endpoint paths in this connector use orgId from action1_list_organizations. The body is the AutomationSchedulePayload — required: name, retry_minutes (STRING, e.g. "1440"), actions[], settings (schedule grammar). endpoints[] optional on schedules; if omitted the schedule has no targets until you add some.

[Action1] Remove a specific action from a schedule without deleting the entire schedule. Side effect: the schedule's instance history for the removed action is also removed.

[Action1] Hard-delete an automation schedule. Side effect: schedule and its instance history are both removed (irreversible).

[Action1] List automation instances (one row per execution of a schedule). Use to track recent runs and their statuses.

[Action1] List per-endpoint results for an automation instance. Pair with action1_get_automation_endpoint_details for richer per-endpoint info.

[Action1] List automation schedules within an organization. Schedules combine actions, scope, and timing. Use action1_list_organizations to find valid orgId values.

[Action1] Stop a running automation instance. Side effect: pending endpoint runs are cancelled.

[Action1] Update a scheduled automation. PATCH semantics — provide only the fields you want to change. Body shape is AutomationSchedulePayload (same shape as create). See action1_create_automation_schedule for the full schema, settings grammar, endpoints[]/actions[] shapes, and the closed template_id enum.

[Action1] Document a compensating control for a CVE in an organization. Side effect: writes a permanent remediation record. fieldsJson must include both `product_name` (the affected software) and `comment` (description of the control). Both fields are required by Action1's vendor schema.

[Action1] Delete a remediation record. Side effect: history of compensating controls is lost.

[Action1] Get the global description of a CVE (not org-scoped). Use this when you need the CVE's general details independent of any specific organization's exposure.

[Action1] List vulnerable software detected on endpoints in an organization. Returns CVE details, severity, and exploit availability. Use action1_list_organizations to find valid orgIds. Use the typed parameters (`score`, `remediationStatus`, `cveIds`, etc.) for structured patch-triage queries; `filter` is a plain substring search.

[Action1] List endpoints affected by a specific CVE within an organization. Use to drill from a CVE down to the affected endpoint set.

[Action1] List recorded remediation/compensating-control actions for a specific CVE. Useful for documenting what's already been done before recommending new actions.

[Action1] Update an existing remediation record. Action1 only allows the `comment` field to be edited; product_name and other fields are fixed at create time. Body shape: {"comment":"Updated explanation..."}.

[Action1] Export the audit trail as CSV. Returns a short-lived (1 hour) read-only SAS URL to the exported CSV stored in blob storage — fetch the file from the URL, do not interpret the URL as JSON. Hard cap: 100 MB; exports above that fail with HTTP 413, so scope with timefrom/timeto/events to keep the export bounded. Use the optional time/event/filter parameters to scope before exporting.

[Action1] Retrieve full details for a single audit event including before/after values where applicable. Use action1_list_audit_events to discover valid event IDs.

[Action1] List audit trail entries (admin actions, logins, API calls, etc.). Use `events` to comma-separate event names (e.g. 'Login,Remote Connect,POST'), `timefrom`/`timeto` to bound the window, and `fromId` for sequential resume. `filter` is a plain substring search across all event fields.

[Action1] Get usage statistics broken out per organization. Useful for MSP billing and capacity planning across clients.

[Action1] Request a price quote for an Action1 plan. Side effect: contacts Action1 sales. The vendor's `SubscriptionQuotePayload` body requires `endpoint_count`, `comments`, and `product` (the company name to attach to the quote).

[Action1] Request a free trial or trial extension. Side effect: contacts Action1 sales/operations and may schedule the trial seats once approved. The vendor's `SubscriptionPayload` body requires `endpoint_count` (number of seats requested) and `comments` (free-form context for the sales team).

[Action1] Create a new email report subscription. Required fields: `name`, `report_id`, `schedule`. `report_id` is enum-restricted to 'daily_patch_statistics' or 'weekly_patch_statistics' — you cannot subscribe to a custom report. `schedule` is a single string in the form '(ENABLED|DISABLED) WEEKLY:Sun|Mon|Tue|Wed|Thu|Fri|Sat AT:HH-MM-SS' (note: time uses DASHES, not colons; weekdays are 3-letter capitalized). Delivery is HTML-only — any `format` value the agent supplies is silently ignored.

[Action1] List the current user's scheduled email-report subscriptions. Hard cap: only the two patch-statistics reports ('daily_patch_statistics' and 'weekly_patch_statistics') are subscribable — custom reports cannot be subscribed to. Delivery is HTML-only; the vendor ignores any `format` value.

[Action1] Update an existing email report subscription. Only include fields you want to change. Same field rules as create — `report_id` is enum-restricted to 'daily_patch_statistics' or 'weekly_patch_statistics'; `schedule` follows the format '(ENABLED|DISABLED) WEEKLY:Sun|Mon|Tue|Wed|Thu|Fri|Sat AT:HH-MM-SS' (DASHES in time, 3-letter capitalized weekdays). Delivery remains HTML-only regardless of any `format` value.

[Action1] Universal case-insensitive substring search across multiple resource types (reports, endpoints, and App Store applications) within a specific organization. Returns up to 10 results by default. Useful as a first hop when you have a hostname, app name, or report keyword but no IDs. Use action1_list_organizations to find a valid orgId.

[Action1] Retrieve diagnostic log entries for a specific organization. Covers agent issues, deployment failures, and automation problems. Use `level` to suppress chatty Debug/Normal entries when triaging incidents, and `sortBy='-time'` for newest first. Use action1_list_organizations to find a valid orgId.

[Action1] Combines automation instances with their endpoint results to compute success vs failure rate per organization. Use to spot trending automation failures.

[Action1] Combines endpoints, missing updates, and vulnerabilities into a single org-level health snapshot. Useful as the entry point for endpoint-health reporting.

[Action1] Cross-organization installed-software rollup. Pages through every org's installed-software list; useful for shadow-IT discovery and license consolidation. Hard ceiling on fan-out is 50 orgs; the response includes `truncated` and `totalOrganizationsAvailable`.

[Action1] Cross-organization rollup of vulnerabilities. Pages through every org the credential can see (no silent first-page truncation) and aggregates CVE counts per org. Hard ceiling on fan-out is 50 orgs; pass `topOrgs` to lower this. The response includes `truncated` (boolean) and `totalOrganizationsAvailable` so the agent can detect partial coverage.

[Action1] Cross-organization ranking of vulnerabilities. Pages through every org and aggregates CVE counts. Hard ceiling on fan-out is 50 orgs; the response includes `truncated` and `totalOrganizationsAvailable` so the agent knows whether it saw the full set.