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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description goes further by quantifying destruction: the old key stops working and tunnels/connections end 'within seconds'. It also discloses a genuine hidden behavior — the generated private key appears in the config and is 'shown once'. It does not cover permission/auth requirements or rate limits.

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

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

The overall purpose is front-loaded, then a compact action-by-action breakdown follows, with no filler sentences. It is dense to the point of being a single run-on paragraph, but every clause carries information an agent needs.

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

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

With six parameters, no output schema, and a mutation-heavy surface, the description carries the return-value burden itself and does so: get returns endpoint, gateway key, peers and per-sandbox addresses; add_peer returns a wg-quick config. The main remaining gap is account/prerequisite detail behind 'Needs a kept top-up' and any preconditions for create.

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

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

With only 50% schema description coverage, the description compensates well: it gives the subnet default (10.250.0.0/16), explains that omitting publicKey makes Runtime generate the pair, ties peerId to rotate/remove, and contextualizes name for add_peer. The only under-specified parameter is the action enum itself, whose values are only implied by the per-action prose.

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

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

Opens with a specific resource (a WireGuard private network connecting the user's own network into sandboxes) and then names every action verb explicitly: create, get, add_peer, rotate_peer, remove_peer. This clearly separates it from sibling network tools such as runtime_networks_private and runtime_networks_upstream_proxy.

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

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

Each action is given a usage context (create it, get endpoint/keys, add a machine or router of yours, rotate to get a new key, revoke a peer), which tells an agent which action to pick for a given intent. It stops short of naming alternatives or stating when-not to use this tool versus its network siblings, and 'Needs a kept top-up' is left unexplained.

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