vmware-nsx-security

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.8.9
Disambiguation5/5
Each tool targets a distinct resource and action: DFW policy CRUD, DFW rule CRUD plus stats, group CRUD (minus update), IDPS list/status, VM tag apply/remove/list, and Traceflow run/result. No two tools overlap; the list-then-get pattern is standard and unambiguous.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case convention: list/get/create/update/delete for policies and rules, list/get/create/delete for groups, list/apply/remove for VM tags, and run/get for Traceflow. No camelCase or mixed verb styles.
Tool Count4/5
21 tools is heavier than the ideal 10-15, but the set is logically partitioned into six sub-areas (policies, rules, groups, IDPS, VM tags, Traceflow), and each tool has a clear, non-redundant role. The count is manageable given the breadth of NSX security features covered.
Completeness3/5
DFW policy, rule, VM tag, and Traceflow lifecycles are complete (create/read/update/delete where applicable). However, groups lack an update tool—you can create and delete but not modify membership criteria—and IDPS supports only read operations (list profiles, get status) with no profile or settings management, creating dead ends.
Average 4.9/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 42 commits in the last 12 weeks
- Last stable release on August 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false). The description adds useful context: it returns the created policy dict or an error/hint, and emphasizes that the policy starts as an empty container. This goes beyond annotation basics, yet it omits details like permission requirements or side effects, keeping it at a 4.
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 well-structured: purpose, return value, usage note, then a parameter list. Every sentence is informative and none are redundant. It is concise yet comprehensive, fitting the tool's complexity.
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?
With no output schema, the description covers return values and error format. It also explains the 'empty container' behavior and dependency on create_dfw_rule. Some minor aspects like error scenarios or required permissions are brief, but overall it is sufficiently complete for a 7-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description provides rich semantics for all 7 parameters: policy_id uniqueness constraints, category allowed values, sequence_number priority meaning, stateful default, and target usage. It fully compensates for the sparse 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 clearly states 'Create a new DFW security policy' with a specific verb and resource. This distinguishes it from sibling tools like create_dfw_rule, get_dfw_policy, and update_dfw_policy, making the tool's purpose 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 provides clear workflow context: 'The policy is an empty container — rules must be added afterwards with create_dfw_rule.' It also explains category evaluation order, which helps selection. However, it does not explicitly mention when not to use this tool or alternative scenarios, so it slightly misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the operation is additive ('existing tags survive'), describes the return format (and what it does NOT return), and notes the side effect of tag-based group membership shifts. This adds valuable behavioral context beyond the structured annotations.
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 compact and front-loaded. The first sentence states the core action, followed by return value, usage guidance, and side effects. Every sentence contributes useful information 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?
This tool has 4 parameters (3 required), no output schema, and no enum constraints. The description covers purpose, parameter semantics, return format, workflow (using list_vm_tags and get_group), and side effects. It provides a complete picture for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates fully by explaining each parameter: vm_id ('VM external ID (fabric UUID, from list_vm_tags)'), tag_scope (with examples), tag_value (with examples), and target ('Optional NSX Manager target from config'). This adds meaning far beyond the bare 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 clearly states the tool's function: 'Apply an NSX tag to a virtual machine.' It uses a specific verb ('Apply') and resource ('NSX tag to a virtual machine'), and distinguishes itself from sibling tools like list_vm_tags and remove_vm_tag by focusing on the action of applying a tag.
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 provides explicit usage context: 'Use list_vm_tags first for the vm_id, and again after to see the result.' It also advises checking with get_group for side effects. While it doesn't explicitly state when not to use this tool or name alternatives, the workflow guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as non-read-only and non-destructive. The description adds important behavioral context such as PATCH semantics ('only provided fields change'), the fact that omitted arguments keep their values, and the return of the updated rule dict. It doesn't cover auth or failure modes, but it goes meaningfully beyond the annotations.
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 front-loaded with the essential purpose, then provides compact usage guidance and an organized parameter list. Every sentence earns its place; the Args block is lengthy only because it must compensate for absent schema descriptions, and it is cleanly formatted.
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?
The description covers the full usage flow: read current state first, perform a partial update, and receive the updated rule dict. It names relevant alternatives and explains the optional target. It omits only deeper error/atomicity details, which are not necessary for selecting and invoking the tool correctly.
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?
With schema description coverage at 0%, the description's Args section compensates by explaining all 12 parameters in plain terms, including 'New source groups' and 'Optional NSX Manager target from config'. It could provide more format-level detail, but it clearly adds meaning beyond the bare property names.
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 clearly states 'Partially update a DFW rule (PATCH)' with a specific verb and resource, and the [WRITE] prefix reinforces the action type. It also explicitly distinguishes this from creating or deleting a rule by naming the alternative sibling tools.
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 gives precise when-to-use guidance: 'retarget, re-prioritise or disable a rule'. It explicitly names alternatives for add (create_dfw_rule) and remove (delete_dfw_rule), and advises reading current values with list_dfw_rules first because omitted fields retain their values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by describing the return shape ('Returns one policy object, not an envelope') and listing the included fields (category, sequence_number, stateful, scope, rule count). It also warns against passing a display name, which is a practical behavioral constraint not captured in annotations.
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 well-structured: a leading [READ] tag, purpose sentence, return detail, usage flow, then an Args section. Every sentence contributes necessary information without fluff. It front-loads the key purpose and keeps the overall length tight given the lack of schema descriptions.
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, the description compensates by explaining the return format and key fields. It covers the full usage flow (list to single, then rules), input parameters, and response shape. For a straightforward get-by-id tool with two parameters, this is complete and leaves no major gaps.
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 0%, so the description carries the full burden of parameter meaning. It clearly explains policy_id with an example ('app-tier-policy') and target as 'Optional NSX Manager target from config.' Both parameters are adequately described beyond the bare schema types.
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 begins with '[READ] Get full details of a single DFW security policy,' which clearly states the action (get) and resource (single DFW policy). It distinguishes from siblings by emphasizing 'single' versus list_dfw_policies, and implies read-only versus create/delete/update. The return-format note ('one policy object, not an envelope') further clarifies the tool's specific behavior.
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 instructs when to use: 'Use it once list_dfw_policies has narrowed to one id — never a display name.' This both gives a workflow trigger and a clear exclusion. It also tells the next logical call ('Then call list_dfw_rules for the rules inside'), providing complete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it reveals the return bundle is 'one bundle, not an envelope,' describes the structure of 'signature_status' and 'settings,' and notes that 'signature_status' may be empty where IDS was never enabled. This adds valuable behavioral context not covered by readOnlyHint/idempotentHint.
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 front-loaded with '[READ]' and a clear summary, then uses compact bullet-like sentences to explain return structure, edge cases, and usage. Every sentence adds value with no 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?
Given there is no output schema, the description compensates by explaining the return bundle's two sections, the varying field names by NSX release, and the empty-state edge case. It also provides enough context for an agent to know when to call this versus siblings.
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?
The only parameter 'target' is described as 'Optional NSX Manager target from config,' which adds a small amount of context beyond the bare schema, but lacks details on accepted values or behavior when omitted. Since schema description coverage is 0%, the description carries responsibility, and it does so minimally.
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 clearly states 'Get IDPS signature status and global IDS settings' with a specific verb and resource, and distinguishes from sibling list_idps_profiles by advising 'Use it first to confirm IDS is on and current, then list_idps_profiles for the profiles.'
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 provides when to use this tool: 'Use it first to confirm IDS is on and current' and when not: 'No per-signature or per-event detail.' It also suggests the alternative sibling tool, making usage guidelines very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by detailing the return payload (a specific object with status, vm_id, scope, tag, not remaining tags), the exact-match removal semantics, and the immediate effect on dynamic groups. This enriches the annotation-provided destructiveHint and idempotentHint without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured with a summary, behavioral notes, and an Args list. It front-loads the purpose and keeps each sentence informative. Slightly longer than minimal, but all content is necessary for correct usage.
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?
Given no output schema and zero schema descriptions, the description covers return format, side effects, preconditions (use list_vm_tags), and post-conditions (re-check with get_group). It is complete for a mutation tool with these annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does so clearly: vm_id as the external ID from list_vm_tags, tag_scope and tag_value with examples ('env', 'production'), and target as an optional NSX Manager target. This adds meaning the schema lacks.
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?
Clearly states the action: 'Remove an NSX tag from a virtual machine.' It specifies the resource (VM) and the exact operation (removing a tag), and distinguishes itself from siblings like apply_vm_tag and list_vm_tags by focusing on removal and noting that only the exact scope/value pair is removed.
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?
Provides clear usage context: 'Use list_vm_tags first to confirm the pair' and 're-check with get_group' after removal due to dynamic group membership changes. It does not explicitly mention when not to use it, but the guidance is practical and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explaining PATCH semantics, noting that omitted arguments keep their values, and that it returns the updated policy dict. This adds important context not captured by the readOnlyHint/idempotentHint flags, though it doesn't cover potential side effects like audit logs.
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 well-structured and front-loaded with the core action, followed by behavior and an Args list. Every sentence contributes value, and the format makes it easy to scan.
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 lacking an output schema, the description states the return type and provides sufficient guidance for a partially-updating tool, including the read-first workflow and alternative for rules. Combined with the sibling tools, it is contextually complete.
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?
With 0% schema description coverage, the description compensates by documenting every parameter (policy_id, display_name, description, sequence_number, stateful, target) with a brief but useful explanation, such as 'New display name' and 'Optional NSX Manager target from config.' This adds meaning beyond the raw 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 clearly states 'Partially update a DFW security policy (PATCH — only provided fields change)' with a specific verb and resource, and distinguishes from update_dfw_rule by noting rule-level changes use a different tool.
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 explains when to use it ('rename or re-prioritise the policy itself') and when not to ('to change a rule inside use update_dfw_rule'), and advises reading the policy first with get_dfw_policy to preserve omitted fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the mutation and non-idempotency, and the description adds that it returns the created group dict and explains how criteria combine and which member types match. It does not mention duplicate-handling behavior, but given the annotation coverage, the additional context is solid.
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 well-structured and concise: it front-loads the purpose, adds the critical condition semantics, then lists parameters compactly. Every sentence earns its place, and the Args block is informative without being bloated.
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?
Given the high parameter count, zero schema descriptions, and no output schema, this description is remarkably complete. It covers the return value, parameter meanings, membership matching semantics, and the tool's role in the DFW rule creation workflow, enabling correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides zero parameter descriptions, so the detailed Args list is essential. The description gives types, constraints, examples, and semantic explanations for every parameter, such as group_id format and ip_addresses as IP/CIDR lists, fully compensating for the schema coverage gap.
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 '[WRITE] Create an NSX security group with optional membership criteria,' which clearly states the action and resource. It is immediately distinguishable from sibling tools like list_groups, get_group, and delete_group, as well as from create_dfw_policy and create_dfw_rule.
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 explicitly says 'Use it before create_dfw_rule, which references the group path; confirm members with get_group,' providing direct strategic workflow guidance. It also explains the OR/AND semantics for membership criteria, which is essential for correct use versus other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations (readOnlyHint, idempotentHint, destructiveHint). It discloses the returned operation_state values, typed observations, and special fields for Dropped types. It also explains the server-side lifecycle (completed traceflow is deleted and IDs 404), which is critical for handling errors.
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 appropriately sized: it front-loads the purpose with the [READ] tag and clear first sentence, then adds efficient detail about return values and lifecycle. The Args section is compact but also adds value. No filler, every sentence earns its place.
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, the description compensates by explaining return values: operation_state, observations typed by resource_type, and Dropped* carrying reason/acl_rule_id. It also covers the edge case of 404s for completed traceflows, making the tool fully self-contained for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries full weight. It explains traceflow_id as coming from a previous run_traceflow call, and target as an optional NSX Manager target from config. This adds real semantic meaning beyond the schema's bare string type definitions.
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 "[READ] Get the current state and observations of an existing Traceflow," which uses a specific verb (Get), a clear resource (Traceflow), and scope (existing). It also distinguishes itself from the sibling run_traceflow tool by focusing on checking a previously initiated traceflow rather than starting one.
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?
It explicitly states when to use the tool: "Use this to check a previously initiated traceflow without waiting," providing clear context for post-run_traceflow polling. It also gives the important caveat that completed traceflows are deleted server-side and return 404. No explicit exclusion or alternative is named, but the guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the destructiveHint annotation by detailing refusal conditions (references from DFW rules, gateway firewall, nested groups, service insertion), fail-safe behavior if the check fails, and return format. This gives the agent a clear model of the tool's runtime behavior.
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?
Every sentence earns its place: action, return value, usage trigger, refusal conditions, remediation, and parameter list. Well-structured and free of padding despite its length.
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?
Given the tool's destructive nature and lack of output schema, the description covers prerequisites (get_group check), failure modes (refusals), remediation steps, and return values. This is comprehensive for the tool's complexity.
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 coverage is 0%, so the description compensates by explaining 'group_id: ID of the group to delete' and 'target: Optional NSX Manager target from config.' This adds meaning beyond schema titles, though target semantics could be more detailed.
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 '[WRITE] Delete an NSX security group,' a specific verb and resource. This clearly distinguishes it from sibling tools like get_group, create_group, and update_dfw_rule.
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 states 'Use it once get_group shows the group is unwanted,' and provides alternative actions when refusal names a DFW rule: 'retarget it with update_dfw_rule or drop it with delete_dfw_rule first.' This offers clear when-to-use guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable context beyond annotations: returns a flat object not an envelope, lists the exact fields returned, notes counters are cumulative, and warns that new rules may read zero. No contradiction with annotations.
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?
Concise and well-structured: starts with a [READ] tag and clear purpose, then a compact paragraph of usage and return details, followed by an Args list. Every sentence provides useful information without waste.
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?
For a simple 3-parameter read tool with no output schema, the description is complete. It describes the return format (flat object with field names), explains counter behavior, specifies where IDs come from, and includes parameter semantics. No critical information 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?
With 0% schema description coverage, the description compensates by giving one-line meanings for each parameter: policy_id as parent policy, rule_id as rule identifier, and target as optional NSX Manager target from config. This adds meaning beyond the bare schema titles, though not deeply detailed.
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?
Clearly states it gets packet/byte hit-count statistics for a DFW rule, using a specific verb and resource. Distinguishes itself from sibling tools by explicitly noting it should be used before update_dfw_rule or delete_dfw_rule and that IDs come from list_dfw_rules.
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?
Provides explicit usage context: 'Use it before update_dfw_rule or delete_dfw_rule to see if a rule still matches traffic' and explains counter semantics (cumulative, may read zero on new rule). This gives clear when-to-use guidance despite not enumerating exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the minimal annotations by disclosing PUT semantics (overwriting on reused rule_id), immediate enforcement unless disabled, return format (rule dict or error/hint), and error behavior for invalid values. No contradiction with annotations.
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?
Long but appropriately sized for 15 parameters; front-loads core behavior and return semantics before structured Args. Every sentence adds value, and the Args block is cleanly formatted.
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?
No output schema and sparse annotations would normally leave gaps, but the description fully covers prerequisites, side effects, error formats, parameter details, and sibling relationships. It is self-contained for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden and succeeds: every parameter is explained with defaults, examples, and special conditions (e.g., source group path format, omit-for-any semantics).
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?
Opens with 'Create a firewall rule under an existing DFW security policy' – a specific verb, resource, and parent context. Clearly distinguishes from siblings like create_dfw_policy, update_dfw_rule, and delete_dfw_rule.
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 states 'Pick policy_id with list_dfw_policies first' and directs users to update_dfw_rule for edits and delete_dfw_rule for removal. Also provides condition for JUMP_TO_APPLICATION requiring an Environment policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description discloses the exact return payloads, the refusal condition, and the cleanup workflow. This adds valuable operational context not present in the annotations.
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 compact and front-loaded with the operation type and action. Every sentence adds value—return values, refusal behavior, and argument explanations—without unnecessary filler.
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 covers the return format, error shape, and a non-obvious prerequisite (active rules block deletion). This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining each parameter: 'policy_id: ID of the policy to delete' and 'target: Optional NSX Manager target from config.' This adds meaningful meaning beyond the bare 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 starts with '[WRITE] Delete a DFW security policy,' using a specific verb and resource. It clearly distinguishes from sibling tools like list, get, create, and update by stating the exact action.
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?
Provides explicit guidance on a key precondition: 'Refuses if the policy still holds active rules: list them with list_dfw_rules and clear each with delete_dfw_rule first.' This names specific alternative tools and the order of operations, helping the agent decide when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by explaining the impact: 'Irreversible and immediate: traffic it matched falls through to lower-priority rules or the policy default.' It also discloses the lack of a guard against deleting a rule while the policy has rules, adding meaningful behavioral context.
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 well structured and front-loaded with its purpose. It includes return format, side effects, usage guidance, and parameter details without extraneous text. Every sentence adds value.
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?
For a destructive tool with no output schema, the description is complete: it covers what the tool does, return values, irreversibility, consequences, alternatives, prerequisites, and parameter sources. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully with an Args section explaining each parameter: policy_id from list_dfw_policies, rule_id from list_dfw_rules, and target as an optional default. This is exactly what an agent needs to populate the parameters correctly.
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 clearly states 'Permanently delete one DFW rule from its parent security policy.' It uses a specific verb (delete) and resource (DFW rule), and is clearly distinguished from sibling tools like delete_dfw_policy (whole policy) and update_dfw_rule (disable instead).
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?
Explicit guidance is given: use update_dfw_rule with disabled=True when the rule may be needed back, and use delete_dfw_policy to remove a whole policy, noting that delete_dfw_policy refuses while rules remain whereas this tool does not. It also recommends confirming rule_id with list_dfw_rules and checking hits with get_dfw_rule_stats first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description reveals crucial behaviors: member_count is the real size while members.items is only a capped sample of 50, the truncated flag indicates more items, and membership changes may take seconds to propagate. This adds significant context not encoded in annotations or 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 appropriately sized and front-loaded with '[READ]' and a clear summary. Each subsequent sentence adds a distinct, necessary detail (return structure, truncation, usage context, timing). There is no redundancy or filler.
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 lacking an output schema, the description thoroughly explains what the return object contains, how to interpret the truncated members list, and the relationship between member_count and members.items. It also covers the prerequisite of using list_groups and the eventual consistency behavior, making it fully self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though the schema has no descriptions for the parameters, the 'Args' section provides meaningful examples for group_id ('web-tier-vms') and clarifies that target is an optional NSX Manager target. This enriches the bare schema definitions with practical context and default behavior.
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 '[READ] Get details of a security group including membership criteria and effective members,' clearly stating the verb (get), resource (security group), and the specific details returned. It differentiates itself from siblings like list_groups (which narrows to one id) and get_dfw_policy (a different resource type).
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 instructs 'Use it once list_groups has narrowed to one id,' providing clear when-to-use guidance and naming the alternative (list_groups). It also adds a key temporal caveat about NSX evaluation delays, helping the agent know what to expect when using it in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, openWorld), the description adds crucial behavioral context: the response envelope fields, pagination behavior, default limit, and the caution that a page may be truncated. This significantly informs the agent about expected output and necessary follow-up actions.
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 efficiently structured and front-loaded with the action and purpose. It uses bullet-like argument formatting and short, informative sentences. No word is wasted; it covers return envelope, pagination, sibling tools, and all parameters without being verbose.
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, the description takes on the burden of explaining return fields and pagination metadata ('returned'/'limit'/'total'/'truncated'/'hint'), which it does thoroughly. It also provides workflow context (sibling tools) and operational warnings, making it complete for an agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by explaining each parameter in plain language: target (default from config), name_filter (substring/glob match), limit (max count, default 50), and offset (skip count). This is exactly what the agent needs to use the parameters correctly.
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 clear verb+resource: 'List DFW security policies in the default domain.' It distinguishes itself from siblings by specifying it returns a list envelope, and contrasts with get_dfw_policy and list_dfw_rules, making its purpose unmistakable.
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?
Explicit guidance is provided: 'Start here' sets it as the entry point. It tells the user to use get_dfw_policy for details and list_dfw_rules for rules, and warns against treating a full page as complete, advising name_filter or pagination. This is clear usage direction beyond just stating purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the return envelope structure, pagination behavior ('truncated=true' means more pages), the fact that 'total' is always null, and that policies can contain thousands of rules. This is valuable operational context not present in annotations.
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 well-structured: a clear [READ] tag, a concise purpose, a paragraph on return format, a workflow tip, and a compact Args list. Every sentence adds value and no redundancy exists.
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, the description adequately explains the return envelope and key fields (items, returned, limit, truncated, hint). It also covers prerequisites (policy_id from list_dfw_policies) and related tools (get_dfw_rule_stats). The tool's complexity is fully addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description's Args section is the only source of parameter meaning. It clearly explains policy_id, target, limit (default 50), and offset (pagination). This fully compensates for the schema gap.
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 'List rules in a DFW security policy' — a specific verb and resource. It clearly differentiates from siblings like list_dfw_policies (lists policies) and get_dfw_policy (gets a single policy). The purpose is unambiguous.
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 an explicit workflow: 'Get policy_id from list_dfw_policies; then get_dfw_rule_stats for a rule's hit counts.' This tells the agent when to use this tool and how it relates to alternatives. It also explains pagination usage with offset/limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, and idempotent hints. The description adds critical behavioral context about pagination semantics ('never read a full page as complete') and clarifies envelope fields like 'truncated'/'hint', which are not obvious from annotations alone.
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 compact yet information-dense. It front-loads the core purpose, then covers pagination caveats, a pointer to the related sibling, and parameter details in a crisp bullet-style Args block. No filler or repetition.
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, the description fully explains the return envelope and pagination semantics, making the tool self-contained. It covers default behavior, edge cases (truncated pages), and next steps, making it complete for a list-with-pagination tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema provides zero parameter descriptions, the Args block explains each parameter (target, name_filter, limit, offset) with practical meaning (e.g., 'Substring/glob match', 'Matched groups to skip'). This fully compensates for the schema gap.
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 starts with a clear verb-object statement: 'List NSX security groups in the default domain.' It distinguishes from siblings like get_group by noting it returns a list envelope and referencing get_group for single-group details. The [READ] prefix reinforces the read-only nature.
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?
Provides explicit usage guidance: warns against treating a page as complete, advises narrowing with name_filter or paginating with offset, and directs users to get_group for detailed criteria. This effectively tells when 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses detailed pagination behavior: it explains the envelope fields ('returned'/'limit'/'total'/'truncated'/'hint') and warns not to treat a page as complete. This is valuable context not available in annotations.
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 well-structured with a clear read marker, return-envelope explanation, pagination warning, cross-reference, and Args list. Every sentence adds functional value without redundant 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?
Given there is no output schema, the description thoroughly explains the return envelope and its fields, pagination semantics, and how to use the results. It also mentions a related tool for complementary data, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions, but the description's 'Args' section explains each parameter: target (optional NSX Manager target), name_filter (substring/glob match), limit (default 50), and offset (pagination). This fully compensates for the schema's lack of descriptions.
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 starts with '[READ] List IDPS profiles configured in NSX', which clearly states the verb (List), resource (IDPS profiles), and scope (in NSX). This distinguishes it from sibling tools like get_idps_status and list_dfw_policies by naming the specific resource and read-only operation.
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 explicitly tells the agent when to use this tool and how to handle pagination: 'never read a full page as complete, narrow with name_filter or page with offset.' It also points to an alternative, get_idps_status, for signature-bundle version and IDS settings, providing clear directional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation by disclosing concrete behavior: all tags arrive in one response (so truncated is always false), empty items means no tags, and error responses for no/some matching VMs. It also explains the deprecated 'tags' alias and the 2.0 removal, which is important for correct usage.
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 efficiently structured, starting with a [READ] tag and a concise summary, then details on return value, error behavior, deprecation, and parameter semantics. Every sentence provides useful information without redundancy or padding.
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?
Without an output schema, the description thoroughly explains the response envelope, including 'items', 'vm_id', 'truncated', and 'tags' alias, plus error handling. It also covers parameter prerequisites and usage context, making it complete for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 0%, the description includes a dedicated 'Args' section that adds critical meaning: vm_display_name is exact and case-sensitive with no wildcards, and target is an optional NSX Manager target. This compensates fully for the bare schema types.
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 clearly states the tool lists all NSX tags applied to a virtual machine, using a specific verb ('list') and resource ('NSX tags on a VM'). It also immediately distinguishes itself from siblings like apply_vm_tag/remove_vm_tag by explaining that it provides the required vm_id for those operations.
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 explicitly tells when to use this tool: 'call this first to get it' for the vm_id needed by apply_vm_tag/remove_vm_tag. It also gives an alternative for getting the VM display name (run vmware-monitor's list_virtual_machines) and notes that this skill does not enumerate VMs, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important lifecycle behavior beyond annotations: a FINISHED traceflow is deleted server-side and its ID 404s, only an IN_PROGRESS traceflow survives polling. Also explains return states and observation types. This adds significant context beyond readOnlyHint=false and destructiveHint=false.
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 front-loaded with the purpose, then organizes details and Args in a clear structure. Every sentence adds value—probe injection, return types, deletion behavior, and parameter explanations—with no filler.
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?
For a tool with 9 parameters, no output schema, and no enums, the description provides complete operational context: expected return values, lifecycle, prerequisites, and companion tools. Nothing critical is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining all 9 parameters in the Args section, including the source port ID's UUID nature and how to obtain it. Adds protocol values, defaults, and the meaning of timeout_seconds, going far 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 opens with a specific verb and resource: 'Run a Traceflow to trace a packet's path through the NSX overlay.' It explicitly distinguishes itself from siblings like get_dfw_rule_stats and get_traceflow_result by stating its role in the DFW troubleshooting flow.
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 states when to use this tool ('Use it to find which DFW rule drops a flow') and points to an alternative for port enumeration ('run vmware-nsx's get_segment_port_for_vm to obtain one'). Also references get_traceflow_result for polling, providing clear context for follow-up actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![VMware-NSX-Security MCP server](https://glama.ai/mcp/servers/vmware-skills/VMware-NSX-Security/badges/card.svg)](https://glama.ai/mcp/servers/vmware-skills/VMware-NSX-Security)

Score Badge

Copy to your README.md:

[![VMware-NSX-Security MCP server](https://glama.ai/mcp/servers/vmware-skills/VMware-NSX-Security/badges/score.svg)](https://glama.ai/mcp/servers/vmware-skills/VMware-NSX-Security)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vmware-skills/VMware-NSX-Security'

If you have feedback or need assistance with the MCP directory API, please join our Discord server