How MCP Makes Wi-Fi AI Agents Practical: From the Plumber Analogy to a 15-Minute Build

In his talk at WLPC Prague 2026, Jean Macq opened with a plumber analogy: he gives a plumber a task, the plumber shows up with a toolbox, and picks the right tools to solve the problem on their own. Swap "water" for "data," the "toolbox" for an "MCP server," and the "plumber" for an "AI agent," and you get a picture of network automation you can put into practice today.

This analogy holds up because an AI agent works much like a house call: you give it a goal and instructions, it uses a model as its "brain" and the tools provided by MCP as its "toolbox," and it autonomously combines tools to complete the task. Four years ago on the same stage, Macq talked about script automation, and he believes the change MCP brings is fundamental—scripts always go from A to B along a fixed path, with only the inputs and outputs differing; MCP turns the script itself into a tool, and the agent can decide for itself how to call it and how to chain calls together based on the documentation.

What MCP Is: Turning Everything into a Tool

MCP was proposed by Anthropic in November 2025 and later transferred to the Agentic AI Foundation (under the Linux Foundation). Its positioning is plain: to let AI applications conveniently access tools and information.

An MCP server can contain three types of content. Tools are the core part—anything can become a tool: REST APIs, SNMP, data-processing logic, even another MCP. Resources are used to provide data to the agent. Prompts are the system's suggested best ways for users to use it. The key point is that these tools all come with documentation, and that documentation is exactly what the AI agent relies on to understand "how to use" them.

Macq demonstrated three progressive application levels on stage. The most basic is connecting MCP to an access point to directly ask questions or issue commands about the Wi-Fi environment, such as creating an SSID or doing troubleshooting. One level up, let MCP connect to switches, DHCP, and DNS at the same time—a single "build me a new network" can trigger DHCP pool creation, gateway configuration, switch VLAN assignment, Wi-Fi rollout, and even calling a test client to verify connectivity. One level further up is the MCP gateway—not an official term, but referring to a site-side server that lets agents and clients communicate with different remote MCP servers at each site, enabling cross-site configuration replication, spec rollout, and similar operations.

MCP (Model Context Protocol) is essentially a standardized interface protocol that solves the integration problem of "how AI models can securely and uniformly call external capabilities." Before MCP, every time a new system was integrated (such as a REST API, database, or network device), developers had to write separate adapter code for the AI application, resulting in high integration costs and poor reusability. MCP defines the communication spec between clients (AI applications) and servers (tool providers); the server exposes three types of capabilities—tools, resources, and prompts—in a standard way, along with machine-readable documentation. This way, any MCP-compatible AI agent can discover and call tools plug-and-play, without custom development for each backend system. The protocol's transfer to the Agentic AI Foundation under the Linux Foundation also means it is evolving toward a vendor-neutral, community-governed open standard, which reduces the risk of lock-in by a single AI vendor for network equipment vendors and operations teams.

The "MCP gateway" mentioned in the article is not an official term, but it corresponds to a real pain point in multi-site network operations: each site may run its own independent MCP server (each connected to local access points, switches, and other devices), while AI agents and clients are usually located centrally. The MCP gateway acts as a site-side aggregation proxy, letting central-side agents discover and route to remote MCP servers at each site without directly exposing each site's server addresses and credentials. This architecture is especially critical in cross-site bulk configuration, unified spec rollout, and configuration replication scenarios, and it also consolidates credential management and access control at the gateway layer, consistent with the security principle later described as "credentials stay on the server side."

Building Your First MCP in 15 Minutes

Macq played a 15-minute screen recording (compressed into a two-minute presentation), and the whole process is simpler than most people expect.

He opens a session on the left side of Claude, points it at an empty folder on his laptop, and grants authorization. The first prompt asks for generating the basic framework of an MCP server, while specifying routing plans, context, suggestions, and key-check requirements. The file tree on the right immediately starts growing as the system automatically generates the needed files.

