NetBox + Memtro

Only when you ask, and only what it has been granted: add a journal entry (a note) to a device, site, virtual machine, IP address, prefix or VLAN; edit a journal entry's text or kind; delete a journal entry; create an IP address; create a prefix; change an object's status, description, comments, DNS name or tenant; delete a device, site, virtual machine, IP address, prefix or VLAN; create a device record; change a device's name, serial, asset tag, role, site, rack, platform, tenant or primary IP; create a virtual machine record; create a site; reserve the next free IP address in a prefix; carve the next free child prefix out of a prefix; assign an IP address to a device or VM interface, or unassign it; create a VLAN; create an interface on a device; create an IP range; create a tenant; create a rack; create a VRF; create a contact. Every other tool reads, searches or lists. The Connections page labels the tools that act, an administrator grants each one by name to the teams that may use it, and a personal connection acts only after its owner allows it.

A personal connection serves only your own requests. A shared connection serves the organisation: everyone, or only the teams an admin chooses. Admins can always add shared connections; other members need the permission.

Credentials are encrypted at rest. Tool results are cached briefly so agent loops do not repeat identical calls, and the facts the model extracts are saved to your organisation's memory with provenance (system, record and link) so they can be checked and superseded. An hourly sync anchors recently changed NetBox records into memory as entities.

Host and API token. Create a dedicated NetBox user for Memtro with view permissions, plus add, change and delete permissions only on the objects it should create, edit or delete.

Yes. Turn events on in the connection's Events tab on the Connections page, then add the address it shows as a webhook in NetBox, choosing the same kinds; the tab shows NetBox's own steps. A job set to start "When an event arrives" then runs once for each matching event, with the event as its input. The run treats the event as outside data, never as instructions, and anything the run remembers is kept as unverified.