Valenius Pro exposes its entire administration surface twice over: as a conventional REST API, and as an MCP server — the protocol AI assistants use to call real tools. Point Claude, Gemini, ChatGPT or Mistral at your own backend and manage the whole VPN in plain language, with permissions you control down to the individual action.
Almost nothing an admin does on a VPN is creative work. It’s finding the right device, checking a state, flipping a flag, and writing it down. That is precisely the shape of work an assistant with real tool access does well — and it’s why handing it the whole surface, rather than a read-only dashboard, is what actually saves time.
“Which Windows clients on the beta channel haven’t checked in since Friday?” is one sentence. In a panel it’s three filters, a sort, and a mental note. The assistant cross-references fields you’d otherwise compare by eye.
A laptop is reported stolen. One instruction — find the device, kill its tunnel, deactivate it, and tell me what it had access to — replaces a sequence of screens someone has to remember correctly while half asleep.
Colleagues who have never opened the admin panel can still ask for what they need in their own words. The token decides what they’re allowed to do — so first-line support can look without being able to break anything.
“Create customer Acme, generate a pairing code, and mail me the details.” What used to be a short checklist becomes a single request — with the same provisioning logic underneath as the panel uses.
“Which customer used the most traffic last week, and is anyone unusually quiet?” The assistant pulls the numbers and reasons about them, instead of handing you a CSV to open in a spreadsheet.
“Who changed MFA policy last month, and on which clients?” The audit log is queryable through the same interface — useful when someone asks you to evidence access control rather than describe it.
Every one of these maps onto real operations the assistant performs through the API — not a summary of a document, and not a guess.
MCP is an open protocol, not a partnership — so this isn’t one vendor’s assistant bolted on. Any MCP-capable client can connect, using an ordinary Valenius API token as its credential. No AI-specific account, no separate password, nothing new to trust.
Claude Code connects with a single claude mcp add command and is the smoothest route today. Note that the Claude Desktop app’s own connector flow expects an OAuth sign-in rather than a fixed token, so Claude Code is the one we point people to.
Gemini CLI takes the server as a few lines in its settings file, including the authorisation header — and it will read the token from an environment variable, so it never has to sit in the config itself.
Through the OpenAI API, Valenius is passed as an MCP tool on a Responses call — a few lines of JSON. The consumer ChatGPT app’s Connectors feature is built around OAuth sign-in, so for a fixed Valenius token the developer API is the path that works.
Mistral registers the server as a Connector with a plain bearer header — genuine fixed-token support, no OAuth dance. Useful if you want a European model provider in front of a European VPN platform.
This is the whole setup for Claude Code. The other assistants are a short block of configuration each — the help guide has all four, copy-pasteable.
# point Claude Code at your own backend
claude mcp add --transport http valenius \
https://vpn.example.com/api/mgmt/v1/mcp \
--header "Authorization: Bearer vlnm_..."
n8n can talk to Valenius two ways, and they suit different jobs. Use the MCP node when you want an agent to work out what to do; use a plain HTTP request when the workflow already knows exactly what should happen and must do it the same way every time.
Give an n8n AI Agent the Valenius MCP server as a tool and it can decide which calls to make. Good for open-ended triggers: a helpdesk ticket arrives in free text, and the agent works out which device it refers to and what to do about it.
No AI in the path at all: point n8n’s standard HTTP node at a REST endpoint with a bearer header. Same result every run, fully predictable, and auditable in exactly the same way.
Your HR system, Entra ID or personnel spreadsheet adds someone — n8n creates the client, provisions the peer, and emails the pairing QR code. When they leave, the same workflow deactivates the device and kills the tunnel. VPN access stops being a separate manual step somebody forgets.
An approved request in Jira, Zammad or ServiceNow triggers the provisioning — and writes the result back onto the ticket. The approval stays where your auditors already look, and nobody has to trust that someone remembered to do it.
Poll the event feed and push anything interesting into Slack, Teams or Matrix — a site gateway dropping, a client failing to connect repeatedly, a config repair that didn’t work. Nobody needs to keep the panel open to notice.
A nightly run that flags devices which haven’t connected in 30 days, clients still on an old build, or customers with no active endpoints — delivered as a short digest instead of something you have to remember to check.
Onboarding a new client company becomes one workflow: create the customer, configure DNS and routes, mint an enrollment token for their gateway, and issue a customer-scoped API token they can use themselves — isolated from your other tenants.
Pull per-customer traffic and endpoint counts on a schedule and push them into your billing system, a data warehouse, or a monthly report — no manual export step, no month-end scramble.
The MCP server is a thin adapter over an ordinary REST API — so if you’d rather write code than prompts, nothing about the AI layer is in your way. Over 50 endpoints cover clients, customers, provisioning, actions, MFA policy, pairing, traffic and audit data.
The OpenAPI 3.1 specification is generated from the running server, so it can never drift from what’s actually deployed — and it’s served openly, without a token. Paste the URL into Visual Studio’s Connected Services, Postman or an OpenAPI generator and you have a typed client in a couple of minutes.
/api/mgmt/v1/** on your own backend/api/mgmt/v1/mcp, Streamable HTTP transport/api/mgmt/v1/openapi.json, no auth requiredIt’s the right question. The answer is that the assistant has no privileges of its own — it has exactly the token you issued it, and that token is as narrow as you care to make it. Enforcement is server-side, so it doesn’t depend on the assistant behaving well.
Reading and changing are separate permissions, per area. A triage assistant that can list clients and read traffic simply has no ability to disconnect anything — the request is refused by the server, not by the model’s good judgement.
A token can be tied to a single customer. Anything belonging to another tenant doesn’t come back empty — as far as that token is concerned, it does not exist. Useful when an MSP wants to give a client their own assistant.
The ability to read a WireGuard configuration — the one thing containing a private key — is its own separate permission, flagged as sensitive in the panel. An assistant only gets it if you deliberately decide it should.
Every call lands in the same audit log as an admin’s own actions, recorded against the token that made it. Worth knowing: the log identifies the token, not the person prompting it — so issue one per person or agent if you need to tell them apart.
Revoke a token and the next request fails — no cache to expire, no propagation delay, nothing to restart. Tokens can also carry an expiry date and an IP allowlist from the moment you create them.
The backend stays where you put it. There is no Valenius cloud in the path, no phone-home, and no vendor account required — the assistant talks to your server, and only about what you asked.
The Management API and MCP server are part of Valenius Pro — included in the licence, not sold separately. A trial takes a few minutes to set up.