This guide walks through one real session in which an AI agent used SiteRF’s MCP tools to design a Wi-Fi deployment, and shows what each tool returned. Every number below is copied from those tool results. If you have not connected an agent yet, start with Connect an AI agent to SiteRF.
The site is synthetic. It is an assumed warehouse layout we built for testing, not a customer facility, and nothing here has been checked on site. The point is the shape of the workflow and the evidence the tools hand back, not that these particular access points would work in a building.
The brief
An agent is given this, in plain language:
Design 5 GHz Wi‑Fi 6 for this warehouse. At least −67 dBm across the picking zone, racks are 5 m tall, access points go on the roof structure at 6 m. Use Aruba AP‑515 unless another model does better. Tell me what you could not verify.
The project holds a floorplan of 50 m × 37.16 m (about 20,000 sq ft): four concrete walls, one 4 m metal door, seven rows of racking 5 m tall and 2.4 m deep at an assumed inventory density of 0.8, and one coverage area called Picking zone. Rack loss is an assumption, and the tools say so every time.
1. Search for the fewest access points
The agent calls optimize_ap_placement with the requirement and does not choose positions. SiteRF generates 150 candidate mounting positions 3.02 m apart, solves each with its own solver, and runs a set-cover and swap search. Racks are height-aware: a path loses power only while it travels inside a rack, so an antenna mounted above the 5 m tops sees over them.
The result is 2 access points, with the reasons attached:
| Design | Access points | Predicted share of the zone at −67 dBm |
|---|---|---|
| Greedy pass (direct paths) | 3 | 99.9% |
| Winner: swap search | 2 | 97.1% |
| One more, for overlap | 4 | 100% |
| Evenly spaced layout | 5 | 99.6% |
The requirement was 95% of the zone. The result also states a lower bound of 2: no choice among the candidate positions can use fewer, because the largest single footprint cannot cover the required area with fewer access points. It is proven for the candidate positions only, and the result says a smaller design might exist that was not tried.
The search used direct paths, which under-estimates the signal a little, and all four designs were then re-solved with single reflections. The winner’s weakest spots are listed as regions with their coordinates: the largest is about 15 m² near (12.3, 6.2).
2. Plan channels, width and power
Because plan_channels is on by default, the winner also gets a channel plan, judged on SNR and SINR, not just signal. The tool compares it with the starting configuration of two radios on the same channel:
| Starting configuration | Planned | |
|---|---|---|
| Channels | both on 100, 20 MHz | 42 and 106, 80 MHz |
| Co-channel pairs | 1 | 0 |
| Share of the zone meeting signal, SNR and SINR | 73.3% | 97.1% |
| Capacity index | 52 Mbps | 1,166 Mbps |
The floors, 15 dB SNR and 10 dB SINR, are the Wi‑Fi 6 planning defaults, and the result says they are assumed. Under FCC rules the transmit ceiling is 30 dBm EIRP, and one of the two channels is a DFS channel. The capacity figure is a planning index from one spatial stream with no MAC overhead, not a throughput prediction.
3. Compare models against the same requirement
The agent asks compare_ap_models to design the same requirement with three models. Each gets a full placement search, and the three share one estimated solver budget, so the result says each used a coarser candidate grid than a single search.
| Model | Access points | Capacity index | SINR, 10th percentile |
|---|---|---|---|
| Ubiquiti U7‑Pro | 2 | 1,346 Mbps | 26.7 dB |
| Extreme Networks AP5010 | 2 | 1,180 Mbps | 26.7 dB |
| Aruba AP‑515 | 2 | 1,166 Mbps | 25.3 dB |
All three need two access points, so the ranking falls through to capacity. Price and PoE are null: the SiteRF catalog has neither, and the tool says so instead of filling them in. If the customer supplies a quote, the comparison totals it and labels it as supplied.
4. Draw it and cost it
generate_deployment_diagram draws the plan, racks, zone, and each access point with its channel, width, power and mounting height. Given one switch (IDF‑1 at the north wall, patch panel 2 m up), it estimates the cable runs:
- AP‑01: 32.1 m (22.1 m horizontal plus 4 m vertical)
- AP‑02: 51.5 m (41.5 m horizontal plus 4 m vertical)
- Total 83.6 m, neither run over the 90 m permanent-link limit
Those lengths follow the plan’s axes with a slack factor and service loops at each end. They are estimates, not a pull sheet.
estimate_cost then does something worth noticing. The agent supplied no prices and the organization has no rate card, so every line is unpriced: the two access points, 83.6 m of cable, two switch ports, labor and licences. The tool returns complete: false, lists each unpriced line with the reason, and withholds the total. A partial sum presented as a cost would be worse than no number.
5. Deliver the report
generate_report builds a customer PDF from the project: the requirement as the agent understood it, the design, the diagram, coverage maps, the bill of materials, how far the model was checked on site, and every assumption. It saves the PDF with the project’s reports and returns a download link that works without signing in and expires in 15 minutes. Every figure is labelled predicted, not surveyed. We did not regenerate the PDF for this article; the test project already holds one from the day before, so this step is described from the tool’s behaviour, not from a fresh output.
What the tools said they did not know
The agent is meant to pass these on to the customer, and each is in the result as a field, not buried in prose.
- Predicted, not surveyed.
confidence.statusispredictedandverified_by_surveyisfalse. No survey is stored for the project, so nothing was checked on site. - Wall losses are planning values. The concrete loss is an assumed figure for a typical assembly. The result asks whether a survey or measured attenuation exists for the main wall types.
- No fade margin. The design just reaches the threshold in the model. A margin of 5 to 10 dB is common for a design that must hold, and the result asks whether this one should.
- Rack loss is assumed. No published measurement fixes the loss of loaded pallet racking at Wi‑Fi frequencies. The result asks how full the racks are on a typical day and at peak, and whether a few paths through them can be measured.
- Not modelled: diffraction over rack tops and around aisle ends, stock above the described heights, staged pallets, forklifts, mezzanines, furniture, people, other floors, client load and roaming, and neighbouring networks.
The honest next step is a site survey. SiteRF can then take the readings with import_survey and show where the model disagrees, so the walls and racks can be corrected before anything is bought.
A second run: reading a drawing
A floorplan does not have to be typed in. In a separate check we sent the sample office drawing from our test suite, a 680-byte DXF, through upload_floorplan_file and extract_floorplan on a scratch project.
The upload is a signed link that expires in 15 minutes, because a file cannot travel through a tool call. The agent sent it with one curl command. The result:
- 11 walls read, 4 concrete on a layer named Exterior and 7 drywall on one named Interior, each with 0.95 confidence and its material taken from the layer name.
- 38 m × 22 m, with the scale taken from the file’s declared units. The tool still asks for one real dimension to cross-check it.
- One line left out. A layer named Glass is not treated as a wall by default, because it may be a glazed wall. The tool turns that into a question for the customer: are those lines walls, and what are they made of?
- Further open questions: whether any windows or solid doors matter, and which spaces need coverage.
That is the intended division of labour. The tool reads what the file says exactly and says what it cannot know; the human answers the questions. A PDF or photograph is read less precisely than a DXF, so its walls are proposals to check against the drawing.