Skip to main content
Glama
roybogs

portveil-mcp

by roybogs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Move device

move_device
Idempotent

Moves a device's VPN exit to a chosen country, city, or region, waits for the switch to be confirmed, and reports if it did not happen. Repeating the same location is harmless.

Instructions

Move a device's traffic to exit from a chosen location. Waits until the device switches and the new exit server confirms it (usually 10–30 s), and says plainly if that didn't happen. Safe to repeat: moving to where it already is does nothing. Only works on machines running the Portveil agent with remote control on (phones using the WireGuard app switch on the device itself). Needs a control-scope token. To just go somewhere different, use rotate_device.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deviceYesWhich device: its name, a unique part of its name (e.g. "scraper"), or its device ID (dev_…). Case-insensitive. Get names and IDs from list_devices.
locationYesWhere to exit: a country, city or region ("Finland", "US", "Helsinki") or a location ID from list_locations (e.g. srv-eu-1)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.0
    • changedInput schema / properties / device / description
      Previous value: -"Device name (or part of it, e.g. \"scraper\") or its device ID (dev_…)"New value: +"Which device: its name, a unique part of its name (e.g. \"scraper\"), or its device ID (dev_…). Case-insensitive. Get names and IDs from list_devices."
    • changedInput schema / properties / location / description
      Previous value: -"Where to exit: a country or city (\"Finland\", \"US\", \"Helsinki\") or a location ID (srv-eu-1)"New value: +"Where to exit: a country, city or region (\"Finland\", \"US\", \"Helsinki\") or a location ID from list_locations (e.g. srv-eu-1)"
  2. First observedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already signal idempotency and non-destructiveness; the description reinforces this with 'moving to where it already is does nothing' and adds timing, success/failure reporting, and prerequisites such as the agent requirement and token scope. No contradiction with annotations.

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?

Every sentence serves a purpose: action, wait/result behavior, idempotency, prerequisites, alternative. The main action is front-loaded, and no filler exists.

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?

Covers prerequisites, expected behavior, failure reporting, idempotency, and alternative routing. The input schema documents both parameters fully, and no output schema exists, so the description's statement about clearly saying if the switch didn't happen is sufficient.

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?

Schema coverage is 100% with detailed descriptions for both device and location, so the description doesn't need to add parameter-level detail. It adds the high-level semantic that location is the desired exit, which maps to the schema's 'Where to exit' description, but provides no additional syntax or formatting clues.

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 ('Move a device's traffic to exit from a chosen location') and explicitly differentiates from rotate_device, so an agent can distinguish purposes.

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

Usage Guidelines5/5

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

Explicitly says when the tool works ('Only works on machines running the Portveil agent with remote control on'), what it needs ('control-scope token'), and names rotate_device as the alternative for simply choosing a different location.

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