Skip to main content
Glama
vmware-skills

vmware-nsx-security

by vmware-skills
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

create_dfw_policy

Create a new empty DFW security policy to serve as a container for firewall rules, with configurable category, priority, and stateful tracking. Rules can then be added separately.

Instructions

[WRITE] Create a new DFW security policy.

Returns the created policy dict (id, path, category, ...), else {"error", "hint"}. The policy is an empty container — rules must be added afterwards with create_dfw_rule.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoOptional NSX Manager target from config.
categoryNoEthernet, Emergency, Infrastructure, Environment or Application (default Application); sets DFW evaluation order, Ethernet first, Application last.Application
statefulNoTrack connection state (default True).
policy_idYesUnique policy id (alphanumerics, hyphens, underscores).
descriptionNoOptional description.
display_nameYesHuman-readable name.
sequence_numberNoPriority; lower = higher priority (default 10).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.10.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / category / description
      Added value: +"Ethernet, Emergency, Infrastructure, Environment or Application (default Application); sets DFW evaluation order, Ethernet first, Application last."
    • addedInput schema / properties / category / enum
      Added value: +[
+  "Ethernet",
+  "Emergency",
+  "Infrastructure",
+  "Environment",
+  "Application"
+]
    • addedInput schema / properties / description / description
      Added value: +"Optional description."
    • addedInput schema / properties / display_name / description
      Added value: +"Human-readable name."
    • addedInput schema / properties / policy_id / description
      Added value: +"Unique policy id (alphanumerics, hyphens, underscores)."
    • addedInput schema / properties / sequence_number / description
      Added value: +"Priority; lower = higher priority (default 10)."
    • addedInput schema / properties / stateful / description
      Added value: +"Track connection state (default True)."
    • addedInput schema / properties / target / description
      Added value: +"Optional NSX Manager target from config."
  2. Addedv1.5.29
  3. Removedv1.5.28
  4. First observedv1.3.2

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already signal this is a write operation (readOnlyHint=false) and not idempotent. The description adds value beyond annotations by stating the return shape ('created policy dict', else error/hint) and the empty-container behavior. No contradiction with annotations. It could mention duplicate-id behavior, but the current disclosure is solid for a creating tool.

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?

Two tightly packed sentences deliver the action, the write marker, the return contract, and the crucial empty-container/rule-sequencing note. No filler or repetition. The most important behavioral caveat is front-loaded.

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

Completeness4/5

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

All 7 parameters are fully covered by the schema, and the description explains the return value and the important empty-container behavior. There is no output schema, so mentioning the return dict fills a real gap. Minor omissions like duplicate-ID handling are not critical given the openWorldHint and idempotentHint annotations.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents every parameter including defaults and enum meanings. The description does not need to add parameter-level detail; its mention of return keys like id, path, and category is incidental. Baseline 3 is appropriate because the description adds no extra parameter semantics beyond the schema.

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 uses a specific verb+resource pair ('Create a new DFW security policy') and clarifies the resource's nature ('empty container'), which distinguishes it from rule-level tools like create_dfw_rule without needing to open schemas. The [WRITE] tag reinforces the action type. This is clear 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 Guidelines4/5

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

The description gives explicit sequencing guidance: the policy starts empty and rules must be added afterwards with create_dfw_rule. This tells an agent how to use the tool in a multi-step workflow. It does not explicitly mention alternatives like update_dfw_policy, but for a create operation the intended use is well implied.

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