oleks/claude-plugin-nvim-agentic
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.6.0: drop MetaMCP from the neovim path

Browse Source 
MetaMCP never re-dials a restarted upstream — proven for both STDIO
and STREAMABLE_HTTP upstreams — so it cannot front an ephemeral,
editor-bound MCP. The pool now fronts the nvim-mcp-bridge directly:

  Claude Code -> mcp-session-pool /p/neovim -> nvim-mcp-bridge -> nvim

The pool re-establishes on its own (_ensure_pinned re-runs initialize),
so an event-driven /repin (fired by the socket-appearance systemd.path
oneshot) actually heals the chain.

- tool names revert to two-segment mcp__neovim__vim_* (no MetaMCP
  aggregation prefix)
- agents/companion.md + skills + README: surface description and
  troubleshooting runbook rewritten for the pool->bridge->nvim chain
This commit is contained in:
oleks
2026-05-21 13:24:01 +03:00
parent 3c5851e95e
commit 214c640f75
6 changed files with 53 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+15 -11
View File
@@ -8,10 +8,9 @@ It assumes two things are already wired up:
1. **`mcp-neovim-server`** reaching the running nvim's RPC socket (default
`/run/user/1000/nvim.sock`, created by NixVim's `extraConfigLuaPre`
`serverstart` at editor startup). The plugin ships a `.mcp.json` that points
the `neovim` MCP server at a **MetaMCP namespace** over Streamable-HTTP
(`pool.localhost:12010/p/neovim/mcp`) rather than spawning a per-session
`npx` stdio child — one persistent server, shared across sessions. Because of
MetaMCP's aggregation, the tools surface as `mcp__neovim__neovim__vim_*`.
the `neovim` MCP server at the `mcp-session-pool` over Streamable-HTTP
(`pool.localhost:12010/p/neovim/mcp`); the pool fronts a supervised
stdio→HTTP bridge. Tools surface as `mcp__neovim__vim_*`.
2. **`coder/claudecode.nvim`** loaded inside nvim, with `<leader>a*` keymaps
wired (toggle, focus, send, accept/deny diff).
@@ -23,17 +22,22 @@ one agent and three skills.
```text
Claude Code session
└─ .mcp.json → http://pool.localhost:12010/p/neovim/mcp (Streamable-HTTP)
└─ mcp-session-pool (:12010, M=1 session pooler)
└─ MetaMCP `neovim` namespace upstream
└─ mcp-neovim-server (one persistent stdio child on emmett)
└─ mcp-session-pool (:12010, M=1 session pooler, /repin endpoint)
└─ nvim-mcp-bridge — supergateway (:12016, --stateful)
└─ mcp-neovim-server (stdio child)
└─ /run/user/1000/nvim.sock (nvim msgpack-RPC)
└─ the running Neovim
```
MetaMCP and the pool both run on emmett as systemd services under user `oleks`,
so the per-user socket is directly reachable. If `mcp__neovim__neovim__*` tools
are missing, walk the chain top-down: socket exists? `systemctl status metamcp`?
session restarted since the wiring landed?
No MetaMCP in this path: nvim is ephemeral and MetaMCP never re-dials a
restarted upstream. The pool *does* re-establish (a fresh `initialize`), so
pool→bridge self-heals. Recovery is event-driven — a `systemd.path` watching
the nvim socket fires a oneshot that POSTs `/repin` to the pool when the socket
(re)appears; no polling. The pool and bridge run on emmett as systemd services
under user `oleks`, so the per-user socket is directly reachable. If
`mcp__neovim__*` tools are missing: socket exists? `systemctl status
nvim-mcp-bridge`? `http://127.0.0.1:12010/pools/neovim` pinned? session
restarted since the wiring landed?
## Layout