The API-First Infrastructure: How 305 Tools Changed How I Manage a Network

Last week, I typed “show me all devices in the management VLAN with their current monitoring status” into my terminal. Two seconds later, I had a formatted report combining data from my IPAM system, network controller, and monitoring platform. No dashboard to load, no API documentation to reference, no Python script to write. Just a question in plain English.

This is what happens when you expose 305 infrastructure management tools through a unified interface.

The API-First Principle

I’ve spent three decades in IT leadership roles, and one pattern has emerged across every successful infrastructure project: if it doesn’t have an API, it becomes a bottleneck. The best systems expose their functionality programmatically. The worst require human operators to click through web interfaces for every change.

But here’s the problem we’re solving in 2026: having APIs isn’t enough anymore. Modern infrastructure platforms expose hundreds or thousands of API endpoints. NetBox has over 200. Proxmox has dozens. UniFi’s controller API is massive. The cognitive overhead of remembering how to structure an API call to “assign this IP to that interface in NetBox” is real work.

Enter the Model Context Protocol. MCP is a standardized way to expose tools through discoverable, schema-validated interfaces. Think of it as a universal adapter between natural language and APIs. Instead of memorizing curl commands or writing integration scripts, you describe what you want in plain English, and the platform figures out which API calls to make.

Seven Systems, One Interface

Over the past few months, I built seven custom API servers for my lab infrastructure. Each one wraps a critical platform API and exposes it as discoverable tools:

• NetBox API Server (80 tools) – Complete IPAM and DCIM management. Devices, IP addresses, VLANs, interfaces, prefixes, custom fields, configuration contexts.
• UniFi API Server (50 tools) – Network device management. Client tracking, device control, WLAN configuration, port profiles, firewall rules, DPI statistics.
• Proxmox API Server (40 tools) – Virtualization platform control. VM lifecycle management, container operations, snapshots, cluster resources, storage.
• MediaWiki API Server (45 tools) – Documentation system integration. Page creation and editing, category management, templates, search, project tracking.
• SSH Gateway (30 tools) – Remote execution across infrastructure. Command execution, file operations, Docker management, systemd service control.
• Vaultwarden API Server (9 tools) – Credential management and secrets. Password retrieval, API token storage, SSH credential handling.
• pfSense API Server (51 tools) – Firewall and routing management. Firewall rules, NAT configuration, VPN management, DHCP/DNS, interface control.

That’s 305 discrete capabilities, all accessible through a single conversational interface.

What 305 Tools Actually Means

The number sounds impressive, but the real power is in composition. Individual tools are building blocks. The platform chains them together to handle complex multi-system operations that would traditionally require custom integration code.

Here’s a real example. I needed to deploy a new monitoring server. The traditional workflow: log into Proxmox, clone a template, configure resources, start the VM, switch to NetBox, create a device record, assign IPs, update custom fields, open MediaWiki, add documentation, SSH in to configure the agent, update firewall rules. Twelve manual steps across five web interfaces.

With the API infrastructure, I described what I needed in one sentence. The platform orchestrated the entire process: called the Proxmox API to clone and configure the VM, used the NetBox API to create the device record and assign interfaces, used the SSH gateway to configure the system, invoked the MediaWiki API to create documentation.

Instead of twelve manual steps, it was one request. More importantly, the documentation was created automatically and stays synchronized with the actual infrastructure state.

The Operational Reality Check

The industry talks a lot about “agentic AI” , systems that can take action on your behalf, not just answer questions. Most of what you see in marketing is vaporware or demos that fall apart under real-world conditions.

What I built actually works in production, and I can tell you why: it’s built on a foundation of well-designed APIs and standardized tool discovery. The AI component is important, but it’s not the differentiator. The infrastructure underneath it is.

The Model Context Protocol gives the platform three critical capabilities:

1. Dynamic tool discovery – The platform queries each API server to learn what tools are available and how to use them.
2. JSON schema validation – Every tool has a well-defined schema for its inputs and outputs.
3. Composable operations – Tools can be chained together. The output from a NetBox query can feed into a Proxmox operation.

This isn’t magic. It’s good API design meeting capable automation.

Security and the Credential Problem

Let’s address the elephant in the room: exposing 305 infrastructure management tools through any interface is a security consideration.

This is why the Vaultwarden API server exists. Every credential, API token, and SSH key lives in the password vault. When the NetBox API server needs to authenticate, it calls the Vaultwarden API to retrieve the token. No credentials are hardcoded in configuration files or environment variables.

The API servers run as local processes, not cloud services. The platform runs on my infrastructure, communicates with API servers over stdio, and never sends credentials or sensitive data outside my network.

What This Means for IT Operations

I’ve been a CIO and VP of IT. I’ve built and led operations teams. This approach fundamentally changes what’s possible with small teams.

The traditional operations model requires specialists for every platform. With an API-first infrastructure, the platform becomes a universal operator. It doesn’t replace human expertise, but it dramatically lowers the barrier to cross-system operations.

This is infrastructure-as-code’s logical evolution: infrastructure-as-conversation.

The Pattern Others Can Follow

API servers built on MCP are straightforward to create. If you have a system with a REST API, you can wrap it as an API server in a few hundred lines of Python. The pattern is consistent:

1. Identify the API endpoints you actually use
2. Define tools with clear JSON schemas for inputs/outputs
3. Handle authentication (preferably via credential management)
4. Implement error handling and validation
5. Register the server with your operations platform

Start small. Pick your most-used system and wrap the five operations you do most frequently. You’ll immediately see the value. Then expand from there.

Where This Goes Next

The next evolution is proactive operations. Right now, I request actions and the platform executes them. The infrastructure exists for the platform to monitor state and take corrective actions proactively: detect new devices, flag anomalies, suggest optimizations.

But I’d want governance guardrails in place first , and that’s a deliberate choice. The ability to automate something doesn’t mean you should automate it without oversight. Understanding where to draw that line is a leadership decision, not a technical one.

The API-first principle has been good practice for a decade. MCP is what makes it genuinely transformative. When you can talk to your infrastructure instead of clicking through it, you stop thinking about tools and start thinking about outcomes.

305 tools, seven API servers, one conversation. That’s not a demo. That’s my production environment.

Want to learn more about API-first infrastructure? Explore my Technology Lab for the full architecture, or reach out to discuss how this pattern could work in your environment.