Skip to main content
Glama

List firewall ACL rules

list_acls
Read-onlyIdempotent

List gateway, switch, or EAP ACL rules (setting/firewall/acls?type=0|1|2) with policy, source/destination…

Instructions

List gateway, switch, or EAP ACL rules (setting/firewall/acls?type=0|1|2) with policy, source/destination…

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": "list_acls"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteNo
aclTypeNogateway

Output Schema

NameRequiredDescriptionDefault
countYes
itemsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • addedInput schema / properties / site
      Added value: +{
      +  "type": "string"
      +}
  2. First observedv1.2.2

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered elsewhere. The description adds only the underlying endpoint path and the numeric type encoding, which is modest extra context; it says nothing about auth requirements, rate limits, or result volume beyond the safety annotations.

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

Conciseness3/5

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

It is short and front-loaded with the action and resource, which is good. However, it is truncated mid-phrase ('source/destination…'), leaving an incomplete sentence, and the raw API path with query string is implementation noise an agent cannot act on.

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

Completeness3/5

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

An output schema exists, so return values need not be described, and this is a simple two-parameter list operation. Still, the description is cut off and leaves the 'site' parameter and the aclType default undocumented, which is a real gap for a zero-coverage schema.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry the parameter meaning. It partially covers aclType by mapping gateway/switch/EAP to type=0|1|2, but it never explains what aclType=all returns, that the schema default is 'gateway', or what the 'site' parameter does at all.

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 verb 'List' plus the resource 'ACL rules' is specific, and it narrows scope to gateway, switch, or EAP ACL rules. It does not name or distinguish itself from any sibling, but the resource is distinct enough that confusion with list_lan_dns_rules or list_policy_routes is unlikely.

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 statement of when to use this tool, when not to, or which alternative to prefer. The mention of an aclType-style selector implies you can narrow by gateway/switch/EAP, but nothing tells the agent which to pick or when 'all' is appropriate.

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