Nautobot MCP Token Efficiency & Build Validation Report

Date: May 2026

FMCP Version: 0.6

Agent: Claude.ai (Web based)

Executive Summary

This report documents practical testing of the Nautobot MCP (Model Context Protocol) tooling architecture during the construction of a multi-site infrastructure environment.

The primary objective was to evaluate whether the MCP dispatcher model materially reduces token consumption and context pressure compared to exposing the entire Nautobot API surface directly to the model.

Conclusion

The dispatcher-oriented MCP architecture produced substantial token savings, reduced cognitive/tool-selection overhead, and enabled scalable interaction with a very large Nautobot API surface.

Infrastructure Build Summary

Location Validated Device Count Status
NYC Metro Core 20 Complete
Chicago Regional DR 20 Complete
Denver Edge Campus 25 Complete

Total validated devices: 65

Validated Topology Components

  • 3 geographic locations
  • 65 validated devices
  • Bulk device creation via MCP
  • Bulk partial update operations
  • IPAM namespace and aggregate prefixes
  • Inter-site WAN circuits
  • Circuit A/Z terminations
  • WAN interface modeling
  • DCIM, IPAM, Circuits, and DNS model testing

MCP Architecture Findings

The Nautobot MCP implementation uses dispatcher-style resource grouping rather than eagerly exposing the entire API schema in-context.

This architecture dramatically reduces token usage and improves tool-selection precision.

Token Efficiency Analysis

Exposure Strategy Estimated Context Size Operational Impact
Full flat Nautobot schema exposure 40k–100k+ tokens High context pressure, poor scaling
Dispatcher-only exposure 1k–4k tokens Efficient discovery and routing
Single domain dispatcher (DCIM) 500–2k tokens Task-focused operation
Direct expanded DNS models 15k–30k+ tokens High discoverability, larger prompt cost

DCIM Dispatcher Example

The DCIM dispatcher exposed a lightweight routing layer instead of hundreds of fully expanded tool definitions.

During testing, the dispatcher represented approximately:

  • 491 operations
  • Across 53 resources

while requiring only a minimal dispatcher schema in-context.

Estimated Savings

Approximately 200×–500× reduction in schema/token footprint compared to fully exposing every DCIM operation individually.

Observed Benefits

  • Schema locality: only relevant domains loaded into context
  • Reduced tool-selection entropy
  • Lower prompt and reasoning overhead
  • Improved scalability for large API surfaces
  • Reduced hallucinated cross-domain calls
  • Faster operational iteration during long builds

DNS Model Exposure Findings

The refreshed Nautobot MCP server exposed DNS models directly, including:

  • DNS views
  • DNS zones
  • A/AAAA records
  • CNAME records
  • MX records
  • PTR records
  • SRV records
  • TXT records
  • Bulk DNS operations

Direct DNS exposure increased immediate discoverability but materially increased schema size.

This provided a useful contrast against the dispatcher-based DCIM implementation.

Bulk Operation Validation

Validated successfully:

  • Bulk create using action=create with objects[]
  • 10-device bulk creation batches
  • bulk_partial_update
  • Device list and retrieval operations
  • Circuit operations
  • IPAM operations
  • DNS model operations

Important Discovery

The legacy bulk_create path was identified as UI-oriented and unsuitable.

The correct bulk-create pattern is:

{
  "resource": "device",
  "action": "create",
  "objects": [
    { "...device payload..." }
  ]
}

Operational Caveats

  • Connector path rotation requires refresh/discovery handling
  • Authentication expiry can interrupt long-running builds
  • Some naming patterns triggered upstream request mediation
  • Large-scale interface/cable modeling remains a future scale test
  • Larger batch sizes (>10 objects) remain untested

Recommendations

  • Use dispatcher-style grouping for large API domains by default
  • Expand schemas lazily only when needed
  • Retain direct model exposure for focused debugging and testing
  • Add automatic connector rediscovery handling in clients
  • Test larger batch sizes and partial-failure semantics
  • Continue expanding DNS, BGP, VPN, and interface-scale validation

Final Assessment

The Nautobot MCP implementation demonstrated that dispatcher-oriented API exposure is a practical and highly effective method for reducing token consumption while preserving deep operational capability.

The architecture allowed a realistic 65-device multi-site environment to be built and validated without requiring the entire Nautobot API surface to be injected into model context simultaneously.