Skip to main content
Glama
zb-ss

Servonaut

by zb-ss
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

waf_rate_rule_set

Create or remove a WAF rate-based rule on a site's WebACL to stop request floods, with per-IP limits, optional URI scope, and reversible removal.

Instructions

Create/attach (or remove) a WAF rate-based rule on a site's WebACL — the durable fix for a flood. 'site' is a WebACL ARN, ALB ARN, or instance id/name. 'limit' is requests per 5-min window per client IP; 'uri_scope' optionally restricts to a URI path prefix. Reversible (remove=true). DANGEROUS — confirm with the user first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteYesWebACL ARN, ALB ARN, or instance id/name.
limitNoRequests per 5-minute window per IP (default 2000).
actionNo'block' enforces; 'count' only meters (dry-run).block
regionNoAWS region override.
removeNoRemove the named rule instead of adding it.
accountNoAWS account label a WebACL/ALB ARN site (or a named ban config) is in; omit for the default account. An instance site always uses its own account.
rule_nameNoRule name (idempotent — reusing it updates the limit).servonaut-rate
uri_scopeNoOptional URI path prefix to scope the rule to (e.g. '/').

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.28.0
    • addedInput schema / properties / account
      Added value: +{
+  "description": "AWS account label a WebACL/ALB ARN site (or a named ban config) is in; omit for the default account. An instance site always uses its own account.",
+  "type": "string"
+}
  2. Addedv2.24.0
  3. Removedv2.23.8
  4. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden well: it discloses reversibility and its mechanism (remove=true), the mutation is flagged DANGEROUS with a confirmation requirement, and the semantics of limit are spelled out. It omits permission/auth requirements and failure behavior, keeping it out of the top band.

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 core action and the durable-fix rationale, then parameter clarifications, then the danger warning. Every clause carries information; slightly dense packing of multiple concerns into one paragraph keeps it from a 5.

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 an 8-param mutation tool with no annotations and no output schema, the description covers purpose, key parameters, reversibility, and a safety warning. It leaves gaps around required permissions and behavior on partial/misconfigured input, but is largely sufficient to call it correctly.

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 description coverage is 100%, so the schema already documents all eight parameters, making 3 the baseline. The description re-explains site, limit (per-client-IP per 5-min window), and uri_scope, adding slight emphasis but little beyond the schema text.

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 set (create/attach/remove) and precise resource (WAF rate-based rule on a site's WebACL), and frames it as 'the durable fix for a flood', which distinguishes it from ephemeral siblings like block_ip/ip_ban_set. An agent can tell what it does without opening the schema.

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

Usage Guidelines4/5

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

Gives clear situational context ('the durable fix for a flood') and a critical precondition ('confirm with the user first'). It does not explicitly name the alternative tools (block_ip, ip_ban_set) or state when NOT to use it, so it stops short of the top band.

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