[Try & share] Connecting RDM MCP with your AI provider

Here are my first impressions after a few days of testing the MCP server in RDM:

• I’m missing the ability to add new entries via MCP.
• It would be great to create/manage templates (not just use existing ones).
• I’d love to read/stream console output, e.g., what’s happening in a terminal during an SSH session to a Linux VM.

Also, will vault search be improved? With a “base” of ~600 entries, the search currently expands to ~40k tokens, but my Claude context window is set to 25k—so queries get truncated. Server-side indexing, chunked retrieval, or embeddings-based filtering before sending data to the LLM would help a lot.
Thanks for the experimental release—looking forward to where this goes!

Hi @ts-avn,

Let me start by introducing myself — I’m Maxime, the Software Architect behind the MCP server in RDM.

I wanted to take a moment to say that the ideas you’ve shared are excellent. Many of them are already on our roadmap, so let’s go through them one by one.

Adding new entries
I’ve postponed this task a bit further down the timeline because my focus right now is on delivering as many core features as possible for the MCP server. That said, it’s definitely coming.

Create / Manage templates
We already support a form of template creation with the tool RDM_create_custom_entry_template. This utility lets you build custom entry templates that don’t exist in RDM by leveraging Custom Fields.

For example, we once had a customer who needed a SIM card entry with specific fields. We built the MCP tool and used it internally with Sonnet 4.5 to create the entry template for that customer — the tool was originally designed specifically for that kind of use case.

As for your suggestion — template creation and management will likely come right after Adding entries. Once that’s done, implementing template creation should be relatively straightforward from a development standpoint.

Read / Stream output of SSH sessions
Good news! I’ll have something for you very soon. The main developer behind the SSH console in RDM is currently implementing the missing pieces I need to read the SSH console output directly into the LLM.

This will unlock tons of use cases — live debugging, back-and-forth interaction with the LLM, and much more. Development should be done in about 2–3 weeks, and I’ll make sure it’s included in a patch release of 2025.3. Keep an eye on the release notes!

Search entries
You’re absolutely right — I knew performance would be an issue even before running large-scale tests. Returning massive JSON payloads to the LLM burns through tokens quickly, and that’s something I’ve been aware of.

I don’t have an ETA yet, but I’ll try to tackle it in parallel with other work. My plan is to roll it out in three phases:

• Basic search
• Advanced search
• Multi-vault search

What we’re working on
I’m currently working on a new tool to expose the use of RDM’s built-in tools — such as Ping, Restart, Shutdown, Wake-on-LAN, Traceroute, and more. The goal is to make these utilities accessible through MCP for automation and integration scenarios.

In addition, we’re working on Importing entries using MCP, supporting XML, CSV, and JSON formats for all the major providers already supported in RDM. This will greatly simplify onboarding and data migration workflows.

On a related note (though not strictly MCP-related), I’m also working on improving the SSH terminal by adding an AI feature that can generate SSH commands from natural language. In parallel, one of my colleagues is developing the AI Assistant entry, which will act as a side helper for any entry connected through the RDM MCP server. The SSH entry will greatly benefit from that integration once it’s ready — we’re aiming for a 2026.1 release.

Thanks again for the great suggestions!
I really appreciate seeing this level of feedback — it helps shape the future of the MCP server and ensures we’re building features that truly bring value to power users and integrators.

Hi @Maxime Forest,

thanks for the detailed reply and roadmap!
The plans for streaming SSH output and improving search sound great. One thing I forgot to mention earlier: importing entries via MCP (XML/CSV/JSON) is a perfect fit for my needs — it’s exactly what I’m looking for to simplify onboarding and migrations across environments. Awesome that it’s on the roadmap.

+1 from me for:

• adding new entries,
• template management afterward,
• and general search optimization to better stay within the context window.

Fingers crossed for 2025.3 and beyond — thanks for being so open to feedback!

Tried using it with Google Antigravity IDE, which is basically a fork of VSCode OSS.
Unfortunately it's MCP Client implementation seems to error out when it tries to use the RDM MCP Server, and it is unable to fulfill any request until I remove/disable the RDM MCP Server.

See below for the Error I'm getting:

Trajectory ID: 889d4131-d37c-43c9-b672-1c71e0c5cf39
Error: HTTP 400 Bad Request
Sherlog: 
TraceID: 0xcc2e62ee5d5cfbce
Headers: {"Alt-Svc":["h3=\":443\"; ma=2592000,h3-29=\":443\"; ma=2592000"],"Content-Length":["1624"],"Content-Type":["text/event-stream"],"Date":["Thu, 19 Feb 2026 12:06:33 GMT"],"Server":["ESF"],"Server-Timing":["gfet4t7; dur=373"],"Vary":["Origin","X-Origin","Referer"],"X-Cloudaicompanion-Trace-Id":["cc2e62ee5d5cfbce"],"X-Content-Type-Options":["nosniff"],"X-Frame-Options":["SAMEORIGIN"],"X-Xss-Protection":["0"]}

{
  "error": {
    "code": 400,
    "message": "* GenerateContentRequest.tools[16].function_declarations[0].parameters.properties[vaultsRequest].properties[vaults].items.properties[vaultContentType].enum: only allowed for STRING type\n* GenerateContentRequest.tools[16].function_declarations[0].parameters.properties[vaultsRequest].properties[vaults].items.properties[vaultContentType].enum[6]: cannot be empty\n* GenerateContentRequest.tools[16].function_declarations[0].parameters.properties[vaultsRequest].properties[vaults].items.properties[vaultAllowAccessRequestRole].enum: only allowed for STRING type\n* GenerateContentRequest.tools[16].function_declarations[0].parameters.properties[vaultsRequest].properties[vaults].items.properties[vaultAllowAccessRequestRole].enum[4]: cannot be empty\n* GenerateContentRequest.tools[20].function_declarations[0].parameters.properties[parameters].properties[ping].properties: only allowed for OBJECT type\n* GenerateContentRequest.tools[20].function_declarations[0].parameters.properties[parameters].properties[wakeOnLan].properties: only allowed for OBJECT type\n* GenerateContentRequest.tools[20].function_declarations[0].parameters.properties[parameters].properties[portScan].properties: only allowed for OBJECT type\n* GenerateContentRequest.tools[20].function_declarations[0].parameters.properties[parameters].properties[shutdown].properties: only allowed for OBJECT type\n* GenerateContentRequest.tools[20].function_declarations[0].parameters.properties[parameters].properties[traceRoute].properties: only allowed for OBJECT type\n",
    "status": "INVALID_ARGUMENT"
  }
}

mcp_config.json

{
    "mcpServers": {
        "rdm-mcp": {
            "type": "stdio",
            "command": "C:\\Program Files\\Devolutions\\Remote Desktop Manager\\runtimes\\win-x64\\native\\jetsocat.exe",
            "args": [
                "mcp-proxy",
                "-",
                "np://RDM.MCP"
            ]
        }
    },
    "inputs": []
}

It seems to not recognize the type property.

But the VSCode integration connects properly.
I tried asking it to open a specific RDP Entry, but it seems to be unable to find it, despite me telling it the exact name and folder where it is located.
It instead asks me if I wanted to open a different entry that is somewhat similar in name and in the same folder.

Though giving the AI the exact ID of the entry I asked for, works at least.
All in all it seems it really does need some way to search for entries here, to avoid truncated results or being unable to find the entry it's being asked for.
So definitely a +1 from me as well on search optimizations.

I also noticed at least for me that it seems to just call RDM_get_entry when prompted to open a RDP connection, I had quite a few problems with the AI not knowing about the tools that are available to it or denying their existence, so I specifically had to tell it to use RDM_open_connection and reference the tool in the prompt so it would finally use it, though this might be more of an issue with the AI itself.

It will surely be interesting to see where this will go in the future, don't have much of a use case for it myself, due to us not wanting to give cloud AI access to sensitive information, but it could be interesting for use cases with local AI/LLMs.

I'll definitely keep my eye on this.

Hi @M-Roth,

I've installed the latest version of Antigravity v1.18.3 to do some testing on my end.

I was able to connect to the RDM MCP server without any issues, as you mentioned in your post (disable, enable).

I tried my usual Open connection tests using my regular prompts:
"List my entries in the vault <vault> in the datasource <datasource_name>"
"Open the entry <entry name>"

It used the expected RDM MCP tools:

1. RDM_list_datasources
2. RDM_list_vaults
3. RDM_search_entries
4. RDM_search_entries (used a more specific query to get the exact entry id for the second prompt)
5. RDM_open_connection (the expected SSH terminal opened in RDM)

In my tests, I used Planning mode with Sonnet 4.6 (Thinking).

If you try it again and have the same problems, let me know the model and the prompts you've used so I can investigate on my end to improve it.

I've done some internal testing with local LLMs ~2 months ago, and what I concluded is that the current hardware I'm working on—a laptop—isn't powerful enough to load the larger models. The small models were able to complete some tasks, but it took 30-40 minutes in some cases. We might check it again soon, but we're focusing on the major cloud providers for now: GitHub Copilot (coming in 2026.1), OpenAI, Anthropic, etc which are far better in terms of performance and accuracy for executing RDM tools.

In 2026.1 we'll also be releasing an AI Assistant entry embedded directly in RDM that connects to the RDM MCP server. This will remove the necessity to use a third-party application like Antigravity, VS Code, etc.

Best regards,

Hi @Maxime Forest,

thanks for the quick response,

I gave it another try on my laptop with my personal devolutions hub account, also with Claude Sonnet 4.6 (Thinking) on the latest Antigravity version v1.18.3.

It seems to work fine there, except where it tries to list vaults on a data source that doesn't have vaults, then telling me there seems to be a problem because it couldn't see any entries 🤦.
Works fine though once I tell it, that it should just try to list entries.

I used Gemini 3 Flash before, and well, trying that again it continously errors just like before.
So for some reason having the MCP Server for RDM added somehow breaks using Gemini 3 Flash 🤷.
I would assume that's a bug on their end.
Can you confirm that Gemini 3 Flash also breaks on your end with the RDM MCP Server added?
I assume it's not a me issue if I got it on 2 different machines now

I just tried the Gemini 3 Flash and I'm getting similar errors as you've had. Each models have their strengths and weaknesses. I'm reading more deeply about Gemini 3 Flash and it's written in multiple places that it excels in MCP tool calling. It could technically be how it's used in Antigravity that's causing issues.

After reopening Antigravity I also got the same error that you got regarding disabling and enabling the MCP server to make it work. I have gotten a similar issue in VS Code before but I'll log an issue for that.

In the meantime, I suggest you keep using Sonnet if that works for you.