vmware-nsx-security

update_dfw_rule

Partially update an existing NSX distributed firewall rule: change its action, sources, destinations, priority, or disabled state without altering omitted fields.

Instructions

[WRITE] Partially update a DFW rule (PATCH — only provided fields change).

Returns the updated rule dict; omitted arguments keep their values, so read them with list_dfw_rules first. Use it to retarget, re-prioritise or disable a rule — to add one use create_dfw_rule, to remove one delete_dfw_rule.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "policy_id": "<policy_id>",
      "rule_id": "<rule_id>"
    },
    "name": "update_dfw_rule"
  }
}

Input Schema

Name	Required	Description
`action`	No	New firewall action.
`logged`	No	New logged flag.
`target`	No	Optional NSX Manager target from config.
`rule_id`	Yes	Rule identifier to update.
`sources`	No	New source groups.
`disabled`	No	New disabled flag.
`services`	No	New services.
`policy_id`	Yes	Parent policy identifier.
`description`	No	New description.
`destinations`	No	New destination groups.
`display_name`	No	New name.
`sequence_number`	No	New sequence number.

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv1.10.0Sep 3, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- changedInput schema / properties / action / anyOf
```
Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "ALLOW",
+      "DROP",
+      "REJECT",
+      "JUMP_TO_APPLICATION"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- addedInput schema / properties / action / description
```
Added value: +"New firewall action."
```
- addedInput schema / properties / description / description
```
Added value: +"New description."
```
- addedInput schema / properties / destinations / description
```
Added value: +"New destination groups."
```
- addedInput schema / properties / disabled / description
```
Added value: +"New disabled flag."
```
- addedInput schema / properties / display_name / description
```
Added value: +"New name."
```
- addedInput schema / properties / logged / description
```
Added value: +"New logged flag."
```
- addedInput schema / properties / policy_id / description
```
Added value: +"Parent policy identifier."
```
- addedInput schema / properties / rule_id / description
```
Added value: +"Rule identifier to update."
```
- addedInput schema / properties / sequence_number / description
```
Added value: +"New sequence number."
```
- addedInput schema / properties / services / description
```
Added value: +"New services."
```
- addedInput schema / properties / sources / description
```
Added value: +"New source groups."
```
- addedInput schema / properties / target / description
```
Added value: +"Optional NSX Manager target from config."
```
Addedv1.5.29May 29, 2026
Removedv1.5.28May 21, 2026
First observedv1.3.2Mar 27, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already convey readOnlyHint=false and destructiveHint=false. The description adds meaningful context: [WRITE], PATCH semantics, returned updated rule dict, and that omitted arguments keep their values. It does not contradict annotations and gives enough behavioral information beyond them.

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?

Three efficient sentences: one for the PATCH verb and scope, one for the return/value-preservation behavior, one for usage routing. Every sentence earns its place and there is no repetition of schema details.

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?

For a 12-parameter mutating tool with no output schema, it covers the main operational guidance: return type, prerequisite read, and sibling routing. The only notable gap is the unclear behavior of explicitly passing null vs omitting a parameter, which matters for nullable fields in a PATCH.

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%, with each parameter having a short description like 'New firewall action.' The main added semantic is that omitted arguments keep their values, but the description does not clarify the null-vs-omitted distinction for clearing fields. The schema carries most of the parameter meaning.

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?

States a specific verb and resource: 'Partially update a DFW rule (PATCH — only provided fields change)' and distinguishes it from create/delete alternatives. This is unambiguous and can't be confused with list_dfw_rules or update_dfw_policy.

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?

Explicitly says when to use it ('retarget, re-prioritise or disable a rule') and names alternatives ('to add one use create_dfw_rule, to remove one delete_dfw_rule'). Also tells the agent to read current values with list_dfw_rules first, which is essential for a PATCH.

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