Nautobot MCP Starfleet Infrastructure Build Report

Date: April 2026

FMCP Version: 0.5

Agent: GPT

frisian-mcp Dispatcher Pattern — Medium Themed Network Construction Session

Session Date: 2026-05-12
Environment: Nautobot MCP / frisian-mcp dispatcher surface
Theme: Star Trek / Starfleet Operations
Build Scope: Medium infrastructure build, logically separated from existing Nautobot data
Modules Used: Tenancy, DCIM, IPAM, DNS Models, BGP Models, Golden Config
Recoverable Validation Events: 12
Unrecoverable Errors: 0

Executive Summary

This session constructed a Star Trek themed medium infrastructure environment inside Nautobot using the frisian-mcp dispatcher pattern. The build was intentionally separated from the existing production-style demo network by creating a dedicated tenant, IP namespace, DNS view/zone, and named Starfleet topology objects.

The final result is a two-site Starfleet network spanning Earth Spacedock and Deep Space Nine, both nested under the Alpha Quadrant region. The build includes a full DCIM footprint with routers, firewalls, spines, leaves, and a services node; IPAM aggregation and site subnets; a DNS zone with SOA/NS/A records; BGP AS/routing-instance/address-family objects; and a Golden Config compliance feature to anchor future baseline policy.

Live Nautobot verification confirmed the tenant contains 11 devices, 2 racks, 3 prefixes, and 4 IP addresses. The DNS module contains the starfleet.example zone and four A records. BGP contains AS 65170, two routing instances, and two IPv4 unicast address-family records. Golden Config contains the Starfleet Baseline compliance feature.

No deployment or configuration-generation jobs were run. The session created inventory and intent/state records only.

Session Objectives

  1. Create a medium-sized infrastructure build using the available Nautobot modules.
  2. Make the build Star Trek themed without polluting the existing environment.
  3. Use multiple dispatcher groups: Tenancy, DCIM, IPAM, DNS, BGP, Golden Config.
  4. Validate schema discovery and error pass-through while adapting to plugin-specific field requirements.
  5. Produce a review similar to the prior large-network demo report, but scoped to this Starfleet build.

Part 1: Dispatcher Validation

Dispatchers Exercised

Dispatcher Resources Used Status
Nautobot:tenancy tenantgroup, tenant Working
Nautobot:dcim location, rack, device, platform Working
Nautobot:ipam namespace, prefix, ipaddress Working
Nautobot:dns dnsview, dnszone, nsrecord, arecord Working
Nautobot:bgp autonomoussystem, bgproutinginstance, addressfamily Working
Nautobot:golden_config compliancefeature Working with stricter rule schema

Dispatcher Behavior

The dispatcher pattern remained effective for this build. Each module exposed a compact action/resource interface while still giving access to the underlying Nautobot resources. The session repeatedly used the same pattern:

Nautobot:<group>(resource="<resource>", action="<action>", ...)

Validation errors were preserved clearly enough to resolve most schema mismatches in a single retry. Examples included:

  • DNS zone required soa_mname and filename.
  • DNS SOA responsible name required an email address, not dotted SOA mailbox syntax.
  • DNS A records required an IPAM IPAddress object, not a raw IP string.
  • BGP address families required a routing instance.
  • Golden Config compliance rules required plugin-specific config-match fields.

Part 2: Network Built

Isolation Boundary

Object Name Purpose
Tenant Group Federation Infrastructure Theme/grouping boundary
Tenant Starfleet Operations Primary logical separation boundary
IPAM Namespace starfleet-operations Independent IP namespace
DNS View starfleet-operations Independent DNS view
DNS Zone starfleet.example Starfleet forward DNS zone

The tenant was used as the primary object boundary for DCIM and IPAM. The IP namespace and DNS view provide additional logical separation for addressing and name resolution.

Location Hierarchy

Alpha Quadrant
├── Earth Spacedock
│   └── ESD-RACK-1701
└── Deep Space Nine
    └── DS9-RACK-0009

Racks

Rack Site U Height Purpose
ESD-RACK-1701 Earth Spacedock 42U Enterprise service/fabric rack
DS9-RACK-0009 Deep Space Nine 42U DS9 edge/fabric rack

Device Inventory

Site Routers Firewalls Spines Leaves Services Total
Earth Spacedock 2 1 1 2 1 7
Deep Space Nine 1 1 1 1 0 4
Total 3 2 2 3 1 11

Devices Created

