Skip to main content
Glama
Sign In
vpnhop

vpnhop

by kylepantall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Connect a VPN profile

connect
Idempotent

Starts a VPN tunnel for a named profile and waits until it is ready, reusing an active tunnel and surfacing redacted client logs on failure.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "profile": "<profile>"
    },
    "name": "connect"
  }
}

Input Schema

NameRequiredDescriptionDefault
profileYesProfile name from list_profiles.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotentHint and openWorldHint, and the description adds genuinely new behavior: the call blocks until the tunnel is up, an existing tunnel is reused rather than restarted, and failures surface the redacted VPN client log. That failure-path detail is useful for an agent deciding how to report errors, though nothing is said about auth requirements or how long the wait may take.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each doing distinct work: what it does, the alternative path, tunnel reuse, and failure behavior. The blocking semantics are front-loaded where an agent will read them first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, annotation-covered tool this covers purpose, blocking behavior, reuse, and error output. The only gap is what a successful call returns (e.g., assigned address or state), which matters somewhat since there is no output schema to fall back on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema coverage ("Profile name from list_profiles"), and the description adds no syntax or naming detail beyond "for a profile." The schema already carries the meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ("Starts the tunnel for a profile") plus the key scope detail that it blocks until the tunnel is up and reuses an already-running tunnel. It also names the sibling that overlaps in behavior (http_request) so the agent can tell the two apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical noting that http_request also brings the tunnel up on demand gives a real routing cue for when this tool is or isn't necessary. It stops short of an explicit "use this when / don't use this when" rule, so the agent must infer that this is the explicit, wait-until-ready path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools