io.github.shigechika/junos-mcp

push_config

Push Junos set commands or .set/.j2 config files safely with a dry-run diff, commit confirmed, and automatic rollback if the post-commit health check fails.

Instructions

Push configuration to a device with commit confirmed and health check.

Supports two input methods (exactly one required):

config_file: Path to a .set or .j2 file containing set commands
set_commands: List of set command strings (inline)

Safety features (not available in Juniper's official MCP server):

dry_run mode (default True): shows diff without committing
commit confirmed: auto-rollback if not confirmed within timeout
health check: auto-rollback on connectivity failure after commit

Commit flow (normal): lock -> load -> diff -> commit_check -> commit confirmed -> health check -> confirm -> unlock

Commit flow (no_commit=True — intentional auto-rollback): lock -> load -> diff -> commit_check -> commit confirmed -> unlock (health check and final confirm are skipped; JUNOS rolls back automatically after confirm_timeout minutes)

RPC timeout: every step uses timeout from config.ini for the host, else the model default from junos-ops (180 s on SRX branch models such as SRX300/320/340/345, whose commits can exceed 30 s; 120 s otherwise). It is never shortened.

Per-call deadline: with JUNOS_DEADLINE set (default 45 s; 0 disables) the push runs as a background job and this call waits for it until shortly before the deadline. If it finishes, the answer is the same as without a deadline. If not, the answer says "Still running" with a job_id: poll push_config_result(job_id) for the outcome (the device-side commit confirmed protects a push whose caller went away). For hosted clients that cut a tool call at about 60 s and for slow-committing models, push_config_start returns the diff and the job id without waiting.

Only one push per host runs at a time; a second one is refused. While a push holds a host, other tools on that host wait at most until the deadline and then answer "host busy".

Args: hostname: Target device hostname (must exist in config.ini) config_file: Path to .set or .j2 file (mutually exclusive with set_commands) set_commands: List of set commands (mutually exclusive with config_file) dry_run: If True (default), show diff only without committing confirm_timeout: Minutes before auto-rollback (default 1, used with commit confirmed) no_commit: If True, issue commit confirmed but intentionally skip the final commit so JUNOS auto-rolls back after confirm_timeout minutes. Useful for triggering service restarts (e.g. syslog on EX3400) where no request ...restart command exists. dry_run=True takes precedence over no_commit (diff is shown but nothing is committed). health_check: Fallback health check commands tried in order after commit. Passes if ANY command succeeds. Supports "ping ..." (checks packets received), "uptime" (NETCONF RPC probe), or any CLI command (success if no exception). Default: ["uptime"] — uses the existing NETCONF session and does not depend on ICMP reachability. (Changed from broadcast ping in junos-mcp 0.11.0 to match junos-ops 0.16.8+.) Ignored when no_commit=True. config_path: Path to config.ini (empty string uses default search)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "hostname": "<hostname>"
    },
    "name": "push_config"
  }
}

Input Schema

Name	Required	Description	Default
`dry_run`	No
`hostname`	Yes
`no_commit`	No
`config_file`	No
`config_path`	No
`health_check`	No
`set_commands`	No
`confirm_timeout`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.16.2Jul 28, 2026
Removedv0.16.1Jul 27, 2026
First observedv0.1.0May 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it spells out the lock/load/diff/commit-check/commit-confirmed/health-check/confirm/unlock flow, the auto-rollback guarantee if the caller disappears, RPC timeouts per model, the JUNOS_DEADLINE background-job behaviour, and the per-host concurrency lock. This is exactly the mutation-safety context an agent needs.

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 front-loaded with headings and a flow diagram, and the most decision-critical facts (exactly one input method, dry_run default True) come first. It is, however, quite long and partly self-repeating — dry_run and no_commit are each explained in both the flow section and the Args block, and the timeout paragraph is dense.

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 a destructive 8-param push with no annotations, everything an agent needs is present: prerequisites (hostname must exist in config.ini), precedence rules, rollback behaviour, timeout/job behaviour, and concurrency limits. An output schema exists, so return-value detail is correctly not duplicated.

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 compensate and it does for all 8 params: mutual exclusivity of config_file vs set_commands ('exactly one required'), dry_run precedence over no_commit, health_check fallback ordering and 'passes if ANY command succeeds', ignored when no_commit=True, and config_path search semantics.

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

Purpose5/5

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

States a concrete verb+resource ('Push configuration to a device') and immediately names the mechanisms that shape the operation (commit confirmed, health check). It also clearly separates itself from push_config_start, which 'returns the diff and the job id without waiting', so an agent can pick between them without opening either schema.

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 throughout: dry_run default True for diff-only, no_commit for intentional auto-rollback (with the syslog/EX3400 example), push_config_start for hosted clients that cut calls at ~60 s, confirm_timeout for rollback windows. It also states a real exclusion — only one push per host at a time, and other tools get 'host busy'.

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