firewall-aiops

wireguard_status

Read-only

Check WireGuard peer status—connected state, last handshake, and transfer—to verify VPN tunnel health on a firewall target.

Instructions

[READ] WireGuard peers with connected state, last handshake, transfer.

Args: target: Firewall target name from config; omit for the default.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "wireguard_status"
  }
}

Input Schema

Name	Required	Description	Default
`target`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.0Aug 4, 2026

TDQS

B3.4/5.0

Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read, so the description's job is to add beyond that. It does add value by enumerating the returned data (state, last handshake, transfer), which partially substitutes for the missing output schema, but it reveals nothing about permissions, target resolution behavior, or failure modes.

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?

Front-loaded with the read tag and the resource/payload in the first clause, with no filler. The Args block is a slightly mechanical way to present a single parameter but wastes nothing.

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 simple read-only status tool with one optional param and no output schema, the description covers what is needed: what it returns, and how the target argument resolves. Nothing critical to correct invocation is missing, though error behavior and whether 'default' means default firewall target could be spelled out.

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 0%, so the description carries the full burden for the single parameter, and it does: 'Firewall target name from config; omit for the default' explains both the value source and the default behavior. Slight gap in that valid target names are not described, but this is solid compensation for one param.

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

Purpose4/5

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

The description names the specific resource (WireGuard peers) and what is reported (connected state, last handshake, transfer), which distinguishes it from siblings like openvpn_sessions and ipsec_sas. The verb is implied by the tool name/status pattern rather than stated outright, so it falls just short of a 5.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no alternatives named, even though sibling VPN/session tools (openvpn_sessions, ipsec_sas) exist. The only usage hint is that target may be omitted for the default, which is parameter guidance rather than tool-selection guidance.

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