Skip to main content
Glama

configure_tier0_bgp

Set BGP settings on a Tier-0 gateway's locale-service: local AS number, ECMP, and inter-SR iBGP. Enables BGP after obtaining tier0_id; note neighbor peering requires separate configuration.

Instructions

[WRITE] Configure BGP settings on a Tier-0 gateway's locale-service.

Use get_tier0_gateway first to confirm the tier0_id. Sets BGP settings only (local AS, ECMP, inter-SR iBGP); neighbor creation is a separate Policy API object not exposed here, so peering will not come up from this call alone. Returns the updated BGP config dict, else {"error", "hint"}. Then check get_bgp_neighbors for session state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ecmpNoEnable ECMP for BGP routes (default True).
targetNoNSX Manager target from config (default if omitted).
enabledNoEnable or disable BGP on the locale-service (default True).
tier0_idYesTier-0 gateway ID, as returned by list_tier0_gateways.
local_as_numYesLocal AS number as a string, e.g. "65001".
inter_sr_ibgpNoEnable inter-SR iBGP (default True).
locale_service_idNoLocale-service identifier (default "default").default

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.8.16
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / ecmp / description
      Added value: +"Enable ECMP for BGP routes (default True)."
    • addedInput schema / properties / enabled / description
      Added value: +"Enable or disable BGP on the locale-service (default True)."
    • addedInput schema / properties / inter_sr_ibgp / description
      Added value: +"Enable inter-SR iBGP (default True)."
    • addedInput schema / properties / local_as_num / description
      Added value: +"Local AS number as a string, e.g. \"65001\"."
    • addedInput schema / properties / locale_service_id / description
      Added value: +"Locale-service identifier (default \"default\")."
    • addedInput schema / properties / target / description
      Added value: +"NSX Manager target from config (default if omitted)."
    • addedInput schema / properties / tier0_id / description
      Added value: +"Tier-0 gateway ID, as returned by list_tier0_gateways."
  2. Addedv1.8.9
  3. Removedv1.7.6
  4. Changed11 schema fields changedv1.5.18
    • addedInput schema / properties / ecmp
      Added value: +{
      +  "default": true,
      +  "title": "Ecmp",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / enabled
      Added value: +{
      +  "default": true,
      +  "title": "Enabled",
      +  "type": "boolean"
      +}
    • removedInput schema / properties / hold_time
      Removed value: -{
      -  "default": 180,
      -  "title": "Hold Time",
      -  "type": "integer"
      -}
    • addedInput schema / properties / inter_sr_ibgp
      Added value: +{
      +  "default": true,
      +  "title": "Inter Sr Ibgp",
      +  "type": "boolean"
      +}
    • removedInput schema / properties / keep_alive
      Removed value: -{
      -  "default": 60,
      -  "title": "Keep Alive",
      -  "type": "integer"
      -}
    • removedInput schema / properties / local_as
      Removed value: -{
      -  "title": "Local As",
      -  "type": "integer"
      -}
    • addedInput schema / properties / local_as_num
      Added value: +{
      +  "title": "Local As Num",
      +  "type": "string"
      +}
    • addedInput schema / properties / locale_service_id
      Added value: +{
      +  "default": "default",
      +  "title": "Locale Service Id",
      +  "type": "string"
      +}
    • removedInput schema / properties / neighbor_address
      Removed value: -{
      -  "title": "Neighbor Address",
      -  "type": "string"
      -}
    • removedInput schema / properties / remote_as
      Removed value: -{
      -  "title": "Remote As",
      -  "type": "integer"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "tier0_id",
      -  "local_as",
      -  "neighbor_address",
      -  "remote_as"
      -]New value: +[
      +  "tier0_id",
      +  "local_as_num"
      +]
  5. First observedv1.3.2

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark the call as non-read-only, but the description adds context: it is a write that only changes BGP settings, will not establish peering, and returns the updated config dict or an error/hint. This goes beyond the annotations by clarifing the exact scope of side effects and follow-up 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?

Three sentences, front-loaded with [WRITE] and the core action, with no redundant phrasing. Every sentence earns its place: what it does, prerequisite workflow, and follow-up.

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 multi-step BGP configuration tool with no output schema, the description covers prerequisite, scope, return shape, and follow-up check. The openWorldHint/idempotent annotations plus reference to siblings complete the picture, so no critical missing guidance.

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 100%, so the schema already documents all parameter names, types, defaults, and descriptions. The desdescription adds only light context, such as confirming tier0_id via get_tier0_gateway and naming the settings fields, which matches the baseline of 3.

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 states a specific operation: configure BGP settings on a Tier-0 gateway's locale-service, and immediately distinguishes itself by noting it sets BGP settings only, not neighbor creation. The verb 'configure' plus resource clearly separates it from read-only siblings like get_tier0_gateway and get_bgp_neighbors.

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 presribes a workflow: confirm tier0_id with get_tier0_gateway first, then configure, then check get_bgp_neighbors for session state. It also states when not to rely on it—neighbor creation is separate and peering will not come up from this call alone—so the agent can choose alternatives appropriately.

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