IDE intelligence for agents — guardrails for unattended work, coordination for fleets.
Alimenter votre agent
Installation de l'éditeur. Ce n'est pas un endpoint PlugMCP.
Host a copy with our keys and logs.
Pas encore de version packagée dans le registre. Suivez le README du dépôt.
URL distante ou commande sur votre machine ? Ce qui distingue les deux installations
Exécuter sur PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
LancerPlumb is an MCP server that gives a coding agent the intelligence layer of an IDE — LSP-backed semantics, a tree-sitter code index, and project memory — inside guardrails: atomic, lock-serialised writes with transactional rollback, scoped filesystem and git access, and a daemon that survives its own crashes. And because every agent you run shares that one daemon, plumb is also the coordination layer between them: peers see the writes others made, message each other, and hand off work instead of duplicating it. A single binary; nothing else to install.
LLM agents usually work by reading whole files into the context window — token-heavy, lossy at scale, blind to symbol semantics, and unsafe to let loose on a real repo. Plumb is built on four pillars, in priority order.
Leaving an agent to edit a codebase for an hour is only viable if writes can't corrupt files and a crash can't wedge your session.
plumb serve is a reconnecting proxy. If the daemon crashes or hangs, it respawns one and replays the handshake; the agent never notices. In-flight writes are never silently re-run.See it run: docs/demos/ — two-agents-one-file.sh (a stale write is refused, nothing is lost) and daemon-respawn.sh (below — the daemon is killed mid-session; the agent's next edit still succeeds):
One daemon serves every agent you run — which makes it the natural place for agents to see and talk to each other, not merely avoid each other's writes. Locks stop two agents corrupting a file; coordination stops them duplicating a task, rebasing onto a function signature a peer is mid-rewrite of, or shipping a change a peer's in-flight work is about to invalidate.
workspace_sessions names every active session and the writes it made, as the daemon recorded them. Recorded activity, not another agent's say-so: an agent about to start a task can see that a peer is already in those files. (Read-only operations never appear, and a write that failed or was refused is kept but marked [failed — no change applied] — so "a peer is working here" and "this landed" are distinguishable at a glance.)leave_note / check_messages give sessions a threaded channel: hand a change to the peer already rewriting those files, or ask a peer to measure a behaviour instead of assuming it. Messages ride on ordinary tool results, so a working agent receives them without polling.[collab] intents) — share_intent declares what an agent is working on; a peer whose write touches a claimed path gets a hint at the moment of the would-be collision. Intents are deliberately labelled as unverified claims, kept distinct from the daemon-recorded activity feed, and never block anything.[collab] knowledge_handoff) — share_findings turns what an agent just learned into a searchable, secret-scrubbed project memory immediately, so the knowledge outlives the session that produced it.Coordination is advisory by design — the write-safety above never depends on agents cooperating. Reference: Cross-agent sharing in the tool docs and the [collab] config section.
The same primitives your editor has, exposed as structured tools:
rename_symbol, replace_symbol_body, safe_delete_symbol understand scope, types, and references.gopls/pyright output is appended to every write, so the agent learns it broke the build immediately.session_start returns workspace, branch, recent commits, diagnostics, and project memory.See the measured, reproducible numbers behind this: docs/use-cases.md — reading one function is 2.9×–33.4× less context than the whole file (the ratio is how much of the file you didn't need), and find_references returns the real call sites where a text search is 60% noise. The page publishes the losses too: read_multiple_files costs 1.31× more payload than reading the files natively (down from 1.32×, but still a loss — see Scenario 10 for why it isn't smaller). Every figure is regenerated by scripts/measure-use-cases.py.
Plumb is a single binary — from zero to your first answer:
1. Install
# Homebrew (macOS + Linux) — recommended
brew install plumbkit/plumb/plumb
# or with Go
go install github.com/plumbkit/plumb/cmd/plumb@latest
# or grab a prebuilt binary: https://github.com/plumbkit/plumb/releases
macOS note: prebuilt binaries are not yet notarised — on first run you may need
xattr -d com.apple.quarantine ./plumb, or right-click → Open. Homebrew installs avoid this.
2. Connect your agent
plumb setup claude-code # also: claude-desktop, codex, gemini, cursor, …
plumb setup writes the MCP config for you — no hand-editing JSON.
3. Open your project and try it
Make sure the language server you need is on your $PATH (gopls for Go,
pyright for Python, …), then point your agent at a real question. In Claude
Code:
cd your/project
claude "Use plumb to orient in this repo (session_start), then show me
everywhere <Handler> is called and what would break if I changed its signature."
Plumb resolves the workspace and runs session_start for orientation, then
answers with real LSP and topology data — actual call sites and blast radius —
instead of guessing from file dumps. It's read-only; nothing is modified. (Any
connected agent works — just paste the prompt.)
No
go.mod/pyproject.tomland not a git repo? Runplumb initonce to pin the workspace root (it also seeds.plumb/context.mdand project config).
Full walkthrough → docs/getting-started.md.
Plumb negotiates LSP capabilities per language and also ships a built-in tree-sitter index for search and navigation with no language server. Support comes in tiers — we'd rather be precise than claim a big number.
Real-binary validation has been exercised on macOS and Linux — as of 2026-08-21, all nine adapters pass their integration tests against real server binaries on both. Details, including three toolchain traps that look like adapter bugs, are in docs/adding-an-lsp.md. Windows is tracked but not yet supported — the daemon's Unix-socket architecture needs a port.
plumb serve is a thin, reconnecting stdio proxy. The real work happens in one shared background daemon, so language servers stay warm across chats.
flowchart TD
A1["Claude"] --> S1["plumb serve *"]
A2["Codex"] --> S2["plumb serve *"]
A3["Gemini"] --> S3["plumb serve *"]
S1 --> K["plumb.sock"]
S2 --> K
S3 --> K
K --> D["plumb daemon **"]
D --> SDB[("stats.db ***<br/>global — all projects")]
D --> G["gopls → /projects/foo"]
D --> P["pyright → /projects/bar"]
G --> F1[("/projects/foo/.plumb/ ***<br/>topology.db · memory.db")]
P --> F2[("/projects/bar/.plumb/ ***<br/>topology.db · memory.db")]
* plumb serve is a reconnecting proxy — if the daemon crashes or hangs it respawns one and replays the handshake, so your session survives without the agent noticing.
** one shared process, reused across every conversation.
*** SQLite. One global stats.db (tool stats + episodic summaries); two per-project indexes under each workspace's .plumb/ — topology.db (the code graph) and memory.db (memory search). Schema details → docs/architecture.md.
Servers stay warm across chats, per-path locks are shared across every connection, and symbol indexes update live after each write. Full architecture → docs/architecture.md.
Run plumb with no arguments for a live dashboard — see what your agent is doing in real time: every tool call as it happens, daemon health, per-tool stats, and streaming logs you can follow and filter. The fastest way to catch a runaway loop or confirm an edit landed.
Plumb exposes 61 tools. The ones you'll use constantly:
session_start · workspace_symbols · get_definition · find_references · rename_symbol · edit_file · transaction_apply · diagnostics
The rest cover filesystem reads/writes, LSP hierarchies, tiered git, an optional local Topology index (ranked search + blast-radius/route analysis, no language server needed), durable per-project memory, and cross-agent coordination (peer sessions, an agent mailbox, opt-in intents and knowledge handoff). Full API reference: docs/tools.md.
Global or per-project config.toml, or environment variables. Run plumb config show to see the resolved config with provenance.
[edits]
strict = true # require read_file before edit_file
rate_limit_per_minute = 30 # bound runaway agent loops
[git]
allow_destructive = false # reset/checkout/rebase off by default
allow_push = false # push/fetch/pull off by default
Full settings reference: docs/configuration.md.
Agents can already read code well enough; writing it unsupervised — concurrently, transactionally, recoverably — is what's still unsolved. Plumb is the bet that this is the half worth getting right first. It's early, and the language coverage says so: a small validated core, the rest clearly marked experimental.
Plumb is pre-1.0. The core — write-safety, the resilient daemon, the topology index, and project memory — is in daily use. The road to 1.0 is mostly about proving it beyond the validated core and smoothing distribution. Issues and ideas welcome.
Shipped
Getting to 1.0. Rather than jump from 0.9 straight to 1.0, Plumb ships a series of focused minor releases — 0.10 through 0.19 — each with one coherent theme. 0.19.x is the last 0.x release; 1.0 follows it as a deliberate stability commitment. Native Windows support is intentionally a post-1.0 (1.1) item, not a 1.0 gate. The themed plan:
Full detail, rationale, and the post-1.0 items (Windows, tree-sitter cleanup) are in docs/roadmap.md.
See CONTRIBUTING.md and AGENTS.md for architecture and code style. We follow Australian English in all prose. By contributing you agree to the Code of Conduct.
MIT — see LICENSE.
IDE intelligence for AI coding agents, with LSP semantics, tree-sitter indexing, project memory, and concurrency-safe edits.
Outils
Pas encore de liste d'outils. Les serveurs distants en obtiennent une après le premier contrôle d'état.
FAQ
Copiez sur cette page la configuration stdio pour Cursor, Claude Desktop, Claude Code ou VS Code. Elle utilise l'installation de l'éditeur, pas un proxy PlugMCP.
Aucune variable d'environnement requise n'est indiquée sur cette fiche.
Plumb s'exécute en local via stdio.
Dernière vérification : 2026-10-28. IDE intelligence for AI coding agents, with LSP semantics, tree-sitter indexing, project memory, and concurrency-safe edits.