Case study
How it's built
An engineering case study on building an AI-native MCP connector for a 1,572-operation REST API—written by the person who built it.
Why I built this
RUCKUS One has a large API. As of September 2026 it exposes 1,572 REST operations covering Wi-Fi access points, ICX switches, Edge, and MSP tenants. Doing real work—auditing a venue, troubleshooting a client, authoring a change runbook, documenting a deployment—means knowing which of those 1,572 endpoints is relevant, what parameters it expects, and then cross-referencing the 544-page user guide to understand what the response actually means.
That is a lot of context to hold in your head on a Tuesday afternoon when a customer is waiting. I wanted to build something that could hold all of it and do the stitching, so I could just describe what I needed to get done.
The design decision that made the whole API reachable
The obvious approach is to write a dedicated tool for every API call you care about. That breaks immediately when the API has 1,572 operations and gets updated every few months. You would spend most of your time maintaining a catalog instead of building useful things on top of it.
Instead, I gave Claude a small set of primitives: search the spec by keyword or endpoint path, inspect an operation's schema, and execute a short script that the server runs in a sandboxed V8 environment. When you ask Claude a question that requires an API call, it searches the spec, reads the operation's details, writes a minimal script, and the server runs it with your credentials. The script cannot touch your filesystem or reach any network endpoint outside the RUCKUS One API, and it times out hard at 30 seconds.
This means one connector covers the whole 1,572-operation spec. When RUCKUS ships a new spec, a daily check flags it, I ingest it and redeploy, and the new operations are available in the next conversation, with no tool code to rewrite.
Safety as a design axis
Early on I decided that safety had to be a first-class concern, not something added after the fact. The risk with an agent that can call any API operation is obvious: a misunderstood instruction could make an unintended change. I built several layers to prevent that.
Write Guard is opt-in and covers direct API mutations. Every call Claude is about to make is previewed with the exact target tenant named, and the user has to confirm it. The confirmation is request-bound and expires in 10 minutes on the server—Claude cannot reuse an old approval.
I am precise about Write Guard's scope because overclaiming safety is worse than understating it. Write Guard covers direct API calls. Device CLI, runbook replay, venue copy runs, backup restore, and test-bed apply each have their own gates: a reviewable plan you inspect before arming, step verify gates during execution, and undo. If a verify gate fails, the runbook halts.
Credentials get the same care. Your RUCKUS One client secret is encrypted at rest with AES-256-GCM and HKDF, decrypted only when a token is minted for a call, and never returned to the browser or to Claude in any response.
The build
The first commit was April 17, 2026. The most recent was September 21, 2026. In roughly five months: 1,468 commits, about 670 pull requests, and around 79,000 lines of TypeScript.
The stack is Cloudflare-native: Hono on Workers, D1 (39 migrations so far), KV, R2, Workers AI, and Browser Rendering. Six Durable Objects handle the stateful work—held-open CLI sessions, unattended runbook autopilot, the live console, and rate limiting. An hourly cron handles retention and spec-update checks. No servers to patch.
I have 184 test files, roughly 55,000 lines of tests, run in CI on every change. The test suite grew alongside the product rather than being retrofitted. For a one-person project that ships continuously, a tight test loop is the difference between confident deploys and late-night rollbacks.
What took longer than expected
The floorplan map feature took much longer than I estimated. Rendering a venue floor to real scale with AP positions, client overlays, and co-channel analysis—then returning it as an actual image Claude can read and comment on—required its own image renderer, careful coordinate math, and several rounds of iteration to get the layers working cleanly. It is one of the features that demos best, because a floor map with roam paths drawn on it is much faster to read than a table of roam events.
The venue copy and element copy pipelines were also harder than they looked. A WLAN in RUCKUS One has a dependency closure—RADIUS profiles, DPSK configurations, AP groups—and moving it to another tenant means resolving all of those in the right order, handling name collisions, and compiling the whole thing into a step-gated runbook a human can inspect before arming. Getting that right required careful modeling of the dependency graph and a lot of edge-case testing.
What I would tell someone building something similar
The primitives approach—spec search plus sandboxed execution—scales in a way that hand-written tool catalogs do not. If the underlying API changes or grows, you update the spec ingestion. You do not touch the tool definitions.
Design for review at every mutation boundary. Users will trust an AI tool more after it asks to confirm a change than after it makes one without asking. That trust compounds over time and is worth the friction.
Build the test suite early and run it in CI from day one. At 1,468 commits with one person, the tests are the institutional memory.