vpnhop
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VPNHOP_CONFIG | No | Path to the vpnhop config file. Defaults to `~/.config/vpnhop/config.json`; relative paths inside the config resolve against the config file's folder. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
vpnhop reaches APIs that sit behind a VPN without connecting this machine to it. Each profile runs its VPN (OpenVPN, WireGuard, OpenConnect/AnyConnect/GlobalProtect/Pulse/Fortinet/F5, IPsec IKEv2) inside its own Docker container. Call list_profiles, then http_request with a profile: it connects on demand, resolves DNS inside the tunnel, and disconnects after the profile is idle. VPN credentials are never shown. Some profiles only allow certain hosts (allowHosts).
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_profilesB | Configured VPN profiles with their type, description, allowed hosts and whether each tunnel is up. |
| connectA | Starts the tunnel for a profile and waits until it is up (http_request also does this on demand). Reuses a running tunnel. On failure the error includes the redacted VPN client log. |
| disconnectB | Stops and removes the tunnel container for a profile. |
| statusB | State of one or all tunnels, optionally with the last lines of the (redacted) VPN client log. |
| http_requestA | Sends an HTTP(S) request from inside the profile's tunnel (connecting first if needed) and returns status, headers and body. Text bodies come back as utf8, binary as base64; bodies over maxBodyBytes are truncated. Redirects are not followed unless followRedirects is set. |
| refreshA | Closes every tunnel (they reconnect on the next call), recycles other running vpnhop servers, stops outdated or orphaned ones, and removes dangling tunnel containers and old runtime images. Use after a tunnel gets stuck or after updating vpnhop. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool maps to a distinct operation: listing profiles, starting/stopping tunnels, inspecting status, sending proxied HTTP requests, and global refresh cleanup. Minor overlap exists because list_profiles reports whether tunnels are up and http_request connects on demand, but the descriptions clarify the intended use of each.
Names use lowercase snake_case and are readable, but conventions are mixed: list_profiles and http_request are verb_noun, connect/disconnect/refresh are bare verbs, and status is a noun. The pattern is understandable but not uniform.
Six tools is a tight, well-scoped set for VPN tunnel management and proxied HTTP requests. Every tool has a clear role and none feels redundant.
Core lifecycle is covered: list, connect, disconnect, status/logs, proxied requests, and global refresh. Profile creation/editing is absent, but profiles appear to be configured externally; a dedicated log-retrieval tool is also missing, though status exposes recent log lines.