Nautobot Plugin Dataset Build Summary

Note on tool/endpoint counts. Totals in these Nautobot records vary by installed plugin set, which dispatcher routes were exposed, and whether the figure counts tools or resources. They are snapshots of one configuration, not a fixed property of Nautobot. See Nautobot Endpoint Counts Explained before treating a difference as a contradiction.

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)