You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Add packaging and deployment: Dockerfile, publish workflows, install docs
- Dockerfile (stdio MCP server, non-root) + .dockerignore
- docker-publish workflow to GHCR on version tags
- PyPI trusted-publishing workflow on release
- README: install (pipx/clone/Docker), env reference, and MCP client
config (command- and Docker-based)
Verified: image builds, runs vymcp as a stdio MCP server (initialize +
tools/list handshake), and reaches VyManager over the network.
* Trim README to the essentials
---------
Co-authored-by: xTITUSMAXIMUSX <chevlle_hottrod_09@hotmail.com>
> Model Context Protocol (MCP) server for VyOS routers, powered by [VyManager](https://github.com/Community-VyProjects/VyManager).
5
+
> MCP server for VyOS routers, powered by [VyManager](https://github.com/Community-VyProjects/VyManager).
6
6
7
-
VyMCP lets AI agents and MCP-aware tools (Claude, IDEs, automation) **read and manage VyOS routers** through a safe, audited interface. Rather than talking to routers directly, VyMCP wraps the VyManager API — so every action inherits VyManager's per-user authentication, role-based access control, audit logging, and version-aware (VyOS 1.4 / 1.5) configuration handling.
7
+
VyMCP lets AI agents read and manage VyOS routers through the VyManager API — inheriting VyManager's authentication, RBAC, audit, and commit-confirm safety. It never talks to routers directly.
8
8
9
-
> **Status: alpha.**Read tools cover every VyManager feature; guarded write tools cover ~86 features through a generic, discovery-driven proposer (plus curated firewall-group tools). The transport is stdio today (hosted HTTP/SSE is planned). Interfaces may still change.
9
+
> **Status: alpha.**stdio transport; interfaces may change.
10
10
11
-
---
11
+
## Install
12
12
13
-
## Why a server, not a direct integration
14
-
15
-
VyMCP deliberately **does not** connect to VyOS devices itself. It is a thin, stateless translation layer in front of VyManager's REST API. This keeps a single, enforced source of truth for everything that matters in an enterprise environment:
16
-
17
-
-**Per-user identity** — a VyMCP request acts as a real VyManager user, never a shared service account.
18
-
-**RBAC** — a token can never exceed its owner's permissions.
19
-
-**Audit** — every configuration change is attributed to the user, token, and instance.
VyMCP authenticates to VyManager with a **personal access token** that a user mints in the VyManager UI (Sites → API Tokens). Tokens are least-privilege by design:
40
-
41
-
-**Read-only scope** — a token can be restricted so it can never make configuration changes.
42
-
-**Instance/site scoping** — a token can be limited to specific routers or sites (always within the user's own grants).
43
-
-**Per-call targeting** — the target router is selected per request via the instance the token is allowed to reach.
44
-
45
-
This means you can hand VyMCP a token that, for example, can only *read* a single production router — and that limit is enforced by VyManager, not by VyMCP.
46
-
47
-
## Tools
48
-
49
-
**Read (always available):**
50
-
51
-
| Tool | Purpose |
52
-
|---|---|
53
-
|`list_instances`| The instances this token can reach (returns `instance_id`s for the other tools). |
54
-
|`list_features`| Every VyOS feature VyMCP can read. |
55
-
|`get_capabilities(feature, instance_id)`| Version-aware capability flags for a feature. |
56
-
|`get_config(feature, instance_id)`| Normalized configuration for a feature. |
57
-
58
-
**Write (only when `VYMANAGER_ENABLE_WRITES=true`):** changes go through a mandatory
59
-
**propose → apply** flow — a `propose_*` tool validates and returns a `plan_id` without
60
-
touching anything, then `apply_change(plan_id, confirm=true)` executes that one reviewed
61
-
plan. Plans are single-use, time-limited, and bound to their target instance.
62
-
63
-
| Tool | Purpose |
64
-
|---|---|
65
-
|`describe_feature_operations(feature)`| The operations available for a feature (op names, arg counts, descriptions, and any required top-level/subject fields). |
66
-
|`propose_operations(feature, instance_id, operations, fields)`| Generic proposer — build a change for **~86 features** from the discovered vocabulary (no effect until applied). |
67
-
|`propose_create_address_group` / `propose_add_address_group_members` / `propose_remove_address_group_members` / `propose_delete_address_group`| Curated firewall address-group proposers (nicer ergonomics for a common case). |
68
-
|`apply_change(plan_id, confirm)`| Apply a proposed plan, protected by VyManager's commit-confirm when available. |
69
-
|`confirm_change(instance_id)`| Keep a pending commit-confirm change (settles the device, stops the rollback). |
70
-
|`discard_changes(instance_id)`| Drop unsaved changes — only when no commit-confirm is pending. |
71
-
|`get_pending_changes(instance_id)`| Show the commit-confirm rollback window and any pending change. |
72
-
73
-
`propose_operations` covers every feature whose batch handler dispatches uniformly — the routing, firewall, NAT, service, VPN, system surface plus interface sub-types. A few features with bespoke handlers (`route`, bridge firewall, `ethernet`) are intentionally **not** exposed generically, because their custom per-op wiring can't be driven safely by introspection alone; manage those in the VyManager UI.
74
-
75
-
### Guardrails
17
+
Or `pip install .` from a clone, or run the Docker image `ghcr.io/community-vyprojects/vymcp` (attached, with `-i`).
76
18
77
-
-**Read-only by default** — write tools are not even registered unless `VYMANAGER_ENABLE_WRITES=true`, on top of the token's own read-only scope (a read-only token is rejected by VyManager regardless).
78
-
-**Vocabulary-bound, not arbitrary** — `propose_operations` only accepts operations that exist in the feature's discovered vocabulary (validated against VyManager's own contract); there is no "set any path" tool.
79
-
-**Propose → apply** — `apply_change` requires `confirm=true` and a valid plan id, so the model can only apply a change a human has seen.
80
-
-**Never auto-confirms** — applied changes ride VyManager's commit-confirm timer. That timer is a *lockout safety net*: if a change cuts off access to the router, the device auto-reverts (reboots) and you regain access. To keep a change, call `confirm_change`; to undo one that didn't lock you out, `confirm_change` then apply the inverse change.
19
+
## Configure
81
20
82
-
## Requirements
21
+
Set environment variables (see `.env.example`):
83
22
84
-
- A reachable [VyManager](https://github.com/Community-VyProjects/VyManager) instance.
85
-
- A VyManager API token (Sites → API Tokens; read-only recommended to start).
86
-
- One or more VyOS 1.4 / 1.5 routers registered in VyManager.
87
-
- Python 3.10+.
23
+
| Variable | Required | Purpose |
24
+
|---|---|---|
25
+
|`VYMANAGER_BASE_URL`| yes | VyManager API URL |
26
+
|`VYMANAGER_API_TOKEN`| yes | A `vym_` token (Sites → API Tokens; read-only recommended) |
27
+
|`VYMANAGER_ENABLE_WRITES`| no | Enable write tools (default off) |
88
28
89
-
## Getting started
29
+
`VYMANAGER_VERIFY_SSL` (default `true`) and `VYMANAGER_TIMEOUT` (default `30`) are optional.
-**Write** (only when `VYMANAGER_ENABLE_WRITES=true`): `describe_feature_operations` + `propose_operations` cover ~86 features; `apply_change` / `confirm_change` / `discard_changes` / `get_pending_changes` drive the rollout.
51
+
52
+
Writes are safe by design: off by default, capped to the token's scope, and gated by a **propose → apply** flow. `apply_change` requires explicit confirmation and rides VyManager's commit-confirm auto-rollback (a lockout safety net) — it never auto-confirms.
0 commit comments