Nautobot Plugin Dataset Build Summary
Date: May 2026
FMCP Version: 0.6
Agent: Claude.ai (Web based)
Session Date: 2026-05-06
Status: MCP Validation Complete; Foundational BGP Data Created
What Was Completed
1. MCP Plugin Dispatcher Validation ✅
Tested Dispatchers:
Nautobot:bgp— 100 tools across 10 resourcesNautobot:golden_config— 89 tools across 9 resourcesNautobot:approvalworkflow— 53 tools across 7 resources
Result: All dispatchers respond correctly to action=help and expose full resource trees. frisian-mcp dispatcher pattern working as designed for Nautobot plugins.
2. BGP Autonomous Systems Created (6 ASNs) ✅
| ASN | Description | Purpose | UUID |
|---|---|---|---|
| 65001 | BuildTask Enterprise - NYC Metro Region | Enterprise network NYC | b0e5b9c9-6e88-4c76-8897-676b5ea6ab0b |
| 65002 | Transit Provider Alpha - NYC Uplink | External transit NYC | e71837d5-7d7e-45e3-9761-14be762b37c5 |
| 65003 | BuildTask Enterprise - Chicago DR Region | Enterprise network Chicago | 0b2722b5-a030-4ca4-93b7-33153ba31aa1 |
| 65004 | Transit Provider Beta - Chicago Uplink | External transit Chicago | 4470ca72-d068-449e-b28c-19022dcd8948 |
| 65005 | BuildTask Enterprise - Denver Edge Region | Enterprise network Denver | 11dd192d-8f11-4f48-8675-7a273d04e7df |
| 65006 | Transit Provider Gamma - Denver Uplink | External transit Denver | 42c113bd-beb6-4f44-9c81-74ca91e24a96 |
Topology Design:
- 3 enterprise ASNs (one per location)
- 3 transit provider ASNs (one per location for uplink)
- Designed to support: eBGP peering to transit providers + iBGP between enterprise sites
3. Router Device IDs Retrieved (6 routers) ✅
| Router | Device UUID | Location | Purpose |
|---|---|---|---|
| nyc-rtr-01 | c1b90e8c-dbe3-4905-bedd-e66738280a35 |
NYC Metro Core | Primary NYC edge router |
| nyc-rtr-02 | bb543e36-8db6-486d-b5b8-f8fc08794709 |
NYC Metro Core | Redundant NYC edge router |
| chi-rtr-01 | a98bd58b-100e-48fb-b424-8e79148d8ca5 |
Chicago Regional DR | Primary Chicago edge router |
| chi-rtr-02 | a159d3f1-0574-4b9b-8bf4-2e663050c233 |
Chicago Regional DR | Redundant Chicago edge router |
| den-rtr-01 | 0e6473bc-2393-4f84-88b0-507daf2bba95 |
Denver Edge Campus | Primary Denver edge router |
| den-rtr-02 | 86e98d1d-5a47-4bde-916b-7d09869da973 |
Denver Edge Campus | Redundant Denver edge router |
Remaining Build Tasks (If Desired)
Phase 1: BGP Routing Instances & Peering (~15-20 min)
Routing Instances to Create (6 total):
- One BGP routing instance per router linking router device to its ASN
Peer Endpoints to Create (12 total):
- 2 peer endpoints per router (one for eBGP to transit, one for iBGP inter-site)
Peering Sessions to Create (8 total):
- NYC-RTR-01 (AS 65001) ↔ Transit Provider Alpha (AS 65002)
- NYC-RTR-02 (AS 65001) ↔ Transit Provider Alpha (AS 65002) [redundant]
- CHI-RTR-01 (AS 65003) ↔ Transit Provider Beta (AS 65004)
- CHI-RTR-02 (AS 65003) ↔ Transit Provider Beta (AS 65004) [redundant]
- DEN-RTR-01 (AS 65005) ↔ Transit Provider Gamma (AS 65006)
- DEN-RTR-02 (AS 65005) ↔ Transit Provider Gamma (AS 65006) [redundant]
- NYC-RTR-01 (AS 65001) ↔ CHI-RTR-01 (AS 65003) [iBGP inter-site]
- CHI-RTR-01 (AS 65003) ↔ DEN-RTR-01 (AS 65005) [iBGP inter-site]
Phase 2: DNS Models Data (~10-15 min)
Note: DNS Models dispatcher was not loaded in this session. Would require:
tool_search(query="nautobot dns zone record")
Proposed Dataset:
- 3 DNS Zones: buildtask.local, nyc.buildtask.local, chi.buildtask.local
- ~70 DNS Records:
- NS records for zone delegation
- A/AAAA records for routers and switches
- CNAME records for service aliases
- PTR records for reverse lookup
- MX records for mail routing
Phase 3: Golden Config Compliance (~10 min)
Compliance Features (3 features):
- NTP Configuration Compliance
- SNMP Security Compliance
- Logging Configuration Compliance
Compliance Rules (3 rules):
- "NTP servers must include 10.0.0.100 and 10.0.0.101"
- "SNMP community must not be 'public' or 'private'"
- "Logging host must be 10.0.0.200"
Golden Config Settings:
- Scope: All routers + core switches
- Backup repository: Git reference
- Intended config source: Jinja2 templates
Estimated Full Build Time
If executed via MCP API (current approach):
- BGP Phase: ~15-20 minutes (20 objects with pauses)
- DNS Phase: ~10-15 minutes (73 objects with pauses)
- Golden Config Phase: ~10 minutes (7 objects)
- Total: ~40-50 minutes
Alternative Approach (Faster):
- Python script using Nautobot pynautobot SDK with batch operations
- Total: ~10-15 minutes
Validation Strategy
Current State Validation ✅
- BGP ASNs:
Nautobot:bgp → autonomoussystem → listreturns 6 objects - Devices: 65 devices exist from Phase 1 build
- Circuits: 2 WAN circuits exist (BT-NYC-CHI-01, BT-CHI-DEN-01)
Post-Build Validation (If Continued)
- BGP Peerings: Should return 8 peering sessions
- DNS Zones: Should return 3 zones
- DNS Records: Should return ~70 records across zones
- Compliance Features: Should return 3 features
- Compliance Rules: Should return 3 rules
Key Findings
MCP Dispatcher Performance
- No issues at scale: BGP dispatcher handles 100 tools across 10 resources without token bloat
- Golden Config dispatcher: 89 tools across 9 resources; all resources discovered correctly
- frisian-mcp validation: Dispatcher pattern confirmed working for Nautobot plugin data
Server Performance (T3.medium)
- ASN creation rate: ~5 seconds per object (includes validation + ORM)
- No API throttling observed: 6 consecutive creates completed without errors
- Server stable: No 5xx errors or memory warnings during testing
Time Estimate Accuracy
- Original estimate: 6 hours for infrastructure build (65 devices + circuits)
- Plugin data estimate: 40-50 minutes for 100 objects (BGP + DNS + Golden Config)
- Ratio: Plugin data is ~5x faster per object (simpler object graphs, fewer FK dependencies)
Recommendations
If Time-Constrained
Priority 1 (Completed): BGP ASNs created — demonstrates BGP Models plugin integration ✅
Priority 2 (Quick win): Create 3-5 DNS zones to demonstrate DNS Models plugin (~5 min)
Priority 3 (Optional): Full BGP peering topology (demonstrates complex relationships)
If Building Full Dataset
Recommended approach: Python script with pynautobot SDK
- Faster than sequential MCP API calls
- Better error handling for batch operations
- Can leverage Nautobot's bulk create where supported
Status UUID Reference
All objects use Nautobot's "Active" status:
UUID: 572a2178-3e95-4b39-8353-e37b48d915ef
Build Session End: 2026-05-06 21:40 UTC
Environment: Nautobot on T3.medium via frisian-mcp
Session Duration: ~15 minutes (MCP validation + 6 ASN creates)