Skip to main content
Glama
piyushladhar

iotamine-mcp

by piyushladhar

update_firewall_rules

Replace the full firewall rule set for a VPS, requiring confirmation to prevent SSH lockout.

Instructions

Replace this VPS's entire firewall rule set with the given list. Requires confirm=true — this can lock out access (including SSH) if the rules are wrong; double-check with the user before calling. Each rule should match the shape returned by list_firewall_rules.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rulesYes
vps_idYes
confirmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A5/5.0
Behavior5/5

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

The description goes beyond the neutral annotations by disclosing that this replaces the entire rule set and can lock out access including SSH. It also notes the confirm requirement, giving the agent critical behavioral context for a mutating operation.

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 three purposeful sentences; the main action is front-loaded, followed by a critical safety warning and a rule-shape pointer. No filler or redundant phrases.

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 destructive mutation with no output schema and neutral annotations, this description provides enough context to call the tool safely: what the action does, what the caller must confirm, the danger of lockout, and where to find the expected shape of rules.

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

Parameters5/5

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

With 0% schema coverage, the description compensates well: it explains rules by referencing list_firewall_rules, implicitly describes vps_id as the VPS this operates on, and explains confirm as required before proceeding. This adds meaning the schema lacks.

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?

The description uses a specific verb and resource: 'Replace this VPS's entire firewall rule set', which clearly conveys a full replacement operation. It is easily distinguished from siblings like list_firewall_rules and other VPS management tools.

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?

It states explicit usage conditions: confirm=true is required, and the user should be double-checked before calling. It also guides rule construction by pointing to list_firewall_rules for the expected shape, and warns about potential SSH lockout.

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