vps-mcp-server

firewall

Check UFW status, allow or deny ports, and delete rules to control VPS network access.

Instructions

Manage UFW firewall rules (status, allow, deny, delete)

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": {
      "action": "<action>"
    },
    "name": "firewall"
  }
}

Input Schema

Name	Required	Description	Default
`rule`	No	Rule specification (e.g., '80/tcp', '443', 'from 10.0.0.1')
`action`	Yes	Firewall action

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Aug 9, 2026

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists actions like 'delete' and even 'reset' (the latter only in schema) which are destructive, but does not warn about potential side effects, permission requirements, or reversibility. The description gives no safety-relevant context beyond naming the actions.

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?

The description is a single concise sentence with the core purpose front-loaded. Every word contributes value, and it avoids redundancy with the schema. It is appropriately sized for a tool with a small parameter set.

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

Completeness2/5

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

Given the tool's potential for destructive actions (delete, reset) and lack of annotations or output schema, the description should provide more context such as safety warnings, when rules are required, or what status returns. The description is too minimal to fully prepare an agent for safe and correct usage.

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%, so the schema already documents both 'action' and 'rule' with examples. The description adds no extra meaning about parameter semantics, and it omits the 'reset' action from its list, though the schema covers it. The baseline of 3 is appropriate because the schema does the heavy lifting, but the description fails to clarify the conditional requirement of 'rule' (not needed for status/reset).

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 clearly identifies the tool as a UFW firewall manager with a verb ('Manage') and specific resource ('UFW firewall rules'), and lists common actions in parentheses. It distinguishes itself from sibling tools like manage_service and docker. However, the verb 'manage' is somewhat generic and the action list omits 'reset', which appears in the schema, slightly reducing specificity.

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 guidance on when to use this tool versus alternatives such as run_command or manage_service. The description does not provide context for when this tool is appropriate, nor does it mention exclusions or prerequisites. The usage is only implicit from the sibling context.

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

Deploy Server