vmware-nsx

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 NSX resource and action (list/get/create/update/delete/configure), with clear boundaries between similar tools (e.g., list_segments vs get_segment vs get_logical_port_status). No two tools appear to perform the same operation.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (list_*, get_*, create_*, update_*, delete_*, configure_*) with lowercase and underscores throughout. The verbs clearly indicate read vs write operations.
Tool Count2/5
At 33 tools, the set exceeds the 25+ threshold for 'too many', making it heavy for an agent to manage. While each tool has a distinct purpose, the high count is at the upper edge and could be overwhelming, though not extreme (50+).
Completeness3/5
The tool surface covers core NSX workflows (segment/Tier-1/NAT/static route/IP pool lifecycle plus health monitoring), but notable gaps exist such as Tier-0 gateway CRUD, DHCP/DNS/LB/VPN services, and port attachment management. The explicit reference to a separate security server narrows the domain further.
Average 4.8/5 across 33 of 33 tools scored. Lowest: 4.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'The same tier1_id overwrites (PUT),' which implies an idempotent PUT-like behavior. However, the annotation idempotentHint is false. This directly contradicts the annotation, so per the rubric the score must be 1.
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 main purpose, followed by usage context, behavioral notes, return/verification info, and a detailed Args list. Every sentence contributes value without redundancy.
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 6-parameter create tool with no output schema, the description covers prerequisites, return format, verification via get_tier1_gateway, and important consequences (e.g., unreachable subnets without route_advertisement). It provides complete context to select and invoke the tool correctly among many siblings.
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?
Despite 0% schema description coverage, the Args section thoroughly explains each parameter: format ('alphanumerics, hyphens, underscores'), default behavior (tier0_path omission), requirements (edge_cluster_path for NAT), and exact enum values for route_advertisement. 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 uses a specific verb and resource: 'Create a Tier-1 gateway to route segments, optionally uplinked to a Tier-0.' It clearly distinguishes this from sibling tools like create_segment and update_tier1_gateway by stating the exact purpose.
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 provides explicit usage context: 'Use this before create_segment when the segment needs routing; get tier0_path from list_tier0_gateways and edge_cluster_path from list_edge_clusters first.' It also mentions the alternative of updating later, giving clear when-to-use and prerequisite guidance.
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, destructiveHint), the description reveals return structure (one dict, not list envelope), matching logic (exact display name), and edge cases (empty matched_ports means no VIF attached). It also clarifies what is not handled (VM power/placement).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, but multiple paragraphs contain some redundancy (e.g., first sentence expands on finding segments). Could be more concise without losing key 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?
Given no output schema, the description explains the return format (one dict with VM info and matched_ports) and semantics of empty results. It covers what the tool does and limitations, making it fairly complete for its 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?
Despite 0% schema description coverage, the description explains 'vm_display_name' as shown in vCenter/NSX inventory and 'target' as NSX Manager target with default behavior, adding meaning beyond the schema's titles.
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] Find which segment(s) a VM is attached to via its VIF attachments.', providing a specific verb+resource. It clearly distinguishes from sibling tools like 'list_transport_nodes' or 'delete_tier1_gateway' by focusing on VM-to-segment mapping.
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 says 'Start here for "why can this VM not reach the network?" — it is the only tool mapping a VM name onto NSX topology.' This gives clear when-to-use context, though it doesn't explicitly state when not to use or list alternatives.
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 read-only, idempotent, and non-destructive. Description adds context about pagination (truncated) and standalone gateway behavior. No contradictions.
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?
Five sentences cover purpose, pagination, usage, standalone meaning, and parameter. Concise and well-structured, though slightly verbose in the usage sentence.
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?
Given no output schema, the description explains the result envelope and truncated check, and hints at fields (Tier-0 path, route advertisement). Sufficient for a list tool, though could mention error handling.
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 coverage is 0%, but the description provides minimal semantics: target is the NSX Manager target from config with default. This adds some context but lacks format or value constraints.
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 Tier-1 gateways with linked Tier-0 path and route advertisement, distinguishing it from sibling tools like list_transport_nodes (different resource) and delete_tier1_gateway (different 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?
Explicit guidance: use this first to resolve tier1_id for other tools (create_nat_rule, etc.), check truncated before assuming completeness, and then use get_tier1_gateway for detail. Also explains meaning of empty tier0_path.
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 show readOnlyHint=false (write operation), destructiveHint=false. The description adds that it is a PUT-like operation that overwrites on same pool_id, returns a dict or error, and requires IPs to be inside cidr. It also references verification and inverse tools. This adds meaningful context beyond annotations.
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 well-structured with a clear summary, contextual notes, and parameter details. It front-loads the purpose. While not overly verbose, it could be slightly more concise, but the organization and readability are good.
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?
Given the tool has 7 parameters (5 required), no output schema, and multiple sibling tools, the description covers prerequisites (list_ip_pools), overwrite behavior, return format (dict or error), and parameter constraints. It also suggests verification. This is fairly complete for agent decision-making.
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 carries full burden. It provides an Args section explaining each parameter: pool_id (uniqueness, path), display_name (UI), start_ip and end_ip (examples), cidr (subnet), gateway_ip (optional, example), target (optional, default). This adds essential meaning beyond the schema's bare names and 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 starts with '[WRITE] Create an IP address pool with one static subnet and allocation range', clearly stating the verb (create) and resource (IP pool). It distinguishes from sibling tools like list_ip_pools, get_ip_pool_usage, and delete_ip_pool by mentioning them in context.
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 advises to run list_ip_pools first to avoid overlapping ranges, and suggests verifying with get_ip_pool_usage. It notes the inverse operation (delete_ip_pool) and warns about the overwrite behavior when the same pool_id is used. It does not explicitly state when not to use, but provides good contextual guidance.
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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds output structure (id, display_name, transport_type) and error behavior ('passing the wrong one is rejected'). No 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?
Description is well-structured: brief purpose, usage guidance, output details, parameter note. Could be slightly more concise, but no extraneous information.
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 list tool with no output schema, the description covers purpose, usage context, output fields, parameter, and error behavior. Complete for an agent to use effectively.
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?
Input schema has 0% coverage (no descriptions). Description explains the 'target' parameter: 'NSX Manager target from config (default if omitted).' This adds essential 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 clearly states 'List all NSX transport zones' and explains they are overlay/VLAN boundaries. It specifies scope ('all') and distinguishes from siblings like list_transport_nodes.
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?
Explicitly says 'Use this first when building a segment' and explains how the output is used to form transport_zone_path. Also differentiates between VLAN-backed and overlay zones. Missing explicit when-not-to-use, but guidance is clear.
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 a write operation (readOnlyHint=false). The description adds context: the same route_id overwrites (PUT behavior), the return format (created route dict or error dict), and that the route can be advertised upstream with proper configuration. This goes beyond annotations.
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 well-structured with a summary line, usage notes, and parameter list. It is somewhat long but every sentence adds value. Slightly verbose in the parameter section, but not wasteful.
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?
Given 6 parameters and no output schema, the description explains return values and errors. It also covers the overwrite idempotency nuance and precondition. However, it could mention more about the default target behavior or other edge cases.
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 carries full burden. It explains each parameter in detail: tier1_id (from list gateways), route_id (alphanumerics/hyphens/underscores), network (CIDR), next_hop (IPv4), gateway_type (tier0/tier1), target (from config). Examples are provided.
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 verb and resource: 'Create a static route on a Tier-0 or Tier-1 gateway via the Policy API.' This distinguishes it from sibling tools that deal with other network objects like segments, transport nodes, or IP pools.
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 when to use ('for destinations not covered by connected or advertised routes'), prerequisite actions ('Run list_static_routes first to avoid an id clash'), and mentions related tools (list_static_routes, delete_static_route, update_tier1_gateway).
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 read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable behavioral context: 'Only online nodes are listed, so a node missing from nodes is down rather than absent' and clarifies the return format (dict, not list). 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?
The description is concise and well-structured: a one-line purpose, followed by usage guidance, return format details, behavioral nuance, and a parameter arg. Every sentence contributes value without redundancy.
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?
Given the tool's complexity (cluster health), the minimal schema (one optional param), rich annotations, and no output schema, the description covers purpose, usage, return structure, and a key behavioral point. It could optionally detail the expected dict fields, but it is sufficiently complete for an agent.
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 explaining the single parameter: 'target: NSX Manager target from config (default if omitted)'. This adds meaning beyond the schema, though it could include more detail on the config source.
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 'Get NSX Manager cluster status (node health, control/management plane)', clearly stating the tool's verb and resource. It is distinct from sibling tools like list_transport_nodes or list_nsx_alarms, which target different aspects of NSX.
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 'Start any NSX health check here: if the manager cluster is degraded, every other reading is suspect', indicating when to use this tool first. It also suggests list_nsx_alarms as a follow-up, providing clear guidance on alternatives and sequence.
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 read-only, open-world, idempotent. Description adds the "result envelope" concept and the `truncated` check, which is valuable beyond annotations. No contradictions.
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 with a clear front-loaded [READ] label. Each sentence serves a purpose: listing, truncation warning, usage flow, parameter explanation. No wasted words.
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?
Given no output schema, description mentions the return envelope and `truncated` for pagination, but doesn't detail all fields in each cluster object. However, it provides enough context for an agent to use the tool effectively alongside sibling tools.
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 has one parameter with 0% schema description coverage. Description explains that `target` selects the NSX Manager from config and defaults if omitted, adding necessary 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?
Clear verb (list) and resource (edge clusters) with specific details (member count, deployment type). Distinguishes from siblings by explaining how it relates to other tools like get_edge_cluster_status and create_tier1_gateway.
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 (first to get cluster_id) and what to do next (get_edge_cluster_status). Also warns about checking `truncated` and explains its role in building edge_cluster_path for Tier-1 gateways.
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 indicate read-only, idempotent, non-destructive. Description adds important context about the result envelope and truncated field, and clarifies that summary status does not explain degradation reasons.
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?
Description is concise and well-structured: starts with a clear purpose, adds usage guidance, and explains parameter. No redundant sentences.
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?
Given the low complexity (1 parameter, no output schema) and rich annotations, the description covers essential behavior, limitations, and usage context adequately.
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 coverage at 0%, the description explains the target parameter as 'NSX Manager target from config (default if omitted)', adding meaning beyond the schema definition.
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 it lists all transport nodes (ESXi hosts and Edge nodes) with type and status, and differentiates from sibling tools like list_transport_zones and get_transport_node_status.
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: use this first to resolve node_id, then use get_transport_node_status for details. Also advises to check truncated before considering the result complete.
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-readonly and non-destructive; the description adds that this is a PATCH partial update and that changing subnet can drop traffic for attached VMs, which is valuable side-effect information. No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, starting with purpose and usage guidance before a brief Args list. Each sentence carries information; no filler.
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 an update tool with four parameters and no output schema, the description covers the operation mode (PATCH), side effects, prerequisite checks, and return value (updated dict or error). It lacks only extended details like authentication, but that is not needed for selection/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?
Schema description coverage is 0%, but the description provides clear explanations for all four parameters: segment_id is from list_segments, display_name is optional, subnet format example, and target defaults from config. This fully compensates for the lack of schema 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?
Description opens with '[WRITE] Update an existing network segment (partial update via PATCH).' It clearly identifies the action (update) and resource (network segment), and distinguishes from create_segment by noting that create overwrites everything.
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 tells the agent to 'Use get_segment first' and to 'prefer this over create_segment for an existing segment' because create is a PUT that overwrites everything. It also warns to check port_count before changing subnet, providing concrete when-to and when-not-to guidance.
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, idempotentHint=true, and destructiveHint=false. The description adds value by noting the return envelope with a truncated flag and clarifying that the usage summary does not tell which addresses are taken, providing behavioral context beyond 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 concise with three short paragraphs. Every sentence contributes essential information: purpose, return envelope behavior, usage guidance, and parameter explanation. No redundant or irrelevant text.
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 read-only list tool with one optional parameter and no output schema, the description comprehensively covers purpose, usage sequence, parameter details, and behavioral nuance (truncated flag and summary limitation). No gaps remain.
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 explaining the 'target' parameter: 'NSX Manager target from config (default if omitted).' This adds meaning beyond the schema's null default.
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 'List all IP address pools with subnets and usage summary,' specifying the action (list), resource (IP address pools), and returned information (subnets and usage summary). It distinguishes itself from siblings like get_ip_pool_usage and create_ip_pool.
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 guides the agent to use this tool first to resolve a pool_id before get_ip_pool_usage, and to run it before create_ip_pool to avoid overlapping ranges. Also mentions checking the 'truncated' flag for completeness.
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 provide read/write and destructive hints (readOnlyHint: false, destructiveHint: false). The description adds critical context: PATCH semantics (only fields passed change), route_advertisement whole-list replacement behavior, 'Re-applying identical values is harmless', and the return format including error hint. This goes beyond annotations, though it doesn't cover auth or rate limits, which is acceptable for this 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 the purpose in the first sentence. Every sentence adds value: usage guidance, behavior, and parameter details. The structured Args section is easy to scan. Despite its length, it's appropriately sized for 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?
Given no output schema, the description explicitly states 'Returns the updated gateway dict, else {"error", "hint"}'. It covers all parameters, usage context, and behavioral nuance. Complete for a 5-parameter update tool with 1 required param.
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 carries full burden. It explains every parameter in the Args section, including tier1_id, display_name, tier0_path with an example, route_advertisement with the full list of enum values, and target with default. This is comprehensive and 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 an existing Tier-1 gateway via PATCH', specifying the verb, resource, and HTTP method. It differentiates from 'create_tier1_gateway' (PUT, overwrites) and 'delete_tier1_gateway', making the 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use get_tier1_gateway first' as a prerequisite, and 'Prefer this over create_tier1_gateway for an existing gateway' with the reason that create is a PUT and overwrites. Also warns about route_advertisement being sent as a whole list, telling users to include all types they want kept. This fully addresses when and how to use the 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?
Discloses write nature (PUT overwrite), return format (dict or error), and the nuance that subnet is the gateway address, not network address. Annotations confirm readOnlyHint=false, no contradictions.
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?
Well-structured with a clear intro and bullet-like arg details. Some repetition (subnet explanation), but overall efficient. Could be slightly more concise.
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 6 parameters, no nested objects, no output schema, the description is highly complete: covers prerequisites, behavior, return, parameter details, and post-creation steps. No gaps.
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?
Adds detailed meaning for all 6 parameters despite 0% schema coverage. Explains constraints (e.g., segment_id alphanumerics/hyphens/underscores), format (transport_zone_path full path), and examples (vlan_ids '100,200', subnet '192.168.1.1/24'). Addresses the mutually exclusive nature of subnet and vlan_ids.
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 it creates an overlay or VLAN-backed NSX network segment. It distinguishes between the two types and mentions the overwrite behavior. Sibling tools are different (e.g., delete, get), and the description sets it apart.
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 advises to run list_transport_zones first to get the transport_zone_path, explaining how it determines whether subnet or vlan_ids applies. Also provides guidance on linking the segment with create_tier1_gateway and verifying with get_segment.
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 critical behavior beyond annotations: 'disconnects all attached VMs', 'Irreversible', and preconditions (NSX refuses if ports attached). Annotation destructiveHint=true is consistent and reinforced.
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?
Well-structured with warning, instructions, and Args list. Front-loaded with purpose and warning. Slightly verbose but every sentence adds value; could be tightened without losing information.
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?
Covers all essential aspects for a destructive tool: prerequisites (get_segment check), consequences (disconnects VMs, irreversible), return format, and parameter documentation. Complete given output schema existence and 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?
With 0% schema coverage, description fully compensates by detailing each parameter: segment_id's origin ('as returned by list_segments') and target's default behavior ('default if omitted'). Adds meaning 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 explicitly states 'Delete a network segment' with a [WRITE] prefix, clearly identifying the action and resource. It distinguishes from siblings like create_segment and delete_tier1_gateway by focusing on segment deletion.
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: Run get_segment first to check port_count, confirm with user, and notes that NSX refuses deletion if ports are attached. Also describes return format (confirmation or error string).
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?
Adds significant behavioral context beyond the readOnlyHint/idempotentHint annotations: specifies the return shape (single dict not list), enumerates the fields returned, and explicitly states what is NOT included (attached segments). This gives the agent a clear picture of the tool's output and limitations.
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 concise and front-loaded with the core purpose. Each sentence earns its place: usage context, return format, exclusions, and argument definitions. No redundant or filler content.
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, the description fully compensates by listing return fields, explaining the distinction from the list tool, and embedding the tool in a workflow (after list, before update). It is self-sufficient for an agent to invoke correctly in context.
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 explaining tier1_id as returned by list_tier1_gateways and target as the NSX Manager target from config (default if omitted). This adds practical meaning beyond the schema's raw parameter names. Slight room for improvement in detailing target's possible values, but it is adequate.
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 'Get detailed info for one Tier-1 gateway' with a specific verb and resource. Differentiates from siblings by noting it returns a single detail dict (not list envelope) and is a prerequisite for update_tier1_gateway, and by pointing to list_segments for attached segments.
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 instructs to use after list_tier1_gateways and always before update_tier1_gateway, explaining why (PATCH needs current values). Also names list_segments as the alternative for attached segments, providing clear when-to-use and when-not-to-use 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 adds context beyond annotations: it specifies the return format ('Returns one dict (not the list envelope)'), lists key fields (node_id, status, control_connection_status, mgmt_connection_status, tunnel_status, pnic_status), and notes it's point-in-time only. Annotations already indicate readOnly, openWorld, idempotent, non-destructive, and the description reinforces and elaborates 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a heading, usage guidance, return details, and parameter descriptions. It is concise, with each sentence earning its place, and no unnecessary words.
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 has 2 parameters, no output schema, and 0% schema coverage, the description covers purpose, usage guidelines, behavioral context, return fields, and parameter semantics thoroughly. It also provides troubleshooting guidance, making it 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains node_id as 'Transport node UUID, as returned by list_transport_nodes' and target as 'NSX Manager target from config (default if omitted)', adding meaning beyond the schema's generic titles. A score of 4 acknowledges good coverage but could include more detail on target format.
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 realized runtime status of one transport node (ESXi host or Edge node)' and uses the '[READ]' prefix to indicate a read operation. It distinguishes itself from sibling tools like list_transport_nodes and get_edge_cluster_status.
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 explicit guidance on when to use this tool ('after list_transport_nodes when a node looks degraded or overlay tunnels are suspect'), when to use an alternative ('for cluster-wide edge health use get_edge_cluster_status instead'), and when not to (if tunnels are down on one segment, follow up with get_logical_port_status).
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 indicate read-only, idempotent, non-destructive. Description adds [READ] marker, notes truncation ('check truncated'), and clarifies scope (USER section only), going beyond 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?
Compact and well-organized, with a clear [READ] header, prerequisites, usage scenarios, and param explanations. 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?
Given 2 simple params and no output schema, description covers purpose, prerequisites, usage, truncation hint, and scope. Annotations complement with safety profile. Adequately 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 coverage, description explains tier1_id as 'Gateway ID, as returned by list_tier1_gateways' and target as 'NSX Manager target from config (default if omitted)'. Adds meaning but target description could be more specific.
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?
Describes listing NAT rules on a Tier-1 gateway, specifying the USER section and noting it excludes NSX-internal NAT. Clear verb+resource and scope.
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 prerequisite (get tier1_id from list_tier1_gateways) and provides specific use cases: before create_nat_rule to avoid id clash and before delete_nat_rule to confirm rule behavior.
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 discloses important behaviors beyond annotations: 'Returns the result envelope; check truncated before calling it complete' indicates pagination or truncation. The note about exact match severity is critical for correct usage. Annotations already provide readOnlyHint and idempotentHint, but the description adds valuable context about how the tool operates.
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 concise and well-structured. It starts with a clear purpose statement, then covers return behavior, severity note, usage workflow, and parameter details. Every sentence serves a purpose, and there is no redundant or extraneous information.
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?
Given the tool's complexity (2 parameters, no output schema), the description is fairly complete. It explains the return envelope and the truncated check. However, it does not list the specific fields returned beyond 'feature, description, and entity,' which would be helpful for an agent to understand the output. Still, it is adequate for a 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?
The input schema has 0% description coverage, so the description fully compensates. It explains severity values ('LOW, MEDIUM, HIGH or CRITICAL') and the exact-match semantics. It also clarifies the target parameter: 'NSX Manager target from config (default if omitted).' This provides complete 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 clearly states the tool's purpose: 'Get active NSX alarms at one severity, with feature, description, and entity.' It specifies the resource (NSX alarms) and the action (get/list). The specificity of the severity filter and the mention of exact match distinguish it from generic list tools. The name and description leave no ambiguity.
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 explicit usage guidance: 'Start a health check at get_nsx_manager_status, then come here, then drill into the entity the alarm names with get_transport_node_status or get_edge_cluster_status.' It also explains the exact-match nature of the severity filter, advising to call once per severity for full coverage. This helps the agent decide when and how to use the tool vs. 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?
Adds significant context beyond annotations: it sets only specific settings, will not establish peering on its own, returns a config dict or error, and is a write operation (consistent with readOnlyHint=false). No contradictions found.
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 opening, usage hint, return statement, and organized Args list. Every sentence adds value, and the length is justified by 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?
Complete for a 7-parameter tool with no output schema: covers prerequisites, scope, return behavior, follow-up steps, and aligns with sibling tools. No missing context 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 description coverage is 0%, but the description fully compensates by explaining every parameter in the Args section, including defaults and examples (e.g., local_as_num as string). No gaps remain.
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 configures BGP settings on a Tier-0 gateway's locale-service, with a specific verb and resource. It also distinguishes from neighbor creation, clarifying the scope versus sibling BGP-related 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?
Explicitly instructs to use get_tier0_gateway first, notes that neighbor creation is not covered, and recommends checking get_bgp_neighbors afterward. This provides clear when-to-use and when-not-to-use 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?
Beyond the annotations (readOnlyHint=false), the description warns that the same rule_id overwrites, which is a crucial behavioral trait. It also discloses the need for an edge cluster and TIER1_NAT advertisement for the NAT to be realized, and describes the return value including error hints. No contradiction with annotations is present.
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 brief purpose line, critical usage warnings, and a clear Args list. Despite the length, every sentence adds necessary information and no redundant filler is present.
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 no output schema and complex prerequisites, the description covers all necessary context: how to obtain IDs, the overwrite risk, upstream requirements, return format, and confirmation step. It is complete enough 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?
With schema description coverage at 0%, the description fully compensates by explaining each parameter's purpose, including required conditions (source_network for SNAT, destination_network for DNAT) and defaults (action default 'DNAT', target default omitted). This is far beyond what the bare schema provides.
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 'Create a NAT rule on a Tier-1 gateway's USER NAT section', clearly stating the verb, resource, and specific location. It distinguishes itself from siblings like list_nat_rules and delete_nat_rule by its create focus and explicit placement.
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 to run list_tier1_gateways and list_nat_rules to avoid ID clashes, names create_tier1_gateway and update_tier1_gateway as prerequisites, and identifies delete_nat_rule as the inverse. These are concrete, actionable guidelines that also reference sibling tools appropriately.
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?
Describes the irreversible nature, rejection conditions, and return format (confirmation string or error string), going beyond annotations which only mark as destructive.
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?
Highly concise yet comprehensive: header, warning, usage steps, parameter descriptions, all in a clear structure without redundancy.
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?
Fully covers the operation's purpose, prerequisites, behavior, and output, making it complete for an AI agent to use 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?
With 0% schema coverage, the description adds crucial meaning: pool_id is from list_ip_pools, target is optional defaulting from config.
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 explicitly states the action 'Permanently delete an IP address pool' with a [WRITE] tag, clearly differentiating from sibling tools like list_ip_pools and get_ip_pool_usage.
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 when-to-use (to delete a pool) and when-not-to-use (if active allocations exist), and recommends checking usage first via get_ip_pool_usage, plus user confirmation.
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?
With annotations already marking destructiveHint=true and readOnlyHint=false, the description adds crucial context: the deletion is irreversible, immediately stops traffic translation, and may break DNAT/SNAT connectivity. Also discloses the return format (confirmation or error string, not dict), going beyond 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: purpose first, then irreversible warning, then return type, then parameters. Every sentence carries meaningful information without redundancy.
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 mutation tool, it covers prerequisites, consequences, return value, and parameter semantics. The output schema exists but the description still clarifies the actual return string, making the tool fully self-contained.
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 has 0% description coverage, but the description fully documents all three parameters: tier1_id identifies the owning gateway (with reference to list_tier1_gateways), rule_id identifies the rule (with reference to list_nat_rules), and target specifies the NSX Manager target with 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?
Clearly identifies the action (permanently delete), the resource (NAT rule), and the scope (Tier-1 gateway's USER NAT section). Distinguishes from sibling tools like create_nat_rule and list_nat_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?
Explicitly instructs to run list_nat_rules first to confirm rule_id and review action/networks, and to confirm with the user before deleting. This provides clear when-to-use guidance and a prerequisite 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?
Despite the destructiveHint annotation already signaling danger, the description adds crucial context: irreversibility, immediate traffic fallback/dropping, and the exact return type (confirmation string or 'Error: ...' string, not a dict). This goes well beyond annotation signals and covers both success and failure 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?
The description is efficiently front-loaded with the core action, followed by critical cautions and parameter docs. No sentence is wasted; even the return-type note earns its place. The bulleted Args block is structurally clean and scannable.
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 this is a destructive, irreversible write operation with four parameters and an output contract, the description covers prerequisites (listing routes), confirmation steps, parameter constraints, and return format. It is fully self-contained and leaves no obvious gaps.
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% (no parameter descriptions in schema), but the Args section fully explains each of the four parameters, including default values and provenance (e.g., tier1_id from list_tier0_gateways/list_tier1_gateways, route_id from list_static_routes). This fully compensates for 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 opens with a specific verb and resource: 'Permanently delete a static route from a Tier-0 or Tier-1 gateway.' This clearly distinguishes it from sibling tools like create_static_route and list_static_routes, and the scope (Tier-0/Tier-1) is explicit.
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 when-to-use guidance: 'Run list_static_routes on the same tier1_id first to confirm... and confirm with the user before deleting.' It also warns about the need to match gateway_type, giving clear prerequisites and cautions not found in sibling descriptions.
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 show destructiveHint=true, but description adds irreversible nature, cascading deletion of segments and NAT rules, locale-service removal, and return type. No contradictions.
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 yet comprehensive: warning, prerequisites, behavior, return type, args. No redundancy. Front-loaded with '[WRITE]'.
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 tool's destructive nature and complexity, description covers all critical aspects: prerequisites, effects, return value. Output schema is present, though not detailed.
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 coverage, description fully explains tier1_id as 'Gateway ID to delete, as returned by list_tier1_gateways' and target as optional default. Adds necessary context.
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?
Description clearly states the tool deletes a Tier-1 gateway, warns about attached segments and NAT rules. Unique among siblings as the only delete gateway 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?
Explicitly advises to run get_tier1_gateway and list_nat_rules first, and to confirm with user. Explains automatic removal of locale-service. No sibling confusion.
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?
Description adds valuable behavioral context beyond annotations: it returns a dict (not a list envelope), reads only the gateway's FIRST locale-service, and returns a hint (not an error) when no locale-service exists. These specifics are not predictable from annotations alone and improve transparency.
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 purpose line, usage context, return format, edge-case caveat, and alternative tool references. Every sentence adds value, and the content is front-loaded with the most important information.
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 read-only tool with strong annotations, the description covers purpose, usage, return shape, edge cases, and related tools. It fully addresses the context needed for an agent to select and invoke the tool correctly, even without an output schema.
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 must carry the burden. It does: 'tier0_id: Tier-0 gateway ID, as returned by list_tier0_gateways' and 'target: NSX Manager target from config (default if omitted).' These provide provenance and default behavior, adding clear meaning beyond the bare schema titles.
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: 'Get BGP configuration and neighbor status for a Tier-0 gateway.' This clearly defines the tool's scope and distinguishes it from siblings like configure_tier0_bgp (write operation) and get_edge_cluster_status (infrastructure status).
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 when-to-use guidance is provided: 'Use this to verify dynamic routing after configure_tier0_bgp, or when troubleshooting north-south connectivity.' It also names alternatives for related cases: 'If sessions are down, check get_edge_cluster_status' and 'Static routes are listed separately by list_static_routes.'
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 and idempotentHint annotations, the description discloses crucial behavioral details: it returns one dict (not the list envelope), lists the exact fields, and clarifies that member status is included but degradation reasons are not. This is valuable context that helps the agent understand response structure and boundaries.
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 written with no fluff. It front-loads the purpose, then provides usage context, return details, and parameter explanations in a logical order. Every sentence adds value and the structure is 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?
For a simple two-parameter, read-only tool, the description is complete. It covers when to use it, what it returns (including field names), the safety profile (via annotations), and the relationship to other tools. No output schema is present, but the description adequately explains the return structure.
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?
Despite 0% schema coverage, the description fully explains both parameters: cluster_id is described as the edge cluster UUID as returned by list_edge_clusters, and target is described as the NSX Manager target from config with a default. This compensates entirely 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 clearly states the tool checks the status of an edge cluster, including member health and overall status. It distinguishes itself from siblings like get_transport_node_status (which focuses on transport nodes) and list_edge_clusters (which lists clusters) by specifying the exact resource and 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?
It explicitly says to use this after list_edge_clusters when north-south traffic, NAT, or BGP looks broken, providing specific context. It also points to get_transport_node_status as the alternative for understanding why a member is degraded, which is excellent sibling differentiation.
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 readOnlyHint=true, destructiveHint=false, etc. Description adds valuable context: returns a single dict with specific fields (pool_id, allocation_count, allocations), clarifies that an empty allocations list means unused (not failure), and describes error response format. No contradictions.
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 concise with a brief summary paragraph followed by parameter descriptions. Every sentence adds value, no fluff. Front-loaded with the purpose and key usage guidance.
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 tool with 2 parameters and no output schema, the description is comprehensive. It covers usage sequence, return format, interpretation of empty results, and error response. An agent can correctly invoke this tool without ambiguity.
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 fully explains both parameters: pool_id is the IP pool ID as returned by list_ip_pools, and target is the NSX Manager target from the config with a default. This adds essential meaning beyond the schema's type and title.
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 it gets current IP allocations for one pool, using the verb 'get' with a specific resource. It distinguishes from sibling list_ip_pools by stating it is used after listing to see consumption, and from delete_ip_pool by noting it should be checked before deletion.
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: after list_ip_pools and before delete_ip_pool. Provides concrete use cases like diagnosing TEP address exhaustion and checking for remaining allocations. No alternatives are needed as the purpose is 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?
Beyond the annotations (readOnlyHint, openWorldHint, etc.), the description reveals critical behavioral traits: only the first 50 ports are returned, NSX does not expose a simple UP/DOWN flag, and an attached port with realized bindings on at least one transport node is considered healthy. It also explains what fields are returned and when to escalate to get_transport_node_status, adding substantial operational 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 efficiently front-loaded with the purpose, then usage context, then return details, then fallback advice, followed by a clean Args block. Each sentence conveys distinct value without redundancy, and the structure makes it easy to scan for key operational points.
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 comprehensively explains the return payload (admin_state, attachment, realized_bindings_count, transport_node_ids) and how to interpret health. It also covers prerequisites, limitations, and related tools, making the tool fully self-contained for an agent to select and 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 input schema provides only parameter names and types with no descriptions (coverage 0%). The description's Args section compensates fully: 'segment_id: Segment ID whose ports to inspect, as returned by list_segments' and 'target: NSX Manager target from config (default if omitted).' This gives the agent everything needed to populate 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 '[READ] Check realized state of all ports on a segment (first 50 ports).' This gives a specific verb, resource, and a key limitation. It also distinguishes itself from siblings by referencing get_segment_port_for_vm and delete_segment, clarifying its unique role in the workflow.
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 explicit usage guidance: 'Use this after get_segment_port_for_vm has told you which segment a VM sits on, or before delete_segment to see whether ports are still attached.' It also names an alternative: 'If bindings are missing everywhere, check get_transport_node_status.' This clearly tells the agent when to use this tool versus others.
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, it discloses the return format ('one dict, not the list envelope'), a critical limit ('first 50 ports only'), and the operational implication ('cannot be deleted — check port_count before calling delete_segment'). This adds substantial context not available in structured fields.
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 purpose, then efficiently packs usage, return details, and related tools without redundancy. Every sentence serves a purpose.
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, the description fully covers return fields, pagination behavior, and sibling tool relationships. It is self-sufficient 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?
The description explains segment_id as 'final component of /infra/segments/<id>, as returned by list_segments' and target as 'NSX Manager target from config (default if omitted).' This provides meaning beyond the bare schema fields and compensates for the 0% schema description coverage.
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 explicitly states 'Get full details for one network segment, including its attached ports,' which clearly identifies the verb, resource, and scope. It also distinguishes itself from the sibling tool list_segments by specifying 'one segment' versus 'list.'
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 provides explicit guidance: 'Use after list_segments to inspect one segment' and contrasts with get_logical_port_status and update_segment. This gives clear when-to-use and when-not-to-use 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: it returns a dict with specific fields, and notes 'Static config only — it does not say whether the gateway is currently forwarding.' This goes beyond the annotations and helps set expectations.
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 sections for usage, return details, limitations, and args. Every sentence provides necessary information without redundancy or fluff, making it appropriately sized for 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?
With no output schema, the description compensates by listing return fields (id, display_name, ha_mode, etc.) and clarifying the static-config limitation. It also places the tool in a workflow with list_tier0_gateways and create_tier1_gateway, making the description complete for practical use.
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?
Despite 0% schema description coverage, the description explains both parameters clearly: tier0_id is 'as returned by list_tier0_gateways' and target is 'NSX Manager target from config (default if omitted)'. This fully compensates for the missing schema 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 clearly states 'Get configuration details for one Tier-0 gateway' with a specific verb and resource, and distinguishes itself from siblings like list_tier0_gateways and get_bgp_neighbors. It also clarifies it returns a single dict, not a list envelope, which is a distinct 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?
Explicit guidance is given: 'Use after list_tier0_gateways to inspect HA configuration, or to build the tier0_path', and 'For BGP peering state use get_bgp_neighbors instead'. This provides clear when-to-use and alternative tool selection.
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, idempotent, non-destructive, open-world. The description adds valuable behavioral context: the exact result envelope shape, the meaning of `truncated`, and the warning to check it before treating the result as complete. This goes well beyond what annotations alone provide.
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?
Well-structured and front-loaded: first sentence states purpose, then result envelope, then usage guidance, then Args. Every sentence carries useful information—the envelope details are dense but necessary since there's no output schema.
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 list tool with no output schema, the description fully compensates: it explains the return shape, truncation semantics, and how to proceed to related tools (get_segment, get_logical_port_status). It also handles all parameter semantics with a single simple arg, making it complete for agent use.
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 explicitly documents the only parameter: 'target: NSX Manager target from config (default if omitted).' This adds practical meaning beyond the schema's type/default by explaining its source 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] List all NSX network segments' — a specific verb, resource, and listed output fields (type, subnet, admin state, port count). It clearly differentiates from get_segment and other list tools like list_ip_pools.
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 workflow: 'Use this first to resolve a segment_id, then get_segment for its ports and linked gateway, or get_logical_port_status for realized state.' It also excludes distributed firewall rules and points to vmware-nsx-security, giving clear when-to-use 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?
Beyond annotations (readOnly, idempotent, non-destructive), it discloses the result envelope with `truncated` flag, that querying the wrong tier returns an empty list rather than an error, and that BGP routes are excluded. These are valuable behavioral traits not available from 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 a clear one-liner, then provides return behavior, usage guidance, and parameter details in a structured Args format. Every sentence adds critical 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?
For a read-only list tool with no output schema, the description fully covers purpose, usage flow, edge cases (wrong tier, truncated results), and parameter semantics. It even distinguishes from BGP routes, making it 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 has 0% description coverage, but the description compensates with an Args section explaining tier1_id, gateway_type, and target. It clarifies tier1_id can be Tier-0 or Tier-1 based on gateway_type, lists valid gateway_type values, and describes target as 'NSX Manager target from config'.
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 'List static routes on a Tier-0 or Tier-1 gateway' with a specific verb and resource. It distinguishes itself from siblings like get_bgp_neighbors (BGP routes) and create/delete_static_route by framing its role in the workflow.
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 to use before create_static_route to avoid id clash and before delete_static_route to confirm destination/next hops. Also clarifies 'BGP-learned routes are not here; use get_bgp_neighbors', providing a clear alternative.
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 discloses the result envelope with a truncation caveat ('check truncated before calling it complete') and proactively states the scope limitation about Tier-0 creation. This adds 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 front-loaded with the purpose, then workflow guidance, then args. Every sentence earns its place with no filler, making it highly efficient.
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 list tool, it covers what it returns, how to use it in a multi-step workflow, the truncation behavior, and parameter semantics. It is comprehensive without verbosity.
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 only parameter, target, is documented in the description as 'NSX Manager target from config (default if omitted),' adding meaning that the schema's type/default alone lack. Since schema coverage is 0%, this fully compensates.
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 all Tier-0 gateways with HA mode and transit subnets,' a specific verb+resource pairing that immediately distinguishes the tool from sibling get_tier0_gateway. It clearly focuses on listing all gateways rather than fetching a single one.
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 positions this as the entry point: 'Use this first to resolve a tier0_id, then get_tier0_gateway... or get_bgp_neighbors...' and notes that Tier-0s aren't created by this skill, preventing misuse.
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 MCP server](https://glama.ai/mcp/servers/vmware-skills/VMware-NSX/badges/card.svg)](https://glama.ai/mcp/servers/vmware-skills/VMware-NSX)

Score Badge

Copy to your README.md:

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

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'

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