Migrate or create checks with MCP

With the octoja MCP, an AI assistant can adapt existing monitoring scripts to octoja or create a new custom check from your description. You review the draft, have it run on a selected test device, then save it in the Check Library. You do not need access to the migration portal for this workflow.

If you want to upload and translate several PowerShell scripts together, use the Check Importer instead. The MCP workflow is particularly useful when you want to clarify requirements in conversation and refine a check step by step. It does not automatically connect to your old RMM: provide the source script or a description of the existing monitoring.

Prerequisites

• A connected MCP client, such as ChatGPT or Claude. Overview and access explains setup and the MCP Usage permission.
• A suitable test device with an installed, online octoja agent and any programs the script needs.
• The following client authorizations and user permissions:

Grant script-execution access only to a trusted client. A live test executes real code on the device even if the check has not been saved. live_test_script does not additionally require Live device access.

Step 1 – Prepare a source or requirements

For a migration, export or copy the monitoring script from your current RMM. Also note any settings stored outside the script. If there is no script, describe the monitoring you want instead.

In either case, record:

• Operating system and required programs or modules.
• Input parameters, defaults and units.
• Conditions for OK, warning and critical, including thresholds and behavior when data is missing.
• Check interval and desired output, such as measurements, status text and history.

Your old RMM's variables, modules and exit codes do not automatically work unchanged in octoja. Ask the assistant to identify these dependencies and unresolved assumptions rather than silently replacing them.

Step 2 – Draft the check in conversation

Start with one check. Replace the placeholders in the following prompts with your requirements and, for a migration, attach the sanitized source script as a file or text.

Migrate an existing check

Use the octoja MCP to convert the attached monitoring script from [source RMM] into an octoja custom check for [operating system]. Read describe_custom_check_authoring first and use list_custom_checks to see whether a suitable custom check already exists. Preserve the meaning of the original statuses and thresholds. Turn the old RMM variables into configurable input parameters. Show me the adapted code, parameters, output fields, result display and all assumptions. Do not execute or save anything yet; ask about any unclear logic.

Create a new check

Use the octoja MCP to draft a Windows custom check for the age of a backup file. Read describe_custom_check_authoring first and see whether a suitable custom check already exists. Make the file path and thresholds configurable: warn at 24 hours, mark critical at 48 hours, and also mark a missing file critical. Interval: 15 minutes. Show the age and last-modified time in the result, and the age in history. The check must only read, not change files. Show me the code, parameters and result display first; do not execute or save anything yet.

The assistant gets the current format from describe_custom_check_authoring; you do not need to supply a complete JSON schema. Custom script-based checks report status through checkResult: 0 for OK, 1 for warning and 2 for critical. PowerShell uses $output.checkResult and reads parameters from $checkInput; Bash uses set_result, set_output and get_input. octoja adds the output formatting. Have the assistant replace status exit codes and remove extra console output so they do not disrupt the result output. See Custom Script for details.

Step 3 – Review and live-test

Read the draft and check the status mapping, units, dependencies and error handling in particular. The check should not silently report missing or unreadable data as OK.

When the draft is ready, authorize a specific test:

Find [test device] with list_devices and show me its device ID and operating system for confirmation. After I confirm, run only the reviewed draft there with live_test_script. Include the input definition and agreed test parameters. Report verified, status, output values and errors. Do not save a check yet or test other devices.

live_test_script tests the script without saving a check. verified: true means execution succeeded and returned a valid result with status OK, Warning or Critical. It does not mean the status is necessarily OK or that the monitoring logic is correct. Compare the reported values with the actual state.

Alongside the normal case, test warning, critical and missing data. For the backup-file example, include the exact boundaries of 24 and 48 hours. Use controlled test data or test parameters rather than changing production backups. For a migration, compare results with the original check. One successful run is not enough to exercise every status.

Step 4 – Save and assign gradually

1. Authorize saving only once the code and tests are satisfactory. The assistant creates the check with create_custom_check and reads it back with get_custom_check using the returned ID. Check its name, platforms, interval, parameters and result display.
2. Open Configuration → Check Library in octoja and enable Custom checks only if needed. Creating the check makes it available in the library but does not assign it to any device.
3. Assign it only to the test device first under Checks → Add Check, and inspect a scheduled run with the actual parameters. Assignment happens in the octoja UI, not through the MCP check-authoring tools.
4. Only then roll it out more widely using config packages. The assistant can inspect assignments with get_device_checks and reported results with get_check_history.

To adapt an existing custom check, have the assistant read it with get_custom_check first and save changes with update_custom_check rather than creating a duplicate. Check where it is already in use before changing it: edits to an active check can affect existing assignments.

For a simple OID-based network check, Simple SNMP mode lets octoja generate the scripts. See Create and test Simple SNMP checks for a suitable prompt and test prerequisites.