Buoy: an in-app React Native dev menu with an MCP server for coding agents

What Buoy replaces for React Native debugging

React Native debugging usually means stitching together three things that do not share state. Logs go to Metro or to a Chrome DevTools instance attached over a websocket. Network traffic goes to a proxy you configure by hand, or to nothing at all on a release build. Render counts and frame drops go to a profiler that needs a development build and a cable. Buoy's pitch is that all of it runs inside the app's own process, so the phone, a desktop app and an agent see one live session rather than three partial views. The README states that every tool runs inside your app's process and that the three surfaces see the same session. The target user is a React Native or Expo developer who tests on a real device and is tired of attaching a debugger. The second audience is newer: teams running Claude Code or Cursor against a mobile codebase, who need the agent to read live app state rather than guess from source.

The floating menu, the tool packages and the shared session

The mechanism is a single mounted component plus a set of independently installed tool packages. You install @buoy-gg/core and render <FloatingDevTools /> once. The README states that installing any tool package makes it appear in the menu on its own, with no registration step. Tools live in separate packages: @buoy-gg/network, @buoy-gg/storage, @buoy-gg/react-query, @buoy-gg/perf-monitor, @buoy-gg/js-top and others, each documented separately. Most need no configuration; the README gives zustandStores as a prop and watchAtoms() as a call for the few that do. Because the tools run in-process, they are not limited to what a debugger protocol exposes. The Highlight Updates tool is described as reporting each render together with its cause (mount, state, props or parent) and the exact useState before and after values. The Storage tool is described as browsing and editing AsyncStorage, MMKV and SecureStore with change history, and it lists biometric keys without auto-reading them. The Events tool aggregates a single timeline across every tool and offers export presets including Markdown for agents and an Errors Only filter. Three surfaces read that one session: the on-device menu, Buoy Desktop (a separate repository, macOS, Windows and Linux, with a UI/JS FPS, CPU and memory HUD and remote control of the device), and the MCP server, which the README describes as giving Claude Code, Cursor or any MCP editor structured tool calls into the running app.

Getting it running: one install, one component, one login

The README gives a two-step quick start. Install the core package with npm install @buoy-gg/core, then import FloatingDevTools from @buoy-gg/core and render it inside your root component alongside your app. That is the whole setup for the menu itself. Individual tools are separate installs. A free key is obtained with npx buoy login, and the README states no card is required. The README also states that every tool works without a key at reduced capture, and that the free key restores the full free tier. Pro is what unlocks production builds, the MCP server and unlimited capture. Configuration is deliberately thin: the README says most tools need zero config and a few take one line, naming zustandStores and watchAtoms() as examples. Two tools are marked as not yet generally available in the README table: Scenarios, listed as coming soon, and Ask Buoy, listed as beta. The Flutter port is also described as beta, installed with flutter pub add buoy and a BuoyDevTools widget wrapper. Note that the repository description mentions 15 tools while the README body says 22 in one place and 22 in the table heading. Treat the tool count as moving and check the docs index for the current list.

Where the model breaks down

Two constraints stand out. First, everything is gated on the app being instrumented. Buoy is a component you render inside your own build, so it cannot debug a binary you did not compile, a third-party app, or a crash that happens before React mounts. That rules out the classic case of diagnosing a release build you received from someone else. Second, the free tier is explicitly reduced capture. The README does not quantify what is dropped or capped, so the practical ceiling on network entries, render events or log lines per session is unknown from the supplied material. If you are chasing an intermittent issue in a high-volume app, that is the first thing to measure. The MCP server, which is the differentiating feature, is a Pro capability, so the agent-driven workflow is not something you can evaluate on the free tier alone. The repository page carries a NOASSERTION licence identifier, meaning GitHub could not map the licence file to a known SPDX identifier. The README does not discuss licensing. That is a real blocker for some organisations and should be resolved by reading the licence file directly rather than inferred from the repository metadata.

How this differs from Flipper and React Native DevTools

The closest comparison is Flipper, the plugin-based desktop debugger that was the default React Native debugging surface for years, and the newer built-in React Native DevTools. Both are desktop-first: you attach a client to the running app, and the tooling lives outside the process. Buoy inverts that. The menu renders on the phone, so it works with no cable, no desktop app and no Metro, which the README calls out directly for the Console tool: read logs from a release build with no cable and no Metro. The second difference is the agent surface. Flipper exposes a plugin API for desktop plugins; Buoy exposes MCP tool calls so an external model can read state and, per the README, tap real buttons and benchmark on a physical device. That is a different integration target. The trade-off is ecosystem breadth. Flipper's value came from third-party plugins and from being independent of the app's own release cycle. Buoy's tools are first-party packages maintained alongside the core, which means coverage is whatever the Buoy team ships, and each tool is an additional dependency in your bundle.

Version churn and what upgrading costs

The release history shows a v2.2.0 and a v3.0.1 published on the same day, 2026-05-28, with v2.1.15 roughly three weeks earlier and the last push to main in September 2026. A major version and a minor version landing hours apart suggests either a rapid fix after a breaking release or parallel release lines, and the supplied material does not say which. Either way, the practical cost is that a major bump in a package you render inside your app's root component is a change you have to test on device, not just in CI. The README also references a legacy package, react-native-react-query-devtools, in its badge set, implying a rename or migration path from an earlier standalone tool. If you are on that legacy package, the upgrade is not just a version bump. Because tools are separate packages, you can pin them independently, which limits blast radius but also means version skew between @buoy-gg/core and a tool package is a failure mode you own. Nothing in the material describes a compatibility matrix between core and tool versions.

Who should take the dependency

The case for Buoy is strongest for a team that tests on physical devices, wants network, storage, render and performance data in one session, and is already using an MCP-capable editor. The agent integration is the part that is hard to replicate: the README describes Claude or Cursor reading live state, tapping real buttons and benchmarking on a device, and the Events tool ships an LLM export preset for exactly that handoff. The case against is equally clear. If your debugging happens on simulators with a debugger attached, the built-in React Native DevTools already covers much of it at no dependency cost. If you need production-build inspection, budget for Pro. If you need a permissively licensed dependency with a known SPDX identifier, the NOASSERTION tag on the repository is the thing to check before anything else. The Flutter port is beta, so Flutter teams should treat it as a preview rather than a replacement for their existing tooling.

Editorial conclusion

Adopt Buoy if you already debug React Native on a physical device and want the same session visible to a coding agent without wiring up a bridge yourself. Skip it if your app is web-first, if you cannot install a component inside the app under test, or if you need a permissively licensed dependency and NOASSERTION on the repository page is not something you can accept. Before committing, verify three things: the actual licence text in the repository, whether the free tier's reduced capture is enough for your network and render volume, and whether the MCP server you plan to rely on requires Pro.

Official sources

1. Buoy-gg/buoy on GitHub
2. Issues
3. Project website
4. README
5. Releases