Skip to main content
Glama
Sign In
portveil-mcp

portveil-mcp

by roybogs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Add device

add_device

Registers a new phone, computer, or Linux machine with the Portveil account: creates WireGuard tunnel files for app import or returns root setup commands for Linux servers.

Instructions

Add a new device to the account. kind "phone_or_computer" (iPhone, Android, Mac, Windows using the WireGuard app): creates the device now and saves one WireGuard tunnel file per location, with a private key made locally, into a folder on the machine running this MCP server; the key is never shown in the reply. Import a file in the WireGuard app to connect. These devices are view-only: they can't be moved remotely. kind "linux_machine" (a server or the machine an agent runs on): returns the exact commands to run as root on that machine; it makes its own key and registers itself, and can then be moved, rotated and switched with the other tools. Uses one device slot (see get_account). Needs an admin-scope token for phone_or_computer.

Input Schema

NameRequiredDescriptionDefault
kindYesphone_or_computer: WireGuard app on a phone or laptop. linux_machine: a Linux server or agent machine running the Portveil agent
nameYesDisplay name for the new device, e.g. "Miguel iPhone" or "scraper-box"
folderNophone_or_computer only: folder to save the tunnel files in. Default ~/Portveil/<name>
split_tunnelNolinux_machine only, advanced: default false (full tunnel), which sends everything the machine connects to through Portveil and keeps SSH and other incoming connections on their normal route, so remote servers stay reachable. true only reaches Portveil's own network: the machine's internet traffic would NOT go through Portveil
temporary_minutesNophone_or_computer only: delete the device automatically after this many minutes (5 to 43200, i.e. 30 days). Omit for a permanent device

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.4
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed1 schema field changedv0.4.3
    • changedInput schema / properties / split_tunnel / description
      Previous value: -"linux_machine only: default true, so a remote server keeps its SSH session. false sends all of its traffic through Portveil"New value: +"linux_machine only, advanced: default false (full tunnel), which sends everything the machine connects to through Portveil and keeps SSH and other incoming connections on their normal route, so remote servers stay reachable. true only reaches Portveil's own network: the machine's internet traffic would NOT go through Portveil"
  3. Addedv0.4.1

TDQS

A4.6/5.0
Behavior5/5

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

Substantial disclosure beyond the annotations: the private key is generated locally and never returned in the reply, files land in a folder on the MCP host, phone_or_computer devices are view-only and cannot be moved, linux_machine devices self-register and become rotatable, one device slot is consumed, and an admin-scope token is required for the first kind. Also covers the delayed self-deletion of temporary devices.

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

Conciseness4/5

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

Purpose is front-loaded in the first clause, and every subsequent sentence carries operational information (file output, key handling, moveability, slot usage, auth scope). It is dense and longer than typical, but almost no sentence is filler; a slight trim of the kind restatements would help.

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

Completeness5/5

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

For a 5-parameter mutation tool with no output schema, the description still tells the agent everything needed to call it correctly: which kind to pick, what side effects occur on the local filesystem, what is returned (commands vs. tunnel files, never the key), auth requirements, and capacity implications.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds consequences the schema only hints at — what each kind produces mechanically, that kind selection determines move/rotate eligibility, and that slot budget is affected. It does not restate folder defaults or split_tunnel routing details, which the schema already handles well.

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 specific verb and resource ("Add a new device to the account") and then splits the operation into its two mutually exclusive kinds, explaining what each actually produces (local WireGuard tunnel files vs. root-run commands). An agent can distinguish this from get_device/list_devices/move_device immediately.

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?

Gives clear selection guidance between the two kinds (phone/laptop with the WireGuard app vs. Linux server or agent host) and points to get_account for slot consumption. It does not explicitly state when to use update_device or move_device instead, but the mute/edit distinction is conveyed by "view-only: they can't be moved remotely."

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