Set up an AI assistant

Remote Desktop Manager supports AI integration with Azure OpenAI, OpenAI, Ollama, Gemini, Mistral AI, Claude (Anthropic) and Azure AI Inference. The Custom provider also connects to any service compatible with the OpenAI, Claude or Ollama API. These can be leveraged through an AI assistant session entry or the AI assistant panel.

Data is only processed through these customer provided AI integrations.

To link your preferred AI provider with Remote Desktop Manager via a session entry, follow the steps below:

1. Click Edit – Add entry, then find the AI assistant entry under Session – Other. Click Select.
2. Enter a Name for the new entry, choose a Provider and select a Model. Depending on the provider, also enter an API key, an Endpoint or both. Click Save.

To use the AI assistant as a separate side panel, head over to File – Settings – AI assistant, enter your provider’s information, and click Save. Then, click Window – AI assistant, located in the Communication group.

Configure a custom provider

Use the Custom provider to connect to a service that is not in the provider list but exposes an OpenAI, Claude or Ollama compatible API, such as a self-hosted server (llama.cpp, for example), an AI gateway or a proxy approved by your organization. When your service is one of the named providers, select that provider instead.

1. In the Provider list (in File – Settings – AI assistant or in an AI assistant entry), select Custom, then click Configure.
2. Fill in the settings described below, then click Save.
3. Click the Refresh button next to the Model list, then select a model.

SETTINGS	DESCRIPTION
Provider	The API your service is compatible with: OpenAI, Claude or Ollama.
Base URL	The address of the service, starting with http:// or https://. Remote Desktop Manager adds the API paths to this address, so include the version segment the service expects. For an OpenAI compatible service, the address usually ends with /v1 (for example, http://localhost:8080/v1). Click Validate to send a request to the Base URL with the configured headers and confirm that the service is reachable.
API mode	Shown when Provider is OpenAI. Choose the OpenAI API used to send requests: Chat completions: Works with self-hosted backends that do not keep server-side conversation state. Use this mode for those backends. Responses API: Requires a backend that keeps server-side conversation state. With a backend that does not, the first message of a conversation succeeds and the second one fails.
Header	HTTP headers sent with every request, including model discovery. Click Add to add a header, then fill in its Name and Value in separate fields. The Custom provider has no API key field, so use a header to authenticate. For example, enter Authorization in Name and Bearer <token> in Value. Entering the full header (Authorization: Bearer <token>) in Name fails with the message Property Header has an invalid value.

When the Provider is OpenAI, the model list comes from a GET request to <Base URL>/models. With a Base URL ending in /v1, this is the standard /v1/models endpoint. When the Provider is Ollama, the list shows the models installed on the Ollama server.

Connect an AI assistant to local MCP server

1. First, configure a local MCP server.
2. Open the MCP servers tab (either in File – Settings – AI assistant or in an AI assistant entry), then click Add. The tab is shown once a Provider is selected.
3. Enter a Name for your MCP server and select its Transport. For HTTP, enter the Server URL. For Stdio, enter the Command. Click Save to close the dialog, then click Save again to apply the changes.

Avoid enabling a content-fetching MCP server and an action-capable MCP server in the same AI assistant unless your workflow requires both. A content-fetching server, such as the Devolutions documentation MCP server or a web search server, places third-party text in the model's context. An action-capable server, such as the Remote Desktop Manager MCP server, exposes tools that can update stored passwords, generate OTPs or run commands on connected hosts. When both share a context, instructions hidden in fetched content could lead the model to call those tools (indirect prompt injection).

Pages returned by the Devolutions documentation MCP server are marked as untrusted content that the model must treat as data to cite, never as instructions to follow. This reduces the risk but does not eliminate it, and other third-party content-fetching servers may not offer this protection.

See also

• Spotlight on: Remote Desktop Manager AI assistant
• Devolutions Academy – Create and use AI assistant in RDM