Skip to main content
Glama
john-broadway

Proximo

by john-broadway
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

pve_sdn_apply

Apply pending SDN configuration changes cluster-wide. Dry-run by default; set confirm=True to execute, disrupting virtual networking for all guests if misconfigured.

Instructions

MUTATION (HIGH RISK): apply pending SDN config changes (cluster-scoped).

Stage zones/vnets/subnets first with pve_sdn_zone_create / pve_sdn_vnet_create / pve_sdn_subnet_create — this applies whatever is pending; for interface/bridge changes use pve_network_apply instead. Dry-run by default — the PLAN surfaces pending zones/vnets AND cites pve_sdn_dry_run's rendered diff (fail-open — an unreachable dry-run degrades to an honest note, never blocks this plan). confirm=True executes with no automatic undo (short of pve_sdn_rollback, which discards PENDING changes only — it cannot revert an already-applied, now-LIVE config), disrupting virtual networking for ALL guests cluster-wide if misconfigured. May return a UPID (async) or None (sync) — outcome='submitted' in either case.

Wave 7a extension: pass lock_token/release_lock if you already hold a lock from pve_sdn_lock_acquire. Both omitted: byte-for-byte the same call as before this extension. lock_token is never written to the audit ledger (see network.py module docstring).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoFalse (default) returns a dry-run PLAN only; True applies pending SDN config cluster-wide.
lock_tokenNoSDN cluster lock token to use for this write, if one is held (from pve_sdn_lock_acquire).
release_lockNoWhether PVE releases the lock automatically after a successful commit (only relevant when lock_token is given; PVE's own default is True — omit to use it).
proximo_targetNoWhich configured Proxmox target to run this call against — a target name from your multi-target config (a specific PVE/PBS/PMG/PDM box). Omit to use the single/default target from the environment; the selection applies only to this call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Tool Definition Quality

A5/5.0
Behavior5/5

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

With no annotations provided, the description fully covers behavioral traits: mutation, high risk, no automatic undo, async/sync return, outcome='submitted', lock_token not written to audit ledger.

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, with clear structure: main action, prerequisites, alternatives, dry-run/apply details, lock extension note. 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's complexity (cluster-wide mutation, async, dry-run, locking), the description covers all key aspects: staging, alternatives, risk, return types, lock handling. Output schema complements return value details.

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 100%, but description adds context for each parameter: confirm's dry-run behavior, lock_token usage with lock acquisition, release_lock defaults, proximo_target for multi-target 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 it applies pending SDN config changes, specifies cluster-scoped and high-risk mutation, and distinguishes from sibling tools like pve_network_apply and pve_sdn_dry_run.

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 stage zones/vnets/subnets first with creation tools, advises using pve_network_apply for interface/bridge changes, explains dry-run default vs confirm=True execution, and mentions lock_token extension.

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/john-broadway/proximo'

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