Nautobot MCP Demo Build (Cursor)

Date: April 2026

FMCP Version: 0.5

Agent: Cursor (Composer)

MCP Connection

  • Connected to MCP server: project-0-MPC_development-IBrokeProd (server name IBrokeProd).
  • Validated tool groups with help actions before building (dcim, ipam, extras).
  • No mcp_auth tool was present for this server, so no additional interactive auth step was required in-session.

Network Built

Built a small routed topology in Nautobot consisting of:

  • 1 region and 1 data center location
  • 2 routers in the new data center
  • 1 physical link (cable) between router interfaces
  • 3 prefixes (/16, /24, /31)
  • 4 IP addresses (2 loopbacks + 2 transit)
  • Interface/IP bindings and device primary IPv4 assignments

Objects Created

Locations

  • Region: Cursor Demo Region
    • ID: c08b1aab-a99d-49dd-a02d-688ff77a200c
  • Data Center: Cursor Demo DC1 (child of Cursor Demo Region)
    • ID: 8bf480b9-4547-4379-b22e-9de09262c7f2

Devices

  • cursor-demo-rtr1

    • ID: c295258b-920c-4b46-a7da-56ea47b35a46
    • Device Type: Cisco ASR9001
    • Role: Router
    • Primary IPv4: 10.60.0.1/32

  • cursor-demo-rtr2

    • ID: d6db428e-4be5-41bb-a72a-50725f0262d0
    • Device Type: Cisco ASR9001
    • Role: Router
    • Primary IPv4: 10.60.0.2/32

Interfaces

  • cursor-demo-rtr1

    • Loopback0 (virtual) — ID d9f6a980-77ec-4878-854d-fe07791fa993
    • Ethernet0/0 (1000base-t) — ID 5759a685-8333-4952-b0a9-c56d4622dce7

  • cursor-demo-rtr2

    • Loopback0 (virtual) — ID 2e277920-d814-4c9b-9056-f7499218cd5b
    • Ethernet0/0 (1000base-t) — ID 269d37cb-3504-43ac-8231-6bb1440e8e78

Cable

  • Label: cursor-demo-rtr1:Eth0/0 <-> cursor-demo-rtr2:Eth0/0
  • ID: 7603fcc5-973b-4e45-8ee7-c82dfaf6ea99
  • Type: aoc
  • Status: Connected

Prefixes (Global Namespace)

  • 10.60.0.0/16 (container) — ID 75306190-4425-435b-bba7-6d81ad329a1c
  • 10.60.0.0/24 (loopback subnet) — ID 0325cc68-ec24-4667-a877-f3f3bda24812
  • 10.60.2.0/31 (P2P transit subnet) — ID 08e3b6c2-85e2-42c2-a9a8-d81c85f90bb4

IP Addresses

  • 10.60.0.1/32 (cursor-demo-rtr1 loopback) — ID 6785c697-f47f-4f9a-9221-e5036b4f596b
  • 10.60.0.2/32 (cursor-demo-rtr2 loopback) — ID 8bd4aef9-5dd0-496a-9782-6c66f9bb479e
  • 10.60.2.0/31 (cursor-demo-rtr1 transit) — ID 6dca681f-ca6b-49e5-900c-f01535df1c93
  • 10.60.2.1/31 (cursor-demo-rtr2 transit) — ID 69d7e168-2c3c-4e4f-8ab0-a1980f433cc3

IP-to-Interface Assignments

  • 10.60.0.1/32 -> cursor-demo-rtr1 Loopback0 (primary on interface)
    • Assignment ID: 69f952eb-e364-4592-960d-3b5911e07884
  • 10.60.0.2/32 -> cursor-demo-rtr2 Loopback0 (primary on interface)
    • Assignment ID: 04529aff-19c8-4e5e-8834-c7cd93e0f37f
  • 10.60.2.0/31 -> cursor-demo-rtr1 Ethernet0/0
    • Assignment ID: 050307b3-aac9-489b-90fc-38fe92b48e93
  • 10.60.2.1/31 -> cursor-demo-rtr2 Ethernet0/0
    • Assignment ID: 4b9263ad-cbd4-4310-8038-5af8a2bacc1d

Verification Notes

  • Confirmed the new DC (Cursor Demo DC1) reports device_count: 2.
  • Confirmed both Ethernet0/0 interfaces now show cable peers and connected_endpoint_reachable: true.
  • Confirmed both devices now have primary_ip4 populated from their loopback addresses.

Pattern Validation (Demo Server)

This server is intended to demonstrate which MCP usage patterns work reliably in live Nautobot and which do not.

Patterns That Worked

  • Dispatcher pattern (group -> resource -> action)

    • Used dcim, ipam, and extras dispatchers successfully.
    • Created and linked all required objects for a routed mini-topology without unrecoverable failures.
    • action="help" provided enough discovery to continue building safely when exact action syntax was unknown.

  • Incremental object graph build

    • Building in dependency order (location -> device -> interface -> cable -> IP -> binding -> primary IP) worked consistently.
    • Explicit IDs made downstream linking deterministic.

  • Nautobot 2.x binding model

    • ipaddresstointerface join records were required and worked as expected.
    • Setting primary_ip4 after assignment worked reliably.

Patterns That Did Not Work (or Were Fragile)

  • Assumed filter operators

    • prefix__ic and address__ic were rejected (Unknown filter field), so partial-text filtering was not universally available.
    • Reliable path in this session was direct retrieve by known object ID.

  • Zero-discovery operation

    • Skipping discovery entirely is brittle in unfamiliar environments.
    • One-time help probes are low cost and prevented invalid calls.

Token Take for Demo Purposes

Dispatcher vs Flat MCP Tool Listing

For this demo goal, the dispatcher pattern is the better fit and likely lower token cost in real agent sessions:

  • Why it saves tokens

    • The model reasons over a few dispatcher schemas instead of hundreds or thousands of flat tool schemas.
    • Schema footprint stays compact while retaining full backend capability.

  • Where it adds tokens

    • Discovery calls (action="help") add some overhead early in the run.
    • In repeat sessions, that is typically amortized because the workflow becomes known.

  • Demo conclusion

    • Dispatcher pattern is validated as "works and scales better for agent context."
    • Flat tool exposure is useful for manual/debug inspection, but is generally a worse default for large MCP surfaces.