firewall-aiops
Server Quality Checklist
Latest release: v0.8.0
- Disambiguation4/5
Most tools target a distinct resource and action, such as interface_status vs gateway_status vs dhcp_leases. However, 'apply_changes' and 'reconfigure' with subsystem='filter' overlap, and 'rule_stats'/'rule_states'/'rule_hit_and_shadow_analysis' could be confused by name, though descriptions clarify.
Naming Consistency3/5Naming mixes verb-noun patterns like list_rules and toggle_rule, noun-only names like health_status and nat_outbound, and single verbs like reboot and reconfigure. While readable, there is no consistent convention across the set.
Tool Count3/535 tools is on the high side, but the firewall domain covers many distinct subsystems: system health, interfaces, gateways, aliases, rules, NAT, VPN, DHCP, logs, and state. The count is justifiable for a comprehensive AIOps tool, though it may feel heavy for agent navigation.
Completeness4/5The server covers most read/monitoring needs and common write operations: toggle rules, add/remove alias entries, apply changes, restart services, reboot, and kill states. Missing create/delete rules or aliases, but for an AIOps tool focused on diagnostics and remediation, the surface is largely complete.
Average 3.9/5 across 35 of 35 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/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. The [READ] prefix explicitly signals this is a read-only operation, which is useful. However, it doesn't describe the return format/structure of the member entries, whether entries follow a specific format, or any pagination/limitation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a docstring-style format, front-loading the purpose in the first sentence and using a short Args section. No filler or redundant content. Slightly under-specified in places but structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% schema description coverage, the description is the only source of information. For a read tool with 2 params, it provides the core purpose and param meanings but lacks return format details, behavioral notes, and edge cases—leaving the agent somewhat blind about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'name' (alias name from list_aliases) and 'target' (firewall target name from config, default when omitted), which adds meaning. However, the 'target' parameter's semantics are thin—'firewall target name' is vague without explaining what targets exist or how to discover them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reads member entries (hosts/networks/ports) of one alias, which is a specific verb+resource. It distinguishes from siblings like list_aliases (which lists aliases) and add_alias_entry/remove_alias_entry (mutations). However, it doesn't explicitly reference these siblings for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The [READ] prefix and 'of one alias' establish context as a read operation, and noting 'name from list_aliases' implies a prerequisite dependency. However, there's no explicit statement of when to use this versus alternatives like list_aliases or rule_detail, and no exclusions beyond the implied read-only nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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. The [READ] prefix indicates a read-only operation, which helps, but the description doesn't disclose what happens with the default target, whether it lists all gateways or fails without a target, or what auth/permissions are needed. For a read-only status tool, the disclosure is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a clear [READ] prefix and a brief description followed by a parameter doc in Args format. No wasted words or redundant content. It's appropriately sized for a simple status tool with one optional parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain the return format. It lists data fields (status, loss %, RTT latency) but doesn't describe how results are structured or what failure modes look like. For a gateway status read with one optional parameter, the coverage is adequate but leaves gaps around output formatting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'target' parameter has 0% schema description coverage, and the description adds context by saying 'Firewall target name from config; omit for the default.' This explains the parameter's meaning and default behavior beyond the schema's bare 'target' property name. However, there are no enums or examples of valid target values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'WAN/LAN gateways with status, loss %, and RTT latency' which clearly identifies the resource (gateways) and the data returned. The [READ] prefix signals a non-mutating operation. It's clear but doesn't explicitly distinguish from sibling tools like gateway_health_rca or interface_status, though the resource focus (gateways vs interfaces) is somewhat implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not explain when gateway status would be preferred over gateway_health_rca, interface_status, or health_status. It only mentions the 'target' parameter for selecting a firewall, with no exclusions or context about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '[READ]' prefix indicates a read-only operation, which is useful. The tool mentions result normalization ('normalized'), suggesting output is processed/organized in a consistent format. However, with no annotations provided, the description carries the full burden and doesn't disclose additional behaviors like pagination, filtering capabilities beyond target, or what fields are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the '[READ]' tag and purpose. The Args section is minimal and efficient. No wasted words, though the format is terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with a single optional parameter and no output schema, the description is mostly adequate: it states the safety profile ([READ]), the resource, and the one parameter. However, it doesn't clarify what 'normalized' means, what fields are returned, or how this relates to the other NAT tools, leaving some gaps for a tool with many closely related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain the 'target' parameter ('Firewall target name from config; omit for the default'), which adds meaning beyond the schema's bare 'Target' title. With only one parameter and the description covering its semantics reasonably well, this is adequate, though paltry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: '[READ] Outbound (source) NAT mappings, normalized'. It specifies what is being read (outbound NAT mappings) and their normalized form. It distinguishes from siblings like nat_port_forwards and nat_one_to_one by explicitly noting 'source' NAT, which differentiates these outbound mappings from other NAT types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal context: it indicates a target parameter for firewall selection. No explicit when-to-use guidance or exclusions are given. With 30+ sibling tools including nat_port_forwards and nat_one_to_one, there's no guidance on when to choose this over those alternatives, though the 'Outbound (source) NAT' phrasing gives some implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. The '[READ]' prefix signals non-destructive intent, and 'Active' implies filtering on currently-tracked states, but the description doesn't explain pagination behavior, whether results are sorted (by size/packets?), what happens when 'top' exceeds available entries, or how 'target' selection affects scope. For a tool with zero annotation coverage, more behavioral detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact - a one-line summary plus a two-argument docstring. It front-loads the core purpose and delivers parameter explanations efficiently. No filler or redundancy. Slightly thin on usage context but appropriately concise for a simple read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (2 optional params, no nested objects, no output schema). The description covers purpose and both parameters. However, with no output schema and no annotations, the description doesn't describe the return format (what fields make up a state entry), which could matter for an agent needing to interpret results. It is adequate for a read-only query tool but marginal for full operational completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting the two parameters. It does explain both: 'top' is how many entries to return, and 'target' is the firewall target name (defaulting to whatever config default applies). However, missing detail on top's type/range constraints, what happens if target doesn't exist, and how the default target is determined. For 2 simple params with defaults, this is adequate but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Active pf state-table entries associated with rules (top-N)', using a specific verb-noun combo that makes clear this reads pf state-table entries filtered by rule association. It distinguishes somewhat from siblings like states_table (which likely returns the raw state table without rule filtering) and rule_stats (which returns hit counts rather than state entries), though it doesn't explicitly name these differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only usage pattern via '[READ]' prefix and the query nature of the tool. It provides basic context (active state table entries, rule-associated, top-N) but gives no explicit when-to-use guidance, no exclusions, and doesn't contrast against siblings like states_table or top_talkers to help an agent choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The '[READ]' marker communicates this is a safe, non-mutating operation, which is useful given the sibling set includes mutating tools (kill_states, reboot, reconfigure). However, it doesn't disclose return format specifics or edge cases (e.g., what happens if no updates are available, or how update availability is determined).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact—two short sentences that convey the purpose and the single parameter. Function-style header '[READ]' front-loads the operational intent. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query with 1 optional parameter and no output schema, the description is reasonably complete. The '[READ]' marker compensates for missing annotations. It clearly states what's returned (version + update availability). However, given no annotations and no output schema, slightly more detail on return structure or update-status semantics could improve completeness, but the tool is simple enough that current coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 1 optional parameter at 0% schema description coverage, the description adds meaning by explaining 'target' refers to a 'Firewall target name from config; omit for the default.' This clarifies semantics beyond the bare schema, though the actual details are minimal and there's no example or value format guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: "Firmware / OS version and whether updates are available." It clearly identifies what information is returned (firmware/OS version + update availability). It distinguishes from sibling tools like health_status, interface_status, and gateway_status which cover different subjects, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There's no guidance on when to use this tool versus alternatives. The '[READ]' prefix and description indicate it's a read-only informational query, but there's no mention of when firmware status would be relevant (e.g., before upgrades) or when to prefer sibling tools. No exclusions or alternate tool suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The '[READ]' prefix signals a non-mutating operation, and the description discloses it's a read/list operation. However, it doesn't explain what happens with the optional target (error vs default firewall), whether any special permissions are needed, or the return format structure. The behavioral disclosure is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two lines plus an Args section). The '[READ]' prefix is an efficient signal. No wasted words. It's concise and front-loaded, though the args explanation could be slightly more detailed without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is near-minimal. There's no output schema, so return format isn't disclosed. With 18+ sibling tools including the closely related dhcp_leases, a bit more context distinguishing this from dhcp_leases would help. The description is adequate for a trivial list tool but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the single parameter 'target' is only described as 'Firewall target name from config; omit for the default.' This does add practical guidance (omit for default), which is useful beyond the raw schema. However, it doesn't explain where 'target' values come from or the format expected, so it only partially compensates for zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'DHCP static (reserved) mappings (MAC ↔ IP)' using a specific noun+resource. It's a clear read-oriented listing tool. It doesn't explicitly differentiate from the sibling dhcp_leases tool, which could be ambiguous to an agent, but the '[READ]' prefix and the MAC↔IP wording make the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it implicitly via '[READ]' prefix and the 'reserved mappings' wording, and explains the optional target parameter. However, it doesn't distinguish when to use this vs dhcp_leases (active leases vs static reservations), and provides no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 for behavioral disclosure. The '[READ]' prefix communicates it's a read operation. It lists what fields are returned (hostname, uptime, CPU, memory, load) which is helpful, but doesn't describe what the response structure looks like, whether it can fail, what the default target is, or how the target is resolved. The functional field listing adds some value but leaves behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two lines of core content plus a compact Args section. Each sentence earns its place: purpose is stated, target semantics are clarified. It is appropriately brief for a simple snapshot tool. Efficient and front-loaded with the read nature and field list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description covers the essential purpose and the single parameter. However, it doesn't describe what the health snapshot output looks like, how often it refreshes, or how to interpret the load values. The output structure is entirely unpredicted. Given the tool's simplicity, it's adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description does explain 'target' as 'Firewall target name from config' and notes it's optional with a default, which does add meaning beyond the schema's bare definition. However, it doesn't specify the target format, valid values, or what happens if an invalid target is given. The description adds some semantic value but is thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'System health snapshot: hostname, uptime, CPU, memory, load' which clearly identifies the verb+resource and the specific fields returned. It distinguishes reasonably from siblings like gateway_status or gateway_health_rca, though those names are distinct enough that differentiation is contextual. The core purpose is clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies read-only status retrieval with '[READ]' prefix and lists what's included. It provides minimal context on when to use this vs siblings like gateway_health_rca, interface_status, or gateway_status. There's no explicit exclusion guidance, but the trailing note about target ('omit for the default') provides some usage context. Overall, usage guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. The '[READ]' tag signals a read-only operation and 'down interfaces first' reveals ordering behavior, which is useful. However, it doesn't disclose what the return format looks like, whether multiple targets are supported, or what happens if the target is not found—valuable behavioral context for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two lines of prose plus an args section. The key facts (read-only, link status + address, down-first ordering) are front-loaded. It's appropriately terse though it could add a line on context/alternatives without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple informational tool with one optional param and no output schema. The description covers purpose and the single param adequately. However, given no annotations and no output schema, it would benefit from a note on the expected return shape and whether 'down interfaces first' includes disabled/administratively-down interfaces, to fully compensate for the missing structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'target' is described as 'Firewall target name from config; omit for the default' which adds some meaning beyond the schema (which just shows a nullable string with null default). The description clarifies that omitting results in the default target. However, schema coverage is 0%, so the description is the only source, and while it covers the one param, it doesn't specify target naming format or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports interface link status plus address, and that down interfaces are listed first (a useful sorting detail). It distinguishes from siblings like gateway_status and health_status by indicating it's about link/address specifically. However, it's somewhat terse and doesn't explicitly differentiate from the sibling tools named similarly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The '[READ]' tag implies safe read-only operation and the target argument is described ('Firewall target name from config; omit for the default'). However, there is no explicit when-to-use guidance, when-not-to-use, or mention of alternative tools—especially important given many sibling tools (gateway_status, health_status) that could overlap in intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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. The '[READ]' prefix signals it's non-mutating, and 'normalized' hints at output format. However, it doesn't disclose return structure, pagination, or whether the default target requires specific config context. For a read-only tool this is moderately adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient—two short lines plus two one-line parameter clarifications. No wasted words. Could benefit from front-loading the most important usage note but is appropriately sized for a simple filtering tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 optional params, no output schema, and no annotations, the description is reasonably complete but misses some details. The '[READ]' marker plus 'normalized' hint covers basics. However, it doesn't explain what fields the returned rules contain or distinguish clearly from rule_detail/rule_stats, which are siblings that could be confused for similar purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add brief meaning: interface is 'an interface name to filter by (e.g. wan, lan)' and target is 'Firewall target name from config'. However, it does not specify what 'default' target resolves to or constrain valid values, leaving the agent to guess the format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List filter rules' with a specific verb and resource, and adds the '[READ]' marker denoting it's a read operation. The optional interface filter is mentioned. It doesn't explicitly distinguish from sibling tools like rule_detail/rule_stats/rule_states, but the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (listing rules, optionally scoped to interface/target) but provides no explicit guidance on when NOT to use it or which sibling tools are alternatives for different needs (e.g., rule_detail for specific rule, rule_stats for metrics). The 'omit for the default' note on target is helpful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the '[READ]' prefix in the description carries the transparency burden and appropriately signals this is a safe read-only operation. However, beyond labeling it as READ, the description doesn't disclose what 'normalized' means (e.g., how the data is transformed) or whether the output lacks certain raw fields, which would be useful behavioral context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences with zero waste. It front-loads the purpose and READ qualifier, then documents the parameter. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter read tool with no output schema and no annotations. Given the complexity, the description covers the basics: purpose, read-only nature, and parameter semantics. However, without an output schema or annotations, the description could have clarified what the 'normalized' output looks like, since an agent receiving results needs to interpret them without any return-format documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'target' is documented in the description ('Firewall target name from config; omit for the default'), which is clear and adds meaning beyond the bare schema. However, schema description coverage is 0% for the parameter properties, so the description is the only source, and while it explains the parameter well, it doesn't explain possible values or how to discover valid firewall target names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Inbound port-forward (DNAT) rules, normalized' which is a specific verb+resource pair. It clearly identifies the purpose (reading inbound port-forward rules) and the '[READ]' prefix signals this is a read operation. However, it doesn't explicitly distinguish from sibling NAT tools like nat_outbound and nat_one_to_one, which are close alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context by labeling it as inbound DNAT rules, which implies it's for reading port forwards. However, no explicit when-to-use vs when-not-to-use guidance is given, and it doesn't reference the sibling NAT tools (nat_outbound, nat_one_to_one) that might be confused with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The [READ] prefix explicitly signals this is a read-only operation, which is valuable given no annotations are provided. However, beyond the read indication, no behavioral details are disclosed — no mention of refresh behavior, staleness of data, or whether it requires admin privileges. The [READ] tag adds value, but for a tool with zero annotations, the description carries more burden than it fully discharges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise — two short lines for the purpose plus a clear parameter note. The [READ] prefix is a useful front-loading device. No wasted words. Slightly lower than 5 because the Args formatting is a bit terse but functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-param read-only status tool, the description is reasonably complete — it covers the purpose, the [READ] behavior, and the sole parameter. However, with no output schema and no annotations, it doesn't describe the return format or data freshness, leaving some ambiguity. Given the tool's simplicity, this is adequate but not exceptional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the single 'target' parameter ('Firewall target name from config; omit for the default'), which is meaningful context beyond the schema. However, schema description coverage is 0%, so the schema provides no description at all; the description's explanation is the only documentation. Given only one optional param fully explained, a 3 is fair — it does add value but the coverage baseline would suggest more effort is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (read/list) and resource (OpenVPN sessions/connected clients) with parenthetical detail on what's returned (name, address, bytes). It's easily distinguished from siblings like wireguard_status and ipsec_sas which cover other VPN protocols. However, it doesn't explicitly differentiate from those sibling VPN status tools, slightly lowering it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (checking connected OpenVPN clients) but provides no explicit guidance on when to use this vs alternatives. Among siblings, wireguard_status, ipsec_sas, and interface_status exist but no exclusions or comparisons are given. The [READ] prefix does signal it's a safe diagnostic read, but no explicit when-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The [READ] prefix signals a non-destructive read operation, and it clarifies that target can be omitted for the default. However, it doesn't disclose what happens if the uuid is invalid/not found, whether there are permission requirements, or what the returned 'full detail' actually contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the [READ] tag and core purpose in the first line. The Args section is formatted clearly. No wasted words, though the docstring style is slightly more verbose than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only detail lookup tool with 2 parameters and no output schema, the description covers the essentials: what it does, where the identifier comes from, and how to handle the optional target. However, it's missing information about expected return structure and what 'full detail' encompasses, which matters since there's no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains uuid ('Rule uuid (OPNsense) or id (pfSense), from list_rules') quite well, which adds real semantic value beyond the bare 'Uuid' schema label. The target parameter is explained in one line. However, the description doesn't cover edge cases like expected format or constraints on these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'One rule's full detail' by uuid/id, distinguishing it from list_rules and rule_stats siblings. It explicitly identifies it as a read operation with the [READ] prefix. It references list_rules as the source for the identifier, adding useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (get rule details by its uuid/id from list_rules) and explains the target parameter ('omit for the default'). However, it doesn't explicitly compare against siblings like rule_stats or rule_states, nor state when NOT to use this tool. The guidance is adequate but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '[READ]' annotation-like prefix signals a non-destructive operation, and 'busiest first (top-N)' discloses the sort order. With no annotations provided, the description carries the full burden, and it does reasonably convey it's a read operation. However, it doesn't disclose whether this reflects a rolling window, sampled counts, or cumulative totals, nor what happens when the target is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line summary followed by an Arg block. No redundant verbiage. It earns its place but is slightly terse on edge cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a top-N read tool with only 2 optional parameters and no output schema, the description covers the essentials: what it returns, sort order, and parameter semantics. It's adequate for a simple reporting tool. Could be more complete with return-format hints, but the simplicity keeps it at a healthy baseline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description briefly explains both parameters inline: 'top' is how many rules to return (busiest first) and 'target' is the firewall target name with a fallback to default. With 0% schema description coverage this is helpful context, though it could add value-type clarification (e.g., top accepts only positive integers) and does not fully compensate for the caller's uncertainty around target name formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Per-rule hit counts / evaluations, busiest first (top-N)' with a specific verb+resource+scoping. It's distinguishable from siblings like rule_detail and rule_states since it focuses on hit counts/usage frequency. Slight deduction because it doesn't explicitly contrast against these sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies read-only usage ('[READ]' prefix and 'counts'), which helps distinguish from mutation tools like toggle_rule or reconfigure. However, it doesn't explicitly state when to use this tool vs. the closely related rule_states or rule_hit_and_shadow_analysis, and provides no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. The [READ] tag signals non-destructive intent, but the description doesn't state whether this requires privileged access, what happens if the target is invalid, the format of returned data, or any rate/refresh characteristics. A [READ] tag is a bare minimum for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at two sentences, front-loaded with the purpose statement and [READ] indicator. The parameter docstring is minimal and earns its place. Zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description covers the essential purpose and parameter semantics. However, given the read nature and the range of status siblings, it could briefly distinguish itself (e.g., noting it complements openvpn_sessions or that it shows handshake latency). The return format for the listed fields (connected state, last handshake, transfer) is unspecified, but many status tools rely on conventional return shapes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The description explains 'target' as the Firewall target name from config, which goes beyond the schema's bare type declaration. It also clarifies the null/omit behavior ('omit for the default'). This adds meaningful semantics for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists WireGuard peers with connected state, last handshake, and transfer data. The [READ] prefix indicates a read operation. It's distinguishable from siblings like interface_status and openvpn_sessions since it specifically targets WireGuard peers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the target parameter can be omitted for default, implying usage context. However, it doesn't explicitly state when to use this over other status tools (openvpn_sessions, ipsec_sas, interface_status) or provide exclusions/alternatives. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The [READ] prefix signals non-mutating behavior, which is helpful. However, it doesn't disclose pagination behavior, whether the list is limited, ordering, or any potential pitfalls. For a read operation this is acceptable but leaves some gaps about output semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Exceptionally concise: two lines of description plus a one-line arg doc. Every sentence earns its place—purpose, scope, and parameter semantics are covered with zero waste. The [READ] tag front-loads the safety profile.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a straightforward list operation with 1 optional parameter and no output schema, the description is adequate. It covers what is returned (name, type, description, member count) and parameter usage. It lacks differentiation from 'alias_entries' but is otherwise complete for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (the schema provides only a 'Target' field name with no description), so the description must compensate. It explains that 'target' is a firewall target name from config and that omitting it uses the default. This adds genuine meaning beyond the bare schema field title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'All firewall aliases' with specific attributes (name, type, description, member count), using a specific verb+resource structure. It distinguishes from the adjacent 'alias_entries' sibling by focusing on the alias list view rather than individual entries. However, it doesn't explicitly differentiate from siblings beyond scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the target parameter context ('Firewall target name from config; omit for the default'), giving some implicit guidance on when to pass versus omit. It doesn't explicitly state when to use this tool versus the sibling 'alias_entries' tool, but the [READ] prefix and scoped output imply a list-context usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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. The [READ] prefix explicitly disclaims mutation behavior, which is useful. However, it doesn't disclose the return format, whether mappings are sorted/filtered, pagination, or what 'normalized' means concretely. For a read tool, the [READ] prefix provides the core safety disclosure, earning a baseline score, but richer behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact: one sentence declaring the purpose plus a short Args section. Every line earns its place, with the [READ] prefix and parameter guidance included. There is zero filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description covers the core essentials: purpose, safety prefix, and parameter usage. No output schema exists, so return values aren't documented, and 'normalized' output format isn't explained. Given the tool's low complexity, this is adequate but leaves the output format ambiguity unresolved. The '[READ]' prefix plus normalized indicator gives reasonable baseline completeness for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single 'target' parameter. It does explain 'Firewall target name from config; omit for the default,' which adds meaning beyond the bare schema (anyOf string/null with default null). However, it doesn't clarify what the default target refers to, where config names come from, or how to list available targets. One parameter means the description should fully document it; it partially does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with [READ] clearly marking the operation type and states '1:1 NAT mappings (external ↔ internal), normalized.' This makes the purpose clear with a specific verb plus resource (NAT mappings). It distinguishes from siblings by specifying the 1:1 variant, which contrasts with nat_port_forwards and nat_outbound. However, it doesn't explicitly explain how 1:1 differs from the other NAT sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for reading 1:1 NAT mappings, and the sibling names (nat_port_forwards, nat_outbound) suggest categorization by NAT type, but the description doesn't explicitly state when to use this vs. the alternatives. There is minimal guidance on the 'target' parameter usage ('from config; omit for the default'). No explicit exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. The [READ] prefix signals it's a read operation, which helps, and it lists the exact fields returned (IP, MAC, hostname, state). However, it doesn't disclose whether the firewall is authoritative, pagination behavior, or what 'online' means precisely. For a read tool the [READ] prefix provides baseline transparency, but the burden isn't fully met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise — two sentences plus an args section. Every word earns its place. The [READ] prefix, field list, and param explanations are all high-value. Zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read tool with 2 optional params, no output schema, and no nested objects. The description covers purpose, returned fields, and both params adequately for a straightforward lease-listing tool. It could note the relationship to dhcp_static_mappings for completeness, but the core usage is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. Both params are explained: online_only filters to online leases, and target names the firewall from config with a default fallback. This provides meaning beyond the bare schema types (boolean, string/null). Well done for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists active DHCP leases with IP, MAC, hostname, and state. The [READ] prefix and verb 'Active DHCP leases' make the purpose clear. It distinguishes from dhcp_static_mappings (which is about static configs) and other read tools, though it doesn't explicitly name the sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting active DHCP leases but doesn't explicitly state when to use this vs alternatives like dhcp_static_mappings. The 'online_only' filter and 'target' parameter suggest usage context (firewall-specific queries), but there's no explicit exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The '[READ]' prefix signals non-mutating behavior, and 'with state' indicates what data is returned. However, it doesn't disclose whether this requires authentication, whether traffic-triggered state is shown, or what 'state' specifically means (active, expired, etc.). The description adds some value but leaves behavioral details unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact - two short sections with a one-line summary, a one-line args note. No wasted words. It's front-loaded with the READ intent. Slightly more detail on return content could be added but the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only status tool with a single optional parameter and no output schema, the description is reasonably complete. It names the resource (IPsec SAs), the phases (1/2), the data type (state), and the parameter. However, given the large sibling set with similar status tools (gateway_status, interface_status, states_table), more clarity on what distinguishes this output (e.g., tunnel-specific SA details vs general gateway health) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description explains the single 'target' parameter ('Firewall target name from config; omit for the default'), which adds meaning beyond the raw schema that merely shows a nullable string with a null default. For a single simple optional parameter, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool reads IPsec security associations (phase-1/phase-2) with state. The verb 'READ' plus the resource 'IPsec security associations' is specific, and it distinguishes from siblings which cover health, gateway, interface, and other network constructs. However, it doesn't explicitly contrast with sibling tools like gateway_status or states_table, so it doesn't get 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The '[READ]' prefix and 'with state' phrasing imply this is a read-only status/introspection tool for IPsec tunnels. The target parameter guidance ('Firewall target name from config; omit for the default') provides clear usage context. However, it doesn't explicitly state when NOT to use it versus alternatives like gateway_status or states_table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does well. It clearly signals read-only via the '[READ]' prefix, discloses pagination/truncation semantics ('truncated' is true when the state table holds more entries than returned), and documents the return envelope structure with field names and types. This transparency about truncation is genuinely useful for an agent handling large tables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the '[READ]' signal immediately, then a one-line purpose. Parameter docs and return format are kept brief. No wasted sentences or redundant prose. Slightly verbose in the envelope detail but each element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with only 2 optional params and no output schema, the description covers the essential contract: what it reads, the two parameters, and the return envelope including the critical truncation flag. No annotations exist to lean on, so the description does the heavy lifting and covers the practical gaps (pagination behavior, default target). This is complete for the tool's complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and both 'top' (how many state entries to return, default 100) and 'target' (firewall target name from config; omit for the default) are explained in the description. This adds real value beyond the bare schema. However, the guidance is serviceable but not deeply detailed—e.g., it doesn't clarify the valid range or behavior of 'top' at extremes, though defaults and nullability are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this reads 'Active pf state-table entries (connections currently tracked)', identifying the verb (read) and the resource (pf state-table entries). It distinguishes itself from siblings like kill_states (destructive), rule_states (rule-specific), and firewall_log (logs), though it doesn't explicitly name alternatives. Clear and specific enough to stand apart from the majority of sibling read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a read-only query tool for current connection tracking, and there's an explicit note about returning truncated results when the table exceeds the limit. However, it doesn't explicitly state when to use this vs alternatives like top_talkers or firewall_log, nor does it note conditions like 'use this for real-time connection visibility'. No explicit when-not-to-use guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the high risk via [risk=high], mentions the lockout guard, override behavior, and that reloading filter is equivalent to apply_changes. This is meaningful behavioral disclosure given zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with a clear headline, followed by relevant context and a concise Args section. The comparison to apply_changes earns its place. Minor inefficiency: the [WRITE][risk=high] prefix partially duplicates the content in the body and Args.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no output schema and no annotations, the description covers the key behavioral aspects: subsystems, dry-run preview, override, target, and risk. It could add reversibility or permission requirements, but given complexity and absence of annotations, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description documents all 4 parameters (subsystem, dry_run, override, target) in the Args block with brief explanations. This adds substantial meaning beyond the raw schema, though explanations are terse — e.g., 'override' and 'target' could use more detail on format and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Reload/commit a subsystem's config') and names the subsystems (filter/nat/aliases). It distinguishes from siblings like apply_changes by explicitly comparing reloading filter to that tool. However, it's not fully differentiated from all sibling tools (pending_changes, undo_apply) and the initial [WRITE][risk=high] prefix is somewhat generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use it vs apply_changes for the filter subsystem, and mentions the lockout guard and override. It explains that dry_run allows preview without reconfigure. However, it doesn't explicitly state when NOT to use this tool or name alternative tools (beyond apply_changes) for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly declares [READ] semantics at the start, describes the output envelope in detail including the 'truncated' flag which discloses the pagination/limitation behavior, and explains what 'truncated: true' means. This is strong transparency for a read-only aggregation tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose (first sentence), followed by a clearly separated Args section and a Returns section. The envelope specification is efficient — it lists field names rather than describing each verbosely. Minor inefficiency: the '1' in the example envelope and explanation of 'truncated' is slightly redundant given the envelope already shows the field names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only aggregation tool with a well-specified output envelope, the description covers the key elements: what is returned, the truncation behavior, and parameter semantics. The output envelope doubles as a de facto output schema since no formal output schema exists. The main gap is not explaining what the 'target' parameter refers to more concretely or what happens when no target is specified versus specifying the default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain 'top' (how many talkers to return, default 20) and 'target' (firewall target name from config, omit for default). However, the description's parameter info largely restates what the schema already encodes (default values), adding only marginal context like 'from config' for target. It covers both params but adds little beyond the schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Busiest source hosts, aggregated from the state table by bytes.' The [READ] prefix signals this is a read operation and distinguishes it from write tools like undo_apply, reconfigure, toggle_rule, and kill_states. It's specific about the aggregation metric (bytes) and source (state table), clearly separating it from sibling tools like states_table and rule_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by naming the data source ('state table') and how it aggregates (by bytes), which suggests when it's appropriate to call. However, it does not name alternative tools or give explicit when-to-use/when-not-to-use guidance compared to siblings like rule_stats or states_table, which could serve similar reporting functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are none, so the description carries the full burden. It discloses that this is a READ operation via the '[READ]' prefix, that it pulls live status data when a target is given, and that it can skip the live pull via the 'gateways' arg. It also reveals the return structure and that ranking includes numbers ('not a black-box verdict'), giving good behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear opening line, an intro paragraph, and a structured Args section with defaults. The only slight waste is the redundant '[READ]' tag alongside the intro paragraph re-stating it pulls status. Overall tight and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description handles the core needs well: it states the read-only nature, explains inputs, describes the full return dict shape, and gives default thresholds. Minor gaps remain (conflict handling between gateways and target, exact criteria for 'degraded'), but it is reasonably complete for an RCA tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain each parameter (loss_pct and latency_ms thresholds with defaults, gateways as injected rows that skip live pull, target as firewall name from config). However, the gateways parameter is described but its exact schema relationship is thin, and there's no note about what happens if both gateways and target are provided together. Compensates partially but not fully given zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and clear: 'Rank gateways by loss + latency, map each down/degraded one to cause + action.' It identifies the resource (gateways), the verb (rank/map), and the exact output structure. Despite siblings like gateway_status and health_status, it clearly distinguishes itself as the analytics/RCA tool that produces rankings with causes and actions, not just raw status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it ('The flagship WAN RCA'), notes it 'pulls gateway status' and flags down/degraded gateways, and explains the two modes: pass 'gateways' for pure analysis or a target for live pull. It doesn't explicitly name sibling alternatives to exclude, but the use cases are clearly framed around RCA/ranking vs. the simpler status tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the medium-risk write nature, the undo implications, and the critical failure mode (killing its own connection). However, it does not describe what specific side effects a restart has on active connections/sessions, firewall state, or whether it takes the service down before bringing it up. Decent but not fully transparent for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with the action and risk tag. The refusal note and dry_run note are valuable and concise. The Args block is somewhat redundant with the schema but serves as helpful inline documentation. Every sentence adds value, though it could be tightened slightly without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this provides good coverage: action, risk, examples, refusal cases, dry_run, and target semantics. The main gap is not documenting the return/confirmation behavior after a successful restart, but the description is notably complete for a tool of this complexity. The undo-related caveat shows deep contextual awareness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for all 3 params. It explains service (name to restart, with examples), dry_run (preview), and target (firewall target, omit for default). All three are covered at a functional level. However, for service it doesn't enumerate valid values or where to find them, and 'target' semantics (what 'default' refers to) are vague. Adequate but could be richer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear [WRITE][risk=medium] tag and 'Restart a firewall service' with concrete examples (unbound, dhcpd, openvpn). This clearly distinguishes it from sibling read-only tools like interface_status or gateway_status, and from reboot/reconfigure. The verb+resource+examples are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when NOT to use it (never on the management API service like nginx/configd because it kills the tool's own connection and undo cannot run), directs to console for those, and documents the dry_run preview option. Also notes 'target' is optional for default. This is exemplary when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are None, so the description carries the burden. It discloses the write risk tier '[WRITE][risk=medium]', explains the inverse runs through its own governed tool with its own audit/labelling, and states the single-use constraint. However, it doesn't detail what happens on failure, return payload shape, or whether state changes are immediately visible. The 'governed tool' comment adds context beyond annotations but could go further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient and well-structured: a one-sentence purpose line, compact behavioral facts (audited, single-use, dry-run), a risk marker, then a brief Args section mapping to each parameter. Every sentence earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write/dispatch tool with 3 params (1 required), no output schema, and no annotations, the description covers the key aspects: purpose, risk tier, dry-run preview, single-use constraint, and parameter provenance. Slightly incomplete on failure behavior and what the inverse call's success/failure looks like, but reasonably complete for guiding a competent agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains undo_id as coming from undo_list or an _undo_id in a write result, dry_run as preview-without-executing, and target as pass-through. This adds meaningful semantics beyond the bare schema, though target's condition ('when it accepts a target') is somewhat vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states what it does: 'Apply a recorded undo by dispatching its inverse tool.' The verb 'Apply' + resource 'recorded undo' is specific. Distinguishes from siblings by the mechanism (dispatching inverse tool) and the write-context trait ('[WRITE]').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: dry_run=True to preview, token can only be applied once, and target pass-through semantics. Doesn't explicitly name alternatives or when-not-to-use, but the 'token can only be applied once' and dry_run guidance give practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the write nature with [WRITE], assigns risk=medium, states reversibility, and reveals that it captures prior entries before changing — important context for audit/undo behavior. This is substantial behavioral disclosure beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient — a bolded one-line summary followed by Args in standard docstring format. The [WRITE] prefix and risk marker are purposeful. Some redundancy (dry_run repeated in summary and Args) is minor. Overall front-loaded and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no annotations and no output schema, the description discloses the key safety-relevant behaviors: reversibility, prior-state capture, dry-run preview, and default target behavior. It's complete for an agent to invoke correctly, though it could note the return/confirmation format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate fully. It documents all four parameters: name (from list_aliases), entry (host/network/port to add), dry_run (preview behavior), and target (firewall target from config, omit for default). This provides meaningful context well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '[WRITE][risk=medium] Add one entry to an alias' — a specific verb+resource pair that clearly states the action. It explicitly mentions reversibility (undo removes it), which differentiates it from siblings like remove_alias_entry and establishes its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use it (adding an entry to an alias) and recommends dry_run=True for preview. It references a sibling function list_aliases for getting valid names (name: Alias name from list_aliases). It doesn't explicitly say when NOT to use it vs remove_alias_entry, but the reversibility note helps with choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and largely meets it. It discloses that the action is IRREVERSIBLE, has no undo, and is audit-only, plus the write/risk profile via the [WRITE][risk=high] prefix. It also flags dry_run as a preview mechanism. It does not detail post-reboot behavior (downtime, reconnection) but the irreversible warning covers the most critical behavioral risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely tight and front-loaded — the first line delivers purpose and risk in a single sentence, with the critical IRREVERSIBLE warning placed for maximum impact. The dry_run tip and two-line Args block are minimal and each sentence earns its place. No wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description is quite complete: it covers purpose, risk, usage, and both parameters. The main gap is that for a high-risk irreversible action, it could mention expected consequences post-reboot or any confirmation/guardrails, but the audit-only and irreversibility warnings substantially cover the completeness need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does for both parameters. It explains dry_run (preview without rebooting) and target (firewall target from config, optional, defaults). Both parameters are documented in the Args block, though only at a surface level without concrete value formats or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb (Reboot) targeting a specific resource (the firewall), and explicitly flags it as IRREVERSIBLE and audit-only. The [WRITE][risk=high] prefix further clarifies the action type, distinguishing it from the many read-only sibling tools like health_status, interface_status, and firmware_status that share the same resource domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly signals when to use it ('Reboot the firewall', 'audit only'), and the [WRITE][risk=high] tag combined with sibling names makes the read-vs-write distinction clear. It notes previewing via dry_run=True, though it does not explicitly enumerate which sibling alternatives exist or state when NOT to reboot beyond 'audit only', leaving some implicit inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses risk level (medium), that the operation is a WRITE, that it captures prior entries before the change, that it's reversible via undo, and that dry_run previews without changing. This is exceptionally transparent for an unannotated mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded with the key purpose and risk in the first line, then supplements with args. The Args block follows standard docstring conventions. Minor redundancy: '[WRITE]' tag and 'risk=medium' are embedded in brackets, and the reversible note is useful but the description is still lean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no annotations and no output schema, the description covers safety (dry-run, reversible, risk level), all parameter sources, and the undo behavior. It's missing explicit return-value or failure-condition information, but for a straightforward single-entry removal that's acceptable. The dry_run flag is a valuable omission-guard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all 4 parameters. It documents name (source from list_aliases), entry (what to remove), dry_run (preview behavior), and target (source and default). The entry semantics are somewhat underspecified ('host/network/port' is a hint but not a format spec), preventing a 5, but it covers all parameters meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Remove one entry from an alias') and distinguishes from its sibling add_alias_entry by being clearly the inverse operation. The '[WRITE][risk=medium]' prefix further clarifies intent. This disambiguates from the many read-only sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it tells the user to pass dry_run=True to preview, explains that entries come from list_aliases (via the 'name' parameter doc), and notes target is optional with a default. It doesn't explicitly state when NOT to use it versus add_alias_entry, but the opposite-operation relationship is implied by the reverse of the sibling tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/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. It discloses the read-only nature with the '[READ]' prefix, explains the analysis semantics (top-down, pf-exact evaluation), and states every finding names the offending/covering rule uuid. It could add more on edge cases or error behavior, but the disclosure is solid for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief summary line, a clarification paragraph, and an Args section. It's front-loaded with the most important purpose first. Slightly verbose in the analysis paragraph but every sentence contributes meaningful details about the evaluation semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description helpfully documents the return dict shape ({rulesEvaluated, unusedCount, shadowedCount, redundantCount, unusedRules, shadowedRules, redundantRules, note}). With 3 optional parameters and no annotations, it covers the invocation modes, semantics, and return format well. Minor gaps: no mention of what happens with conflicting inputs or empty rule lists, but the overall completeness is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all three parameters. It does: 'rules' is described as injected rows with an explicit field list, 'interface' as an optional filter when pulling live, and 'target' as the firewall name with omit-for-default behavior. This adds meaningful semantic context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb + resource ('Flag never-hit enabled rules and shadowed/redundant rules') and clearly explains what the tool detects: dead/misordered rules, shadowed rules, and redundant rules. It distinguishes well from sibling tools by describing the specific rule-analysis behavior versus status/list tools, and explains the top-down evaluation semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the operational context: rules are compared 'in list order, top-down, exactly as pf evaluates them,' and gives clear guidance that one can pass 'rules' for pure analysis or 'a target to pull live.' It explains the optional interface filter and default target behavior. This provides strong when-to-use and how-to-invoke guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/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. It clearly discloses the [READ] nature (safe read), the two operational modes (injected rows vs live pull), and the transformation pipeline (keeps blocked entries, aggregates, ranks, classifies). It also documents the return dict structure precisely. Missing explicit notes on authorization/permission requirements, but for a read-only analytics tool the disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured and front-loaded with the headline purpose. It is appropriately sized for a 4-parameter tool with 0% schema coverage — the space is needed to document the parameters inline. The Args block is clean and each line earns its place. Slightly verbose but justified given the zero-coverage schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, no output schema, and 0% schema coverage, the description is thorough: it explains the pipeline, modes, and full return shape. It lacks explicit mention of error cases or performance caveats for large log pulls, but the note field in the return dict suggests graceful handling. The degree of completeness is strong for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully, and it does. 'top' is explained as 'how many source rows to return, noisiest first', 'limit' as 'how many recent log rows to pull when live', 'log_entries' with its injected shape {action, source, destination, destinationPort, protocol}, and 'target' as 'firewall target name from config'. Every parameter gets meaningful semantic context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description has a clear specific verb+resource ('Rank the noisiest blocked sources and classify cause + action'). It clearly distinguishes itself from siblings like 'top_talkers' (who talk) and 'firewall_log' (raw logs) by specifying it only keeps blocked entries, aggregates by source, ranks, and classifies. The scope is explicit and differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Pass log_entries for pure analysis, or a target to pull live.' It also explains parameter roles (top, limit, target, log_entries) and their default behavior, plus the two operational modes (analysis vs live pull). This is clear enough to avoid confusion with sibling analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses the envelope return format, defines each field (entries, returned, limit, truncated), and critically explains the 'truncated' flag behavior — telling the agent to re-run with a higher limit rather than trusting the result as complete. This is valuable behavioral context beyond what any annotation would provide, since no annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured with a one-line summary followed by a compact Args list and a Returns block. Every sentence earns its place — the truncation warning is the only additional prose, and it's essential. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filtered-list read tool with 3 optional parameters and no output schema, the description comprehensively covers purpose, all parameters, return envelope structure, and the truncation edge-case behavior. The return format is explicitly documented even without an output schema, making this complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: action (pass/block/reject/rdr/nat filter with optional semantics), limit (max entries, default 200), and target (firewall target name, omit for default). The description adds meaning beyond the bare schema names, though the parameter list in the description doesn't explicitly map to the schema names it covers all three.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool reads recent firewall-log entries with an optional filter for pass/block. The '[READ]' prefix signals it's a read operation, and the resource (firewall log) is specific and distinct from the many sibling tools like rule_stats or states_table that query other firewall data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the optional action filter and target parameter, and signals the tool is for reading log entries (vs. altering them). It doesn't explicitly name sibling alternatives or when-not-to-use cases, but the '[READ]' prefix plus clear filter semantics provides adequate usage context for a log-reading tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/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. It discloses that the operation is reversible, that it performs a read-before-write to record an undo, that it is staged (not immediately live), and that dry_run is available for preview. It declares medium risk. This is strong behavioral disclosure for a write tool with zero annotation support. It doesn't detail auth requirements, but for a firewall rule toggle these are adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured with a one-line summary up front, followed by clearly labeled Args. Every sentence carries information: reversibility, undo behavior, staging, dry_run support, and parameter meanings. No wasted words or redundant restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters at 0% schema coverage, no annotations, and no output schema, the description does substantial work. It covers all parameters, the undo/staging workflow, and platform differences. It doesn't describe return values or error cases, but with no output schema and a reversible toggle operation, this is a minor gap rather than critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It explains uuid (rule uuid for OPNsense, id for pfSense, sourced from list_rules), enable semantics (true=enable, false=disable), dry_run behavior (preview without changing), and target (firewall name from config, default when omitted). All four parameters are given meaning beyond bare names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Enable/disable a filter rule; reversible' with a specific verb+resource (toggle/enable-disable + filter rule). The [WRITE] tag and risk level distinguish it functionally from the many read-only sibling tools like list_rules, rule_detail, rule_stats. The stated behavior of being reversible distinguishes it from destructive write tools like kill_states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains the workflow: reads the rule first for undo recording, is staged only requiring apply_changes to go live, and dry_run=True for preview. It also explains target (firewall name from config, omit for default) and uuid semantics differ per platform (OPNsense vs pfSense). This gives clear when/how guidance including the apply_changes dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully shoulders the transparency burden. It discloses the exact return shape, the measured (not guessed) truncation behavior, the semantics of 'effectVerified' and its implications for probable vs confirmed state, and the fact that 'target' is unused. This is thorough behavioral disclosure beyond what structured data could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized for the tool's complexity. It front-loads the purpose, then gives return format, behavioral nuances, and parameter documentation. Every sentence adds value without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description provides a complete picture: return object shape, pagination semantics, effectVerified caveats, and full parameter descriptions. It leaves no significant gaps for the agent to make correct decisions about selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does so completely: 'limit' is described as max rows with default and cap, and 'target' is explicitly stated as unused/accepted for CLI uniformity. This compensates entirely for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource: '[READ] List recorded, not-yet-applied undo tokens (most recent first).' It distinguishes this from the sibling 'undo_apply' by explicitly noting these are tokens to be used with undo_apply, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance: 'Use the undoId with undo_apply' and advises re-running with a higher limit when truncated. It clearly establishes the context for listing pending undo tokens, though it does not explicitly state when not to use this tool versus alternatives; the context is strong enough to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers richly. The [WRITE][risk=medium] tag signals mutation and risk level. It clearly documents the side effect (drops tracked connections), the self-inflicted consequence (own connection state flushed causing apparent failure), and reassures that access is not lost. This is a model of behavioral disclosure for a destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a clear [WRITE][risk=medium] tag and one-line purpose. The warning paragraph is tight and fills a critical gap. Args are listed compactly with useful semantics. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, self-impacting operation with 0% schema coverage, no annotations, and no output schema, the description covers the purpose, the danger, the error-signature behavior, the access-safety reassurance, and all parameters. The dry_run escape hatch is mentioned. There is little an agent could be left unsure about for selecting and invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all three parameters: filter_ip (optional source IP scope, blank = all states), dry_run (preview without flushing), and target (firewall target from config, omit for default). This fully compensates for the empty schema coverage, adding type/format and default semantics for each.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Flush pf state-table entries.' The tool distinctly operates on firewall state table entries, which is clearly differentiated from siblings like states_table (which presumably lists states), rule_states, and toggle_rule. The optional filter_ip scoping is also stated upfront.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns about when NOT to use it: dropping tracked connections means this tool's own connection state is flushed, so the call may appear to fail — a lost response, not a lockout, and a blind retry is the wrong reaction. It positions dry_run=True for preview and notes the permitting rule is untouched. This is exceptional guidance that addresses the risk scenario directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and fully delivers. It discloses the read-only nature ('[READ]'), the certain vs uncertain flag distinction (certain blocks apply_changes, uncertain only warns), and the fallback behavior when no risky rule exists. It also exposes the internal limitation (no per-rule dirty flag over REST).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight paragraphs, each earning its place: purpose/behavior, the certain-vs-uncertain distinction, and the single parameter. Front-loaded with the core READ purpose and usage directive. Zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a moderately complex tool (lockout risk semantics, certain/uncertain flags, aliases/interface-group edge cases), the description covers purpose, output semantics, limitations, and parameters. No output schema exists, so describing the certain flag and finding ordering ('ranked worst-first') compensates fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the single 'target' parameter, which it does: 'Firewall target name from config; omit for the default.' This explains the parameter's purpose and default behavior, going meaningfully beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb+resource ('reports whether committing the staged rules would cut the endpoint'), and clearly distinguishes this from siblings like list_rules, rule_detail, and apply_changes. The '[READ]' prefix plus the explicit relationship to apply_changes leaves zero ambiguity about purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Run this BEFORE apply_changes' and explains what it does (reports lockout risk). It also distinguishes its behavior from a diff against running config, stating why — neither platform exposes a per-rule dirty flag over REST. This is explicit when-to-use guidance with rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels. It discloses the write/high-risk nature, the refusal behavior on provable lockout, the warn-and-proceed for uncertain cases, and the dry_run return behavior. This is exceptionally transparent for a destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but well-structured with a clear header, context, safety explanation, dry_run guidance, and parameter breakdown. Every sentence earns its place; there is no fluff, and the risk tag is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk write tool with no annotations and no output schema, the description is complete: it covers when to use, what it does, safety behavior, dry_run semantics, and parameter meaning. The agent has everything needed to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section explains each parameter beyond the schema: dry_run returns the full staged change set + assessment, override proceeds despite lockout findings, and target selects the firewall target. The schema has 0% coverage, so this description is essential and fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'commits staged firewall config' and 'makes edits live,' which is a specific verb+resource pair. It distinguishes itself from siblings by positioning this as the 'make it live' step after staged edits like toggle_rule, and differentiates from undo_apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames when to use: 'the "make it live" step after staged edits (e.g. toggle_rule)' and advises using dry_run before every apply. It also warns that override is only for operators with console/out-of-band access, giving clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AIops-tools/Firewall-AIops'
If you have feedback or need assistance with the MCP directory API, please join our Discord server