acex-mcp

# ACE-X MCP Server A Model Context Protocol server that gives AI assistants read-only access to ACE-X: the network devices it manages, the configuration each is intended to have, and the configuration snapshots actually collected from them. It holds no data and no credentials of its own. Every tool is a call to the ACE-X API made **as the caller**, so the backend authorizes each read against that user's own permissions. ## Installation ```bash pip install acex-mcp ``` ## Tools All tools are read-only. Start with `find_nodes` — the `node_id` it returns is what every other tool takes. | Tool | What it answers | |---|---| | `find_nodes` | Which devices exist, filtered by hostname, site, region, role, vendor, OS or status | | `get_node` | One device: its identity plus the hardware it runs on | | `find_assets` | What physical hardware is in inventory, deployed or spare | | `list_sites` | Which sites exist | | `list_regions` | Which regions exist, and their sites | | `get_desired_config` | The configuration ACE-X intends a device to have, rendered as device commands | | `get_observed_config` | A configuration snapshot collected from a device — latest, at a past moment, or by id | | `get_running_config` | *Placeholder.* Explains that ACE-X cannot read a device live, and offers the newest snapshot | | `list_observed_configs` | A device's configuration history | | `diff_observed_configs` | What changed on a device between two snapshots | | `get_config_drift` | How a device differs from its intended configuration, compared per component | | `get_neighbors` | What is physically cabled to a device, per LLDP | `get_desired_config` and `get_observed_config` take a `section` argument that keeps only matching configuration blocks, so a question about one interface does not pull a three-thousand-line config into the model's context. ## Resources and prompts | Resource | Contents | |---|---| | `acex://glossary` | desired vs observed vs running, and what users mean when the…