Next comes connecting to the Ruckus access point. Macq provides connection information through the terminal, and these credentials are kept in a local file, never handed to the agent itself. Once the connection is established, he asks the agent to generate four tools: check existing Wi-Fi, create new Wi-Fi, activate Wi-Fi, and verify results. He then connects the agent to the MCP server to test communication, and asks it to "create a new Wi-Fi similar to the existing one, on the same VLAN." The agent requests confirmation twice—once for creation and once for activation—and each time Macq explicitly approves. On screen you can watch the venue and access point counts go from 0 to 1, the new SSID appear, and all the information about that Wi-Fi become queryable. The whole MCP also keeps a complete log, so every API call can be traced.

Four Hard Rules for Designing Tools

Among Macq's recommendations, several directly concern production-environment security.

Let the server do the data cleaning. Tools should not only fetch data and perform operations but also tidy up the results before handing them to the AI. This work should be done server-side rather than letting the agent handle it itself, otherwise token consumption will balloon rapidly.

Read-only by default. Tools should be read-only from the moment of design. If the business genuinely needs write operations, explicit approval must be requested before any change—this is exactly why he clicked confirm twice in the demo.

Keep credentials on the server side. Never hand credentials to the AI itself. They should stay local, protected, and confidential.

Log everything, and don't trust agent output. Every call must be logged so that what happened can be reconstructed afterward. At the same time, remember: everything from an agent should be treated as untrusted input, and double-checking is always a good habit.

The principle of "read-only by default" matters more in the AI-agent context than in traditional automation, because agent behavior is probabilistic and autonomously compositional rather than a deterministic scripted path. A read-only design minimizes the tool's initial attack surface: even if the agent miscalls a tool due to a misunderstood prompt or model hallucination, it will not cause changes to the production network. When the business genuinely needs write operations, "requesting explicit approval before changes" is essentially implementing human-in-the-loop approval at the tool level, returning control over irreversible operations to the engineer. This complements the later principle of "don't trust agent output"—the former controls what the agent can do, the latter controls what the agent says, and together they form two lines of defense for safely deploying agents.

Why Network Engineers' Experience Is Actually Worth More

There is an easily overlooked judgment in the talk: in the MCP era, the value of domain experts is not diminished but amplified.

The reason is that the agent needs a "user manual" to call tools correctly, and only someone who knows the domain can write that manual. Macq's advice is: pick something you repeatedly do every day, break it down into specific actions, and describe it to the coding system in as much detail as possible—because that description will directly become the manual the agent uses to understand the tool. The machine cannot decide for you what you want the tool to do. Once you have described it clearly, leave the rest to vibe coding: generate, run, test, self-repair—this loop runs quite smoothly.

He also mentioned a noteworthy detail: the script automation everyone discussed four years ago has not disappeared but has been absorbed into the toolbox. The parts with fixed paths became tools, and the parts requiring judgment were handed to the agent. This division of labor makes MCP's adoption threshold lower than imagined—you don't need to overturn existing automation, just layer on top of it.

Macq's conclusion is just one sentence: go try it. His environment is not complicated, and the build process is a 15-minute video. In his words, there is already a "dot" in your environment; MCP simply draws the lines connecting them.

One-line Summary

MCP turns scripts and APIs into documented tools, letting AI agents autonomously handle network automation like a plumber.

Paragraph Summary

Based on Jean Macq's talk at WLPC Prague 2026, this article explains how MCP (Model Context Protocol) upgrades network automation from fixed scripts to autonomous orchestration by AI agents. MCP was proposed by Anthropic in November 2025 and transferred to the Linux Foundation; a server can package three types of content—tools, resources, and prompts—with tools carrying documentation so agents understand how to call them. Applications span three levels: single-point connection to access points, cross-system orchestration (DHCP/DNS/switches/Wi-Fi), and cross-site operations via an MCP gateway. A 15-minute demo shows the complete process from an empty folder to creating and activating Wi-Fi, with the agent requesting human approval twice before write operations. Macq offers four tool-design rules: clean data server-side, read-only by default, never hand credentials to the AI, and log everything while not trusting agent output. He emphasizes that domain experts' value is actually amplified, because only someone who knows the domain can write the tool manual—and his conclusion is "go try it."