Your MCP config files now sit in the same blast radius as your lockfiles. That is the quiet argument behind Bumblebee, a read-only scanner Perplexity open-sourced on May 22, 2026 that inventories your developer machine for supply-chain exposure — and treats AI tool configs as a first-class thing worth checking. It reads mcp.json, .mcp.json, claude_desktop_config.json, Cline's cline_mcp_settings.json, Gemini CLI's ~/.gemini/settings.json, and Claude Code's ~/.claude.json to see which MCP servers you have wired up, without ever launching a single one of them.
What's Converging
For most of the last decade, supply-chain scanning meant one of three things: scan the repo, scan the container, or scan production. That model assumes the risk lives in code you ship. But that is not where modern developers actually accumulate risk. A single laptop now carries global npm packages, language toolchains, VS Code and Cursor extensions, browser extensions, and a growing pile of AI agent configurations — MCP servers, local agents, tool-calling workflows — all sharing one trust boundary. The dev endpoint became the messiest, least-inventoried surface in the whole pipeline, and almost nobody has good visibility into it.
The MCP angle is what makes this land for AI-first developers. An MCP config is, functionally, an instruction sheet telling your AI coding tool which external servers to trust and run. As the video walkthrough on Bumblebee puts it, MCP configs "are becoming the new ENV files" — they're proliferating across machines, they encode trust, and most teams have no inventory of them at all. Perplexity built Bumblebee internally to answer one question during an incident — which of our machines actually has the compromised thing installed right now? — then open-sourced it under Apache 2.0. Crucially, MCP configs are not the whole tool; they are one ecosystem inside a scanner that also covers package managers and extensions. But for developers who live in Claude Code, Cursor, and Cline, the MCP coverage is the part that didn't exist anywhere else.
The Specific Development
Bumblebee is a single Go binary with zero non-standard-library dependencies, released at v0.1.1 and currently focused on macOS and Linux. You install it with go install, run bumblebee selftest to confirm it can read its known fixtures, then run a scan. Its defining design choice is that it is strictly read-only: it parses on-disk metadata and never executes install scripts, never calls npm ls or pip show, and never builds your project. That matters more than it sounds. During an active supply-chain incident, the instinctive move — ask everyone to run a package-manager command and report back — is exactly the wrong one, because a malicious package's install or lifecycle script could fire the moment you touch it. Bumblebee's whole premise is to look without triggering.
Coverage is broad: npm, pnpm, Yarn, Bun, PyPI, Go modules, RubyGems, Composer, and Homebrew on the package side; VS Code, Cursor, Windsurf, and VSCodium editor extensions; Chromium-family and Firefox browser extensions; and the MCP host configs listed above. It ships three scan profiles. Baseline is the lightweight weekly scan — global package roots, toolchains, extensions, and MCP configs. Project targets known workspace directories like ~/code or ~/src where lock files live. Deep is incident-response mode: you point it at explicit roots, even a bare home directory, usually paired with an exposure catalog and a time limit. Output is NDJSON — one structured record per line carrying ecosystem, package name, version, source file, and confidence — which is deliberately boring so you can pipe it through jq, ship it to a file, or feed it to another agentic workflow.
Our read is that the read-only, metadata-only design is the real story, not the feature checklist. Bumblebee is explicitly not an SCA tool (those scan application dependencies), not an SBOM tool (those describe what you shipped), and not EDR (that watches what executed). It answers a narrower, previously-unowned question: what packages, extensions, and dev-tool configs are physically present on this machine, and do any match something already known to be bad? That gap — the local developer state — is precisely the part most security teams cannot see clearly.
What's Likely Next
The 30-day question is data. Bumblebee's deep-scan flow gets dramatically more useful when paired with a good exposure catalog of known-bad packages and versions; without strong advisory data, you get an inventory but not a verdict. Watch whether the community converges on shared catalog formats, or whether Perplexity ships curated feeds. The v0.1.1 version number is a clear signal that the schema, profiles, and config coverage will move — Codex's config.toml and Continue's YAML MCP formats, for instance, weren't parsed at launch, and that list will almost certainly grow.
The 90-day question is whether MCP config auditing becomes a standard part of developer security hygiene the way dependency scanning already is. If it does, Bumblebee's bet — that AI tool configs deserve the same inventory discipline as your lockfiles — looks prescient, and you'll see the pattern absorbed into MDM rollouts and larger security platforms. The practical takeaway for now is unglamorous and correct: run bumblebee scan --profile baseline once a week, dump the NDJSON somewhere central, and when an advisory drops you can search across every machine in seconds instead of asking in Slack whether anyone happened to install the bad thing.
Sources
Written by the vybecoding.ai editorial team
Published on May 29, 2026