Spaces:
Sleeping
Sleeping
File size: 7,036 Bytes
fee25bf b3d02a4 c7576e1 b3d02a4 281131b b3d02a4 281131b b3d02a4 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 | ---
title: "Overgrowth – a living digital environment"
emoji: "🌿"
colorFrom: "green"
colorTo: "gray"
sdk: "gradio"
sdk_version: "4.44.0"
app_file: "app.py"
pinned: false
---
# Overgrowth – MCP Agent for Network Reliability
**Track:** MCP in Action – Enterprise
**Hackathon:** MCP's 1st Birthday – Hosted by Anthropic & Gradio
**Tag:** `mcp-in-action-track-enterprise`
Overgrowth is a living, digitally persistent network engineer. It simulates an out-of-band (OOB) mesh with MCP tools, JSON state, and Gradio UI to plan, simulate, triage, and roll back network changes safely.
What Overgrowth simulates:
- Hardware-like OOB mesh via MCP-style tools (backups, drift, bootstrap, alerts)
- Persistent state across runs (`infra/*.json`)
- Change simulation against the Track 1 MCP server (`network-change-simulator`)
- Topology-aware risk and blast radius
- Rollback planning and troubleshooting flows
---
## High-Level Architecture
[User]
|
v
[Gradio 6 UI: Overgrowth]
|
v
[Agent Pipeline]
1. Parse free-text change request → hybrid steps (NL + JSON)
2. For each step, call MCP `simulate_network_change` (Track 1 server)
3. Blend MCP risk with topology impact (infra/topology.json)
4. Generate config-diff summaries and rollback plan
5. OOB Troubleshooting calls Overgrowth tools (backup, drift, alerts, bootstrap)
|
v
[MCP Servers / Tools]
- Track 1: `simulate_network_change`
- Overgrowth OOB tools: backups, drift, bootstrap, alerts, root-cause triage
---
## MCP Tools Used
- **External MCP server (Track 1):** `network-change-simulator` → `simulate_network_change`
- **Overgrowth OOB MCP-style tools (simulated hardware mesh):**
- `oob_get_last_backup`, `oob_perform_backup`
- `oob_detect_drift`, `oob_reset_drift_flag`
- `oob_seed_device`
- `oob_get_alerts`, `oob_add_alert`
Example Track 1 invocation (conceptual)
```
{
"tool_name": "simulate_network_change",
"arguments": {"preset_id": "leaf_tor_vlan_stage", "mode": "analysis"}
}
```
---
## User Workflow
1. Describe a change in the main textbox.
2. Click **Run Analysis** to get:
- Plan tab: Hybrid NL + JSON steps with MCP-friendly `change_type` + `preset_id`
- Risk & Topology: MCP risk plus blast radius from topology.json
- Diffs: Conceptual before/after
- Rollback: Ordered rollback plan
- Tool Calls: Transparent MCP call log
3. Open **OOB Troubleshooting** to triage a device:
- Runs backup/drift/alerts/boot checks (persistent JSON state)
- Suggests root causes, rollback safety, and next MCP simulations
---
## Configuration
### GNS3 Server Setup (Required for Build Network & Lab Management)
The "Build Network" and "Lab Management" features require a running GNS3 server. Configure the server URL using environment variables:
```bash
# Copy the example environment file
cp .env.example .env
# Edit .env and set your GNS3 server URL
GNS3_SERVER=http://your-gns3-server:3080
GNS3_PROJECT_NAME=overgrowth
```
**Note:** When running on HuggingFace Spaces, you'll need to configure these as Space secrets. For local development with a local GNS3 server, the defaults will work.
---
## How to Use
1. Open the Space.
2. Enter a change request, e.g.
“Add VLAN 120 for tenant Blue on leaf-01 and uplink it to tor-03 (staging only).”
3. Inspect Plan, Risk, Diffs, Rollback, Tool Calls.
4. If there’s an issue, go to **OOB Troubleshooting**, pick a device, describe the symptom, and run triage.
---
## Notes for Judges
- Persistent state lives in `infra/*.json` and is updated during user actions (Option C).
- OOB tools emulate a hardware-backed OOB mesh while remaining pure MCP-style JSON/state.
- Track 1 MCP server is used for real change simulation; Overgrowth augments it with reliability/triage workflows.
---
## Future Extensions
- Richer root-cause engine combining MCP results with time-series alerts
- Multi-step autonomous remediation runs
- Import real config snippets for diffs
- CI/CD hooks to gate changes before rollout
---
## What is Overgrowth?
- A living MCP-powered OOB engineer that plans changes, simulates risk, detects drift, infers root cause, and self-heals.
- Persistence lives in `infra/*.json` so the environment evolves across runs (backups, drift, alerts, bootstrap, MCP history, synapse log).
## Why this matters for enterprise networks
- Gives SRE/netops teams a pre-flight simulator + autonomous triage loop without touching production hardware.
- Blends MCP tool calls (Track 1 server) with OOB state to deliver safety, transparency, and repeatability.
- Produces audit-ready synapse logs, stability scoring, and after-action narratives.
## How Overgrowth works
- **MCP Engine:** Calls Track 1 `simulate_network_change` with structured presets from parsed NL input.
- **OOB Engine:** Backup/drift/bootstrap/alerts tools operate on persistent JSON state to mimic a hardware OOB fabric.
- **Topology Model:** `infra/topology.json` informs blast radius and role-aware amplification.
- **Reasoning Layer:** Root-cause inference fuses MCP history, alerts, drift, backup age, and topology to rank causes.
- **Recovery Engine:** Executes recommended actions (MCP sims, backup, drift reset, bootstrap, alert clear) and logs everything.
## Autonomous Root-Cause Engine (Aggressive Mode)
- Multi-signal fusion (drift + alerts + backups + topology role + last MCP predictions).
- Cascading-failure inference (leaf→TOR→core amplification).
- Predictive simulation heuristic (reasons about presets without re-running tools).
- Recovery sequencing suggestions (rollback, re-bootstrap, re-run MCP full mode, auto-backup).
## Autonomous Recovery Engine (Self-Healing Overgrowth)
- Executes recommended actions via MCP-style calls and updates state.
- Tracks health with a stability metric (drift/alerts/backup-age/MCP-risk) and reports before/after.
- Logs every decision in `infra/synapse_log.json` and displays it in the Synapse Log tab.
- Provides after-action narratives and recovery execution summaries directly in the Troubleshooting tab.
## Architecture (ASCII)
```
User → Overgrowth UI
→ OOB Engine (backup / drift / bootstrap / alerts)
→ MCP Engine (Track 1 simulate_network_change)
→ Topology Model (blast radius, roles)
→ Synapse Log (state & audit trail)
```
## Demo Script (5 steps)
1. Input a change request (e.g., VLAN add) and click **Run Analysis**.
2. Show MCP risk + topology impact in Plan/Risk tabs.
3. Go to **OOB Troubleshooting**, enter “leaf-01 flap”, run troubleshooting to see root cause + stability + actions.
4. Click **Execute Recovery Plan**; watch recovery summary/log update and stability improve.
5. Open **Synapse Log** to show the audit trail of decisions and health deltas.
## Try it live
- Open the Space, follow the demo script above, then hit **Reset Overgrowth State** to rerun deterministically.
---
Demo video: https://youtu.be/YOUR_DEMO_VIDEO
Social post: https://www.linkedin.com/posts/YOUR_POST or https://x.com/YOUR_HANDLE/status/YOUR_TWEET_ID
|