Which AI agents can connect to rConfig over MCP?

Which AI agents can connect to rConfig over MCP?

Any agent that speaks MCP over Streamable HTTP and can send a fixed Authorization: Bearer header can connect to rConfig. In practice that means the agents that run on an engineer’s machine or your own servers (Claude Code, Claude Desktop, Cursor, VS Code with GitHub Copilot, Codex CLI, Gemini CLI, self-hosted n8n) work today. ChatGPT does not, and Claude on the web works only when rConfig is reachable from the internet.

What a client needs

rConfig’s MCP server lives at https://<your-rconfig-server>/mcp. A client has to meet four conditions to use it:

1. Streamable HTTP transport. The server does not offer stdio or the older SSE transport.
2. A static bearer token. The server accepts a personal access token with the mcp:read ability, sent as Authorization: Bearer <token>. It has no OAuth flow.
3. A network path to rConfig. The connection starts wherever the client runs. A client on a laptop needs the laptop to reach rConfig; a client hosted in a vendor’s cloud needs rConfig to be reachable from that cloud.
4. Trust in rConfig’s certificate. The endpoint is HTTPS only. With an internal CA, the client’s runtime has to trust that CA, or the connection fails with a vague error.

The second and third conditions are the ones that rule clients in or out.

Compatibility table

Checked against each vendor’s documentation on 7 November 2026. Connection snippets for each client are on the MCP server page.

Clients not listed (Windsurf, Cline, Microsoft Copilot Studio and others) may work. Check them against the four conditions above: if the client can send a custom Authorization header over Streamable HTTP and can reach your server, it should connect.

Where the agent runs decides your network design

flowchart LR
    subgraph net["Your network"]
        L["Engineer's laptop<br/>Claude Code, Cursor, VS Code, Codex"] --> RC["rConfig<br/>/mcp"]
        S["Automation host<br/>n8n, headless agents"] --> RC
    end
    subgraph cloud["Vendor cloud"]
        C["claude.ai custom connector"]
        G["ChatGPT"]
    end
    C -. "needs a public HTTPS path" .-> RC
    G -. "not supported:<br/>no bearer token option" .-> RC

Local and self-hosted clients connect from inside your network, so rConfig can stay on a private address. This is the simplest and most common setup, and the only one that works for an air-gapped site.

Cloud-hosted clients connect from the vendor’s infrastructure. To use a claude.ai custom connector, /mcp has to be published through your edge, typically behind a reverse proxy that exposes only that path and restricts source addresses. Weigh that carefully: the endpoint returns full device configs (secrets obfuscated) to anyone holding a valid token.

Tokens and what the agent can see

• A token belongs to one user. Every result is limited to the devices that user can see under Roles. An agent holding an admin’s token sees every device.
• Engineers can create their own tokens. Give their role aicenter.mcptoken. They get a token limited to their own device access without the right to change AI settings.
• For automation, use a dedicated user. Give a service user a role limited to the devices the automation needs. An admin creates the token for that user from the MCP Server tab (Token for) without signing in as them. Revoking the token, or disabling the user, cuts the automation off without touching anyone else.
• Tokens expire. A new token lasts a year unless you choose otherwise, and No expiry is an explicit choice. Admins see and revoke the tokens of users they manage. Treat tokens like any other credential: environment variables or a secret store, never committed to a repository.

Every tool call is written to rConfig’s activity log with the tool name, the outcome and the device ID, so you can see what each agent did.

Which model sees your configs

The MCP server hands data to the agent. The agent then sends it to its own model: Claude for Claude Code, whatever model you’ve selected in Cursor or Copilot, OpenAI for Codex. rConfig’s AI provider setting doesn’t apply. If configs must stay on your network, the agent itself has to run against a local model, not just the Iris features inside rConfig.

Related reference

• Connect an AI agent over MCP: token creation, connection snippets for each client, and connection checks
• Download the rConfig Skill: teaches a connected agent how to use the tools well
• AI Center governance, audit trail and privacy
• Troubleshooting MCP connections