# Robolytix MCP > Robolytix connects your AI agent directly to your Robotic Process Automation (RPA) analytics platform. It lets you manage bot workflows, track performance metrics, and read detailed logs through natural conversation. Use tools like `list_rpa_processes` or send `sonar_start` messages to monitor process health without leaving your chat window. ## Overview - **Category:** industry-titans - **Price:** Free - **Tags:** rpa-monitoring, process-automation, bot-performance, workflow-analytics, execution-tracking, business-process-health ## Description Robolytix connects your AI agent straight into your Robotic Process Automation (RPA) analytics platform. You can manage and query bot workflows—everything from simple status checks to deep-dive error analysis—using plain language commands right through your chat window. If you wanna know what bots you got running, start by calling **`list_rpa_processes`**. That tool spits out a list of every single RPA process name and ID configured in the system. Once you've got the name, you can dig deeper into that specific automation using **`get_process`**; it pulls all the full configuration details for that robotic process based on its identifier. To see what ran recently, use **`list_runs`**. This generates a paginated list of every bot run recorded within a given timeframe. After you pick a unique run ID from that list, you can get summary data and metadata about that single execution with **`get_run`**. That lets you check the overall performance metrics for one specific instance right away. When things go sideways or you need to know exactly what happened during an active process, **`get_run_messages`** is your best friend. It pulls every single log message and step that was recorded during that specific process run, which is killer for debugging failures. You don't just get a summary; you get the whole transcript. For monitoring overall system health, start with **`get_stats`**. This fetches high-level, aggregated performance statistics across every automation your company runs. It gives you the big picture without having to sift through thousands of individual logs. When you need to track milestones or signal major events in a process workflow, you use specialized 'Sonar' tools. You mark the beginning of monitoring by sending **`sonar_start`**. If the process hits a critical intermediate step—like pulling data from an external API—you log it with **`sonar_checkpoint`**, which tracks that specific milestone. When everything finishes clean, you send **`sonar_end`** to mark successful completion. Conversely, if something breaks, you immediately flag it using **`sonar_error`** to make sure everyone gets alerted right away. Essentially, your agent uses these tools to act as a complete monitoring system. You use **`list_rpa_processes`** and **`get_process`** to understand the structure; then you use **`list_runs`** and **`get_run`** to pinpoint specific instances of activity. If those runs need detailed scrutiny, **`get_run_messages`** gives you every word they said. You keep tabs on the whole operation using **`get_stats`**, while the specialized sonar tools—**`sonar_start`**, **`sonar_checkpoint`**, **`sonar_end`**, and **`sonar_error`**—let your agent actively control the monitoring flow, signaling exactly when things start, what major steps they hit, or where they fail. It's a full cycle of visibility. ## Tools ### get_process Gets the full configuration details for a specific robotic process using its identifier. ### get_run_messages Pulls every single log message recorded during a specific process run, useful for debugging failures. ### get_run Retrieves summary data and metadata for one particular bot execution run. ### get_stats Fetches high-level, aggregated performance statistics across all managed automations. ### list_rpa_processes Returns a list of every configured RPA process name and ID in the system. ### list_runs Generates a paginated list of all recorded bot runs within a given time frame. ### sonar_checkpoint Logs an intermediate 'common' event in the process workflow, useful for tracking major steps. ### sonar_end Marks the successful completion of a monitored automation run. ### sonar_error Logs an explicit error event into the process workflow for immediate alerting. ### sonar_start Logs the official start of a new robotic process run, initiating monitoring. ## Prompt Examples **Prompt:** ``` Log the start of process 'p-123' with run ID 'r-999'. ``` **Response:** ``` Sonar start message sent! Process 'p-123' is now being tracked under run 'r-999' in Robolytix. Would you like to log a common step now? ``` **Prompt:** ``` Show me all RPA process runs from today with their success rates and execution times. ``` **Response:** ``` 34 process runs today across 8 automated processes. Success: 31 (91.2%). Failed: 3 (invoice processing errors). "Order Processing" ran 12 times (avg 2.3 min, 100% success). "Invoice Generation" ran 8 times (avg 1.8 min, 75% success, 2 failures due to template mismatch). "Data Sync" ran 6 times (avg 4.5 min, 100% success). "Email Classification" ran 5 times (avg 0.8 min, 100% success). Total automation time saved: 4.2 hours. Cost savings: $840. ``` **Prompt:** ``` Get the detailed message log for the last failed invoice processing run. ``` **Response:** ``` Run ID: run_8923 (Invoice Generation, failed at 10:47 AM). 12 messages in log. Start: "Process initiated, 45 invoices queued". Steps 1-8: successful (customer lookup, line item calculation, tax computation). Step 9 ERROR: "Template 'INV-2024-v3' not found. Expected path: /templates/invoices/". Step 10: "Attempting fallback template 'INV-2024-v2'". Step 11 ERROR: "Fallback failed - missing required field 'tax_region'". End: "Process terminated with error code E-TPL-404". Recommendation: update template path in config. ``` ## Capabilities ### Track process status Retrieves current metadata and details for a specific configured robotic process using `get_process`. ### Monitor run history Gets detailed information about any completed or active bot execution, including the unique run ID via `get_run`. ### Retrieve message logs Pulls every single log entry and step message from a specific process run using `get_run_messages`. ### Get overall performance metrics Retrieves aggregated statistics across all your RPA activities using `get_stats`. ### List available processes Pulls a list of all configured robotic processes, providing their necessary identifiers via `list_rpa_processes`. ### Send workflow messages Logs specific events like start, checkpoint, or end using specialized sonar tools (`sonar_start`, `sonar_checkpoint`, `sonar_end`). ## Use Cases ### Investigating a failed batch job A user suspects the 'Invoice Generation' bot failed last night. They ask their agent, 'What went wrong with the latest invoice run?' The agent runs `list_runs` to find the ID, then uses `get_run` for metadata, and finally calls `get_run_messages`. This pulls a full log showing exactly which step (Step 9) failed, saving hours of manual investigation. ### Documenting process flow An Automation Manager needs to prove that a multi-stage workflow ran correctly. They prompt the agent to 'Start tracking the Order Processing bot run.' The agent executes `sonar_start`, then logs checkpoints with `sonar_checkpoint` at key steps, and finally calls `sonar_end`. This creates an immutable, auditable log trail in seconds. ### Calculating daily performance metrics A DevOps engineer needs a quick health check. They ask the agent for 'Today's overall bot performance.' The agent runs `get_stats`, returning success rates and failure counts across all bots, instantly giving them the data they need without logging into any web portal. ### Debugging missing process IDs A developer is about to monitor a new bot but doesn't know its ID. They simply ask, 'What are my available bots?' The agent uses `list_rpa_processes`, returning the list of names and their exact identifiers, allowing the developer to proceed with monitoring. ## Benefits - Stop dashboard hopping. Instead of switching between the RPA tool, the logging system, and a spreadsheet to check status, you use `get_run` or `list_runs`. The agent pulls all necessary metadata directly into your conversation. - Pinpoint failures instantly. When something breaks, don't search through thousands of lines of text. Use `get_run_messages` to pull the exact log sequence and error message right away. - Automate monitoring checkpoints. You can trigger major milestones using tools like `sonar_checkpoint`. This ensures that even complex processes are logged at critical junctures, giving you a clear operational timeline. - Get system-wide visibility with `get_stats`. Instead of running separate reports for success rates and run times, one query gives you the aggregate performance numbers across all bots. - Manage process discovery on demand. Need to know what processes exist? Use `list_rpa_processes` first to get the correct IDs before attempting to monitor or modify anything. ## How It Works The bottom line is, your AI client acts as a dedicated operations manager, running commands that usually require jumping between multiple dashboards. 1. First, subscribe to the Robolytix MCP Server and enter your API Key in the client settings. 2. Next, prompt your agent with a request—for example: 'What were the errors on run r-999?' 3. The agent uses the appropriate tool (like `get_run_messages`) to query Robolytix and returns the structured log data directly in the chat. ## Frequently Asked Questions **How do I check overall bot health using get_stats?** You ask your agent to run `get_stats`. It returns aggregated performance metrics, including total runs today, average success rate, and the count of errors across all bots. **What is the difference between list_runs and get_run?** `list_runs` gives you a paginated index of many run IDs over time. `get_run` takes one specific ID and returns the detailed metadata for just that single execution. **I need to track a custom step in my process, what tool should I use? Do I use sonar_checkpoint?** Yes, you must use `sonar_checkpoint`. It sends an intermediate 'common' message into the workflow. This logs your specific milestone without triggering a full start or end event. **Which tool do I use to find out what processes are available?** You run `list_rpa_processes`. This returns all configured bot names and their required IDs, so you know exactly which process to target next. **If an automation fails mid-run, how do I use sonar_error to log the failure immediately?** You send `sonar_error` when a process hits an unexpected exception. This tool immediately logs the error message and prevents data loss by marking the run as failed in Robolytix. **I need more than just basic details; how do I use get_run_messages to see every step of a run?** Use `get_run_messages` to pull the complete, granular log history for any given process run. It retrieves all associated messages—from start notes to calculation steps—allowing deep forensic analysis. **Before running a bot, how do I use get_process to check its defined parameters?** The `get_process` tool pulls the static definition and configuration details for a specific process ID. This lets you verify required inputs or setup changes before you initiate any run. **After I've successfully completed all steps, which tool should I use to mark the automation as finished?** Use `sonar_end` to signal that the process has reached its successful conclusion. This finalizes the run lifecycle in Robolytix and updates the overall health metrics. **Can my AI automatically start a process run in Robolytix and track its common steps?** Yes! Use the `sonar_start` tool to initiate a run, and `sonar_common` for subsequent steps. Provide the `processid` and a unique `runid`, and your agent will log the milestones in your Robolytix dashboard instantly. **How do I find a processid for my automation?** Log in to the Robolytix dashboard, go to **Settings** > **Processes**, select your process, and the unique GUID will be displayed in the **General** tab. **What should I use as a runid?** The `runid` can be any unique string for that specific execution instance (e.g., a timestamp, a UUID, or an order number). Just ensure you use the same ID for all sonar messages belonging to that single run.