Skip to main content
Glama

update_dfw_rule

Modify an existing distributed firewall rule by changing only the specified fields, such as action, sources, destinations, services, priority, or enabled state, while preserving all other settings.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoNew firewall action.
loggedNoNew logged flag.
targetNoOptional NSX Manager target from config.
rule_idYesRule identifier to update.
sourcesNoNew source groups.
disabledNoNew disabled flag.
servicesNoNew services.
policy_idYesParent policy identifier.
descriptionNoNew description.
destinationsNoNew destination groups.
display_nameNoNew name.
sequence_numberNoNew sequence number.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv1.10.0
    • 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."
  2. Addedv1.5.29
  3. Removedv1.5.28
  4. First observedv1.3.2

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.