Skip to main content
Glama
vmware-skills

vmware-nsx-security

by vmware-skills
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

list_groups

Read-onlyIdempotent

List NSX security groups in the default domain, returning each group's ID, name, and description. Use name filters or pagination to navigate large collections without missing data.

Instructions

[READ] List NSX security groups in the default domain.

Returns the list envelope: 'items' holds each group's id, display_name, description and expression 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_group for one group's criteria and effective members.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoPage size, 1..1000 (default 50). Not a way to ask for everything — 0 or negative is rejected.
offsetNoMatched groups to skip, 0 or more. Pass the previous response's 'next_offset'.
targetNoOptional NSX Manager target from config.
name_filterNoSubstring/glob match on group 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 group display_name."
    • addedInput schema / properties / offset / description
      Added value: +"Matched groups to skip, 0 or more. Pass the previous response's 'next_offset'."
    • addedInput schema / properties / target / description
      Added value: +"Optional NSX Manager target from config."
  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_groupsOutput",
-  "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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description reinforces this with '[READ]'. It goes beyond the annotations by fully describing the response envelope fields and the pagination contract, including the critical caveat that 'truncated' is not a loop condition and that a page may not be the whole answer. This is exactly the kind of behavioral context an agent needs in the absence of an output schema.

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: it states the operation, describes the return envelope, gives paging rules, and routes deeper work to get_group. The most important scoping and pagination warnings are front-loaded, and there is no filler or repetition of schema content. The structure is well suited to the tool's complexity.

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?

Despite having no output schema, the description fully covers the return envelope and pagination semantics, which are the non-obvious parts of this tool. It also tells the agent when to redirect to get_group for deeper detail, covering the main follow-up need. For a read-only list tool with fully documented parameters, nothing essential 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?

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds meaningful semantics by explaining how name_filter and offset are intended to be used together, and by explicitly tying offset to the next_offset field from a previous response. It reinforces the schema's parameter descriptions rather than merely repeating them, though the schema already carries most of the parameter burden.

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 opens with a specific verb-resource pair, 'List NSX security groups in the default domain,' making the tool's core purpose unmistakable. It also distinguishes itself from get_group by pointing to that sibling for a single group's criteria and effective members, and from mutation siblings like create_group and delete_group by the explicit '[READ]' marker. An agent can tell this tool apart from its siblings without opening the schema.

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

Usage Guidelines5/5

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

The description provides direct usage guidance: narrow with name_filter, page with offset, and never treat a single page as complete. It explicitly names get_group as the alternative when one group's criteria and effective members are needed. It also warns against looping on 'truncated' and explains the correct next_offset walk, which is actionable and unambiguous.

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