Skip to main content
Glama
vmware-skills

vmware-nsx

by vmware-skills
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

create_static_route

Create a static route on a Tier-0 or Tier-1 gateway for destinations not covered by connected routes. Provide network CIDR and next-hop address to add the route.

Instructions

[WRITE] Create a static route on a Tier-0 or Tier-1 gateway via the Policy API.

Use this for destinations not covered by connected or advertised routes, e.g. a VPN or external subnet. Run list_static_routes first to avoid an id clash — the same route_id overwrites (PUT). For the Tier-0 to advertise a Tier-1's static route upstream, the gateway needs TIER1_STATIC_ROUTES advertisement, set via update_tier1_gateway. Returns the created route dict, else {"error", "hint"}. Then confirm with list_static_routes; delete_static_route is the inverse.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoNSX Manager target from config (default if omitted).
networkYesDestination network in CIDR notation, e.g. "10.0.0.0/8".
next_hopYesNext-hop IPv4 address, e.g. "192.168.1.254".
route_idYesUnique id (alphanumerics, hyphens, underscores only).
tier1_idYesGateway ID (Tier-0 or Tier-1, per gateway_type), from list_tier0_gateways / list_tier1_gateways.
gateway_typeNoEither "tier0" or "tier1" (default "tier1").tier1

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed8 schema fields changedv1.8.16
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / gateway_type / description
      Added value: +"Either \"tier0\" or \"tier1\" (default \"tier1\")."
    • addedInput schema / properties / gateway_type / enum
      Added value: +[
+  "tier0",
+  "tier1"
+]
    • addedInput schema / properties / network / description
      Added value: +"Destination network in CIDR notation, e.g. \"10.0.0.0/8\"."
    • addedInput schema / properties / next_hop / description
      Added value: +"Next-hop IPv4 address, e.g. \"192.168.1.254\"."
    • addedInput schema / properties / route_id / description
      Added value: +"Unique id (alphanumerics, hyphens, underscores only)."
    • addedInput schema / properties / target / description
      Added value: +"NSX Manager target from config (default if omitted)."
    • addedInput schema / properties / tier1_id / description
      Added value: +"Gateway ID (Tier-0 or Tier-1, per gateway_type), from list_tier0_gateways / list_tier1_gateways."
  2. Changed1 schema field changedv1.6.0
    • addedInput schema / properties / gateway_type
      Added value: +{
+  "default": "tier1",
+  "title": "Gateway Type",
+  "type": "string"
+}
  3. First observedv1.3.2

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behavioral details: the same route_id overwrites via PUT, the risk of an id clash, the advertisement prerequisite for Tier-0 route propagation, the return shape (created route dict or error/hint), and the recommended confirmation via list_static_routes. This goes well beyond what readOnlyHint/idempotentHint/destructiveHint 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?

The description is well-structured and front-loaded with the core purpose, then packs critical caveats and workflow guidance into a few purposeful sentences. No sentence is redundant; each one adds operational 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 that there is no output schema, the description compensates by telling the agent what to expect in return. It covers when to use the tool, what to check before calling, overwrite behavior, an advertisement prerequisite, and how to verify the result, making the call sequence complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds operational context around route_id because it warns about overwriting with the same id, but it does not add substantially new parameter-level semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Create a static route on a Tier-0 or Tier-1 gateway via the Policy API.' This clearly identifies the tool's purpose and distinguishes it from sibling tools like create_nat_rule, create_segment, and list_static_routes.

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 when to use the tool ('for destinations not covered by connected or advertised routes') and provides a precondition: run list_static_routes first to avoid an id clash. It also references update_tier1_gateway for advertisement settings and delete_static_route as the inverse, giving clear routing among siblings.

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

Install Server

Other Tools

Latest Blog Posts

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