Skip to main content
Glama
vmware-skills

vmware-nsx-security

by vmware-skills
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

list_dfw_policies

Read-onlyIdempotent

Retrieve distributed firewall security policies in the default domain, showing IDs, categories, sequence numbers, and rule counts. Use it to find the policy to inspect before viewing its details or rules.

Instructions

[READ] List DFW security policies in the default domain.

Start here. Returns the list envelope: 'items' holds each policy's id, display_name, category, sequence_number, stateful flag and rule count; 'returned'/'limit'/'total'/'truncated'/'hint' say whether the page is the whole answer — never read a full page as complete, narrow with name_filter or page with offset. Then get_dfw_policy for one policy's detail, or list_dfw_rules for the rules inside.

Page with 'next_offset': pass the value back as 'offset' and stop when it is null. Do not loop on 'truncated' — that says this page is not the whole collection, which stays true on the last page of a walk.

'rule_count' is null when NSX did not report one — that means "not retrieved", NOT "no rules", so do not conclude a null policy enforces nothing; call list_dfw_rules on it. Passing name_filter makes every count null (it is resolved via the Policy Search API, which carries no rule counts). A null anywhere adds 'rule_count_note' to the envelope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoPage size, 1..1000 (default 50). Not a way to ask for everything — 0 or negative is rejected.
offsetNoMatched policies to skip, 0 or more. Pass the previous response's 'next_offset'.
targetNoNSX Manager target name from config; default if omitted.
name_filterNoSubstring/glob match on policy display_name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.10.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit / description
      Added value: +"Page size, 1..1000 (default 50). Not a way to ask for everything — 0 or negative is rejected."
    • addedInput schema / properties / name_filter / description
      Added value: +"Substring/glob match on policy display_name."
    • addedInput schema / properties / offset / description
      Added value: +"Matched policies to skip, 0 or more. Pass the previous response's 'next_offset'."
    • addedInput schema / properties / target / description
      Added value: +"NSX Manager target name from config; default if omitted."
  2. Changed1 schema field changedv1.8.9
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "title": "Result",
-      "type": "array"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "list_dfw_policiesOutput",
-  "type": "object"
-}New value: +null
  3. Changed3 schema fields changedv1.5.38
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 50,
+  "title": "Limit",
+  "type": "integer"
+}
    • addedInput schema / properties / name_filter
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Name Filter"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
  4. Addedv1.5.29
  5. Removedv1.5.28
  6. First observedv1.3.2

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses the envelope structure, the meaning of truncated, the null rule_count caveat, and the side effects of name_filter. It also warns against misinterpreting null rule_count as 'no rules,' which is critical behavioral context an agent would otherwise lack.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: entry-point advice, return envelope semantics, pagination rules, and null-value pitfalls. The most important orientation is front-loaded in the first sentence, and the later paragraphs add essential nuance without fluff.

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

Completeness5/5

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

With no output schema present, the description sufficiently explains the return envelope, pagination contract, and null rule_count behavior. It also handles the open-world concern by explicitly warning not to treat a truncated page as the complete answer. For a read-only list tool with four self-documenting parameters, nothing required for correct invocation is missing.

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

Parameters4/5

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

The input schema already provides 100% description coverage for parameters. The tool description adds meaningful operational detail: offset should carry next_offset, limit rejects invalid values, and name_filter makes counts null through the Policy Search API. This is a solid addition above the schema baseline, though the schema already carries the basic parameter meanings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List'), a concrete resource ('DFW security policies'), and a scope ('default domain'). It also positions itself as the starting point and names get_dfw_policy and list_dfw_rules as follow-up tools, making it distinguishable from siblings.

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

Usage Guidelines5/5

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

It explicitly says 'Start here,' then directs the agent to get_dfw_policy for detail and list_dfw_rules for rules. It also provides precise pagination guidance using next_offset and explains when not to treat a page as complete, which fully covers when and how to use this tool versus alternatives.

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

Install Server

Other Tools