Device Site Role Theme Note
esd01-core-rtr-01 Earth Spacedock Router USS Enterprise core router
esd01-core-rtr-02 Earth Spacedock Router USS Defiant secondary core
esd01-fw-01 Earth Spacedock Firewall Shield-grid perimeter firewall
esd01-spine-01 Earth Spacedock Spine Switch Vulcan logic spine
esd01-leaf-01 Earth Spacedock Leaf Switch Enterprise access leaf
esd01-leaf-02 Earth Spacedock Leaf Switch Voyager access leaf
esd01-svc-transporters-01 Earth Spacedock Server Transporter services node
ds901-core-rtr-01 Deep Space Nine Router Wormhole edge core router
ds901-fw-01 Deep Space Nine Firewall DS9 shield-grid firewall
ds901-spine-01 Deep Space Nine Spine Switch Cardassian-refit spine
ds901-leaf-01 Deep Space Nine Leaf Switch Promenade access leaf

Device Type / Platform Use

The build reused existing Nautobot hardware and platform models rather than creating new ones unnecessarily.

Platform Intended Use
IOS-XR Cisco ASR-style core routers
EOS Arista spine/leaf switching
JunOS Juniper firewall devices

Part 3: IPAM Data

Namespace

Namespace Description
starfleet-operations Dedicated IP namespace for the Starfleet build

Prefix Hierarchy

10.170.0.0/16  Starfleet Operations aggregate / NCC-1701 block
├── 10.170.1.0/24  Earth Spacedock management and services
└── 10.170.9.0/24  Deep Space Nine management and services

IP Addresses

IP Address DNS Name / Use Site
10.170.1.1/24 esd01-core-rtr-01.starfleet.example Earth Spacedock
10.170.1.10/24 ns1.starfleet.example Earth Spacedock
10.170.1.50/24 transporters.starfleet.example Earth Spacedock
10.170.9.1/24 ds901-core-rtr-01.starfleet.example Deep Space Nine

The DNS plugin required A records to reference Nautobot IPAM IPAddress objects. Supporting IP address objects were therefore created before DNS A records were added.

Part 4: DNS Data

DNS View

View Purpose
starfleet-operations Dedicated DNS view for Starfleet name resolution

DNS Zone

Zone TTL Filename SOA MNAME SOA RNAME
starfleet.example 300 db.starfleet.example ns1.starfleet.example. noc@starfleet.example

DNS Records

Type Name Target
NS starfleet.example ns1.starfleet.example.
A ns1.starfleet.example 10.170.1.10
A esd01-core-rtr-01.starfleet.example 10.170.1.1
A ds901-core-rtr-01.starfleet.example 10.170.9.1
A transporters.starfleet.example 10.170.1.50

Part 5: BGP Data

Autonomous System

AS Description
65170 Starfleet Operations private autonomous system for NCC-1701 fabric

Routing Instances

Routing Instance Device Router ID
esd01-core-rtr-01 - AS 65170 esd01-core-rtr-01 10.170.1.1
ds901-core-rtr-01 - AS 65170 ds901-core-rtr-01 10.170.9.1

Address Families

Device AFI/SAFI
esd01-core-rtr-01 ipv4_unicast
ds901-core-rtr-01 ipv4_unicast

The BGP model required address families to be scoped under routing instances, so routing instances were created first.

Part 6: Golden Config

Compliance Feature

Feature Slug Description
Starfleet Baseline starfleet-baseline Baseline compliance feature for hostname, management access, BGP AS 65170, DNS reachability, and shield-grid firewall posture

Compliance Rule Attempts

Compliance rule creation was intentionally stopped after validation showed that this Nautobot Golden Config schema requires stricter, plugin-specific rule fields. The session successfully created the compliance feature but did not create malformed compliance rules.

Observed Golden Config schema behavior:

  • The requested platform must match a valid Nautobot platform (IOS-XR, EOS, or JunOS).
  • Compliance rule config fields were not plain-text fields as initially assumed.
  • config_remediation was interpreted as a boolean.
  • The rule model expected a valid configuration match structure.

This is a good place for follow-on work once the intended Golden Config rule schema or policy templates are defined.

Part 7: Object Creation Results

Summary

Resource Type Created / Verified
Tenant groups 1
Tenants 1
Locations 3
Racks 2
Devices 11
IP namespaces 1
Prefixes 3
IP addresses 4
DNS views 1
DNS zones 1
DNS NS records 1
DNS A records 4
BGP autonomous systems 1
BGP routing instances 2
BGP address families 2
Golden Config compliance features 1

Total Created / Verified Objects

39 primary Nautobot objects were created or verified for this build, excluding implicit relationship metadata and nested foreign-key references.

Part 8: Errors Encountered & Resolutions

