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 resources
  • Nautobot:golden_config — 89 tools across 9 resources
  • Nautobot: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):

  1. NYC-RTR-01 (AS 65001) ↔ Transit Provider Alpha (AS 65002)
  2. NYC-RTR-02 (AS 65001) ↔ Transit Provider Alpha (AS 65002) [redundant]
  3. CHI-RTR-01 (AS 65003) ↔ Transit Provider Beta (AS 65004)
  4. CHI-RTR-02 (AS 65003) ↔ Transit Provider Beta (AS 65004) [redundant]
  5. DEN-RTR-01 (AS 65005) ↔ Transit Provider Gamma (AS 65006)
  6. DEN-RTR-02 (AS 65005) ↔ Transit Provider Gamma (AS 65006) [redundant]
  7. NYC-RTR-01 (AS 65001) ↔ CHI-RTR-01 (AS 65003) [iBGP inter-site]
  8. 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):

  1. NTP Configuration Compliance
  2. SNMP Security Compliance
  3. Logging Configuration Compliance

Compliance Rules (3 rules):

  1. "NTP servers must include 10.0.0.100 and 10.0.0.101"
  2. "SNMP community must not be 'public' or 'private'"
  3. "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 ✅

  1. BGP ASNs: Nautobot:bgp → autonomoussystem → list returns 6 objects
  2. Devices: 65 devices exist from Phase 1 build
  3. Circuits: 2 WAN circuits exist (BT-NYC-CHI-01, BT-CHI-DEN-01)

Post-Build Validation (If Continued)

  1. BGP Peerings: Should return 8 peering sessions
  2. DNS Zones: Should return 3 zones
  3. DNS Records: Should return ~70 records across zones
  4. Compliance Features: Should return 3 features
  5. 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)