RDM MCP — RDM_execute_opened_connection_action not working on SSH sessions

Hi @danieliwaszkiewicz,

Let me introduce myself first. I'm Maxime, AI Software Architect, I am the developer of the MCP server and the AI Assistant in RDM.

I'll answer your question about whether it should work first, then go into more detail about my findings. Yes, it should work. I just tested it locally in RDM with the AI Assistant using 3 SSH entries (Linux, macOS, Windows) and on the same 3 entries using an MCP client (VSCode) connected to RDM. I'm experiencing some lag and timeouts on my end, and RDM is slow when I send the prompt to get the top 3 processes on my Windows machine. I'll have to investigate that further with my colleague responsible for the SSH terminal, as there is tight integration with it to extract the output of the command.

We have the same request structure being sent to the MCP server, so the issue is not that

  "actionName": "send_command",
  "connectionIds": [
    "<redacted>"
  ],
  "parameters": {
    "command": "<redacted>",
    "captureOutput": true,
    "timeout": 30000
  }
}

Can you provide more information about your SSH entry so that I can investigate in the right direction? Is it Windows, Linux, or macOS machine? If it's Windows, then what I mentioned about the lag and timeout issues might explain it. If it's Linux or macOS, then I'll need to investigate further.

I'll start investigating the Windows-specific issues while I wait for your reply.

Thanks,

Hi Maxime,
Thanks for the quick response and for testing this yourself!
Here are the details:

• RDM client OS: Windows (Cloud Desktop)
• SSH target: Linux (Ubuntu), standard username/password authentication
• Connection type: Regular SSH session (no key-based auth, no jump host)
• Session state: The SSH connection was open and active in RDM at the time of the MCP call — I could see the terminal tab with the session running
• Datasource: Devolutions Hub Business (not a local database)

The error was consistent across all three actions (send_command, get_terminal_status, take_screenshot), so it doesn't seem action-specific.
On a positive note — other MCP operations like creating folders, moving/copying entries, and importing work very well overall. I do experience some lags and timeouts there too, but the operations complete successfully on the Hub side even when the MCP call times out on the client.
Let me know if you need any additional details or logs.
Thanks,
Daniel

I'll do some testing regarding the calls that sometimes timeout for creating folders, moving and copying entries. Are you doing like 30-40-50 entries? What's the use case look like when that happens?

Hi Maxime,
The use case was copying ~80 entries (26 per folder × 3 sub folders) into a new folder structure, sent in parallel batches of 4–10 entries per RDM_copy_entries call.
Honestly, I think the main bottleneck might just be Hub Business itself — even when I move or copy a larger number of entries manually in RDM, it also takes quite a while. So the MCP timeouts might simply reflect that underlying latency rather than anything specific to the MCP layer.
Thanks,
Daniel

Could most likely be issues regarding Hub, now called Devolutions Cloud especially if you're experiencing the same issues in the Web UI or RDM. I'll relay the information to my colleagues so they can look at it.

The MCP server in itself is using the same paths as what the UI of RDM would be using tweaked to work with a prompt and no UI interactions in RDM (confirm dialogs).