# Error / Validation Event Root Cause Resolution
1 Tenant group did not appear on tenant after create Field naming/model behavior differed from assumption Used tenant as authoritative separation boundary
2 DNS zone missing soa_mname Required DNS Models field Retried with SOA fields
3 DNS zone missing filename Required zone-file field Added db.starfleet.example
4 DNS SOA responsible name rejected Plugin expected email format, not dotted SOA mailbox Used noc@starfleet.example
5 DNS zone rejected UUID via wrong view field Field expected dns_view natural key Used dns_view: starfleet-operations
6 NS record missing server NS model uses server target field Retried with server
7 A record missing ip_address A model uses ip_address, not address Retried with ip_address
8 A record rejected raw IP string DNS A records bind to IPAM objects Created IPAM IP objects first
9 BGP AS filter rejected integer Dispatcher filter expected string Retried with "65170"
10 BGP address family missing routing_instance AFI/SAFI scoped under routing instance Created routing instances first
11 Golden Config platform not found Used invalid platform display name Inspected valid platforms
12 Golden Config rule config fields rejected Plugin requires specific rule schema Stopped at valid compliance feature

All errors were recoverable or safely bounded. No partial destructive operation was performed, and no deployment job was run.

Part 9: Architecture Validated

Dispatcher Pattern

This session reinforced the same core dispatcher pattern finding as the larger reference build: a compact group dispatcher lets the agent navigate a broad Nautobot surface without flooding the context window with hundreds of flat tool schemas.

For this Starfleet build, the agent used multiple modules in one flow:

tenancy → dcim → ipam → dns → bgp → golden_config

The dispatcher pattern was especially useful when plugin schemas differed from generic assumptions. The agent could call help, try a minimal object, inspect validation feedback, and retry with corrected fields.

Schema Discovery

The most useful discovery behavior came from Nautobot validation errors. Rather than hiding details, the MCP surface returned actionable messages such as:

  • required property names,
  • incorrect field types,
  • missing relationship objects,
  • invalid platform references.

This made iterative schema alignment practical.

Logical Separation

The build is separated from prior infrastructure through:

  1. Dedicated tenant: Starfleet Operations
  2. Dedicated IP namespace: starfleet-operations
  3. Dedicated DNS view: starfleet-operations
  4. Themed unique naming convention:
    • esd01-*
    • ds901-*
    • starfleet.example
    • 10.170.0.0/16

Part 10: Recommended Follow-On Work

High Priority

  1. Create Golden Config rule templates

    • Define proper compliance-rule schema payloads for IOS-XR, EOS, and JunOS.
    • Add Starfleet baseline checks for hostname, BGP AS 65170, DNS resolvers, and management ACLs.

  2. Add interfaces and IP-to-interface assignments

    • Create management interfaces for all 11 devices.
    • Bind the four IPAM addresses to the appropriate router/server interfaces.
    • Set primary IPv4 addresses on core devices where appropriate.

  3. Add physical cabling

    • Model router-to-spine and spine-to-leaf links.
    • Suggested pattern:
      • ESD dual-core to ESD spine
      • ESD spine to both leaves
      • DS9 core to DS9 spine
      • DS9 spine to DS9 leaf

Medium Priority

  1. Expand DNS

    • Add A records for all devices.
    • Add PTR records for management IPs.
    • Add TXT record for Starfleet build metadata.

  2. Complete BGP peering

    • Add peer groups.
    • Add peer endpoints.
    • Model ESD ↔ DS9 core peering.

  3. Add VRF or route-target modeling

    • Add STARFLEET-MGMT VRF.
    • Add route targets for shared services and site-local routing.

Nice to Have

  1. Add contacts / teams

    • Team: Starfleet Network Operations
    • Contact: Chief Engineer Montgomery Scott
    • Contact: Operations Officer Data

  2. Add software versions

    • IOS-XR baseline for routers
    • EOS baseline for spines/leaves
    • JunOS baseline for firewalls

  3. Add tags

    • starfleet
    • demo
    • mcp-build
    • logically-separated

Part 11: Token Savings Analysis — Dispatcher vs. Flat MCP vs. Raw API

Summary

Yes — this Starfleet build had substantial token savings by using the frisian-mcp dispatcher pattern instead of exposing Nautobot as a flat MCP tool surface. Compared with raw REST API, the dispatcher approach uses more tool-schema tokens than zero, but it avoids the agent having to manually reconstruct endpoint paths, authentication patterns, pagination, object-reference semantics, validation retries, and plugin-specific payload schemas.

The key result is that the dispatcher pattern keeps the tool schema surface small and stable while still exposing the full Nautobot model through resource/action dispatchers.

Relevant Tool Surface for This Build

The Starfleet build used the following Nautobot dispatcher groups:

Module Approx. Underlying Tools
DCIM 491
IPAM 139
Tenancy 50
DNS 130
BGP 100
Golden Config 89
Extras / statuses / roles 335
Relevant flat-tool surface 1,334 tools

The broader visible Nautobot MCP surface contained roughly 1,837 underlying tools across all dispatcher groups.

Estimated Schema Overhead

Using the same methodology as the reference Nautobot MCP demo report:

  • Dispatcher schema: approximately 180 tokens per dispatcher
  • Flat MCP schema: approximately 300 tokens per underlying tool
Access Pattern Approx. Schema Tokens Exposed Notes
frisian-mcp dispatcher, relevant modules ~1,260 7 dispatchers × ~180 tokens
Flat MCP, relevant modules only ~400,200 1,334 tools × ~300 tokens
frisian-mcp dispatcher, full visible Nautobot surface ~2,880 16 dispatchers × ~180 tokens
Flat MCP, full visible Nautobot surface ~551,100 1,837 tools × ~300 tokens
Raw REST API ~0 tool schema tokens No tool schema, but much more agent-side scaffolding

Savings Calculation

For the modules actually used in the Starfleet build:

400,200 flat-MCP schema tokens
- 1,260 dispatcher schema tokens
= 398,940 schema tokens saved

That is approximately 99.7% less schema overhead than exposing the same relevant Nautobot surface as flat MCP tools.

For the full visible Nautobot surface:

551,100 flat-MCP schema tokens
- 2,880 dispatcher schema tokens
= 548,220 schema tokens saved

That is approximately 99.5% less schema overhead than a flat MCP exposure of the full visible Nautobot surface.

Dispatcher vs. Raw API

Raw REST API has the lowest tool-schema token cost because there is no tool schema at all. That does not make it equivalent for an autonomous agent.

With raw API, the agent would need to know or reconstruct:

  • Nautobot endpoint paths such as /api/dcim/devices/ and /api/plugins/dns/dns-zones/
  • authentication headers and session handling
  • pagination and retry behavior
  • exact plugin payload fields such as dns_view, soa_mname, filename, server, and ip_address
  • object-reference semantics, such as DNS A records requiring an IPAM IPAddress object rather than a raw IP string
  • validation recovery workflows for Nautobot-specific schema errors

The dispatcher approach preserved discoverability and validation feedback while avoiding the extremely large schema footprint of flat MCP.

Practical Result

For this Starfleet build, the dispatcher system was the best operating point:

Pattern Strength Weakness
Dispatcher MCP Low schema overhead, discoverable, safe validation feedback Slight schema overhead remains
Flat MCP Direct one-tool-per-action mapping Huge schema footprint; context-window pressure
Raw API Minimal schema tokens Requires significant agent scaffolding and prior API knowledge

Conclusion: The Starfleet build saved hundreds of thousands of schema tokens versus flat MCP while remaining far more agent-friendly than raw REST API. The dispatcher pattern was not just more efficient; it made iterative, multi-module Nautobot automation practical within a single agent session.

Conclusion

The Starfleet Operations build is a successful medium-scale Nautobot MCP construction session. It demonstrates that frisian-mcp can drive multi-module Nautobot automation across inventory, addressing, DNS, BGP, and compliance-intent objects while adapting to live schema constraints.

The network is not merely a naming exercise: it has a clear topology boundary, tenant model, IPAM hierarchy, DNS zone, BGP control-plane model, and Golden Config baseline anchor. It is ready for a follow-on enrichment pass to add interfaces, cabling, IP-to-interface bindings, complete BGP peering, and executable Golden Config compliance rules.

Final status: Build complete and demo-ready as a logically separated Starfleet-themed Nautobot environment.

Appendix A: Live Object Snapshot

Category Count
Tenant devices 11
Tenant racks 2
Tenant prefixes 3
Tenant IP addresses 4
DNS zones 1
DNS A records 4
DNS NS records 1
BGP ASNs 1
BGP routing instances 2
BGP address families 2
Golden Config compliance features 1

Appendix B: Build Naming Conventions

Prefix Meaning
esd01 Earth Spacedock site
ds901 Deep Space Nine site
core-rtr Core router
fw Firewall
spine Spine switch
leaf Leaf switch
svc Service node
starfleet.example Starfleet DNS zone
10.170.0.0/16 NCC-1701 themed aggregate

Report generated from live Nautobot MCP session verification after the Starfleet build was completed.