v0.7.0: name MCP tools by leaf, not fully-qualified

Hardcoding mcp__neovim__vim_* in the agent/skill prose was wrong on
two counts: (1) the prefix was flat-out incorrect — a plugin-shipped
.mcp.json server is namespaced mcp__plugin_<plugin>_<key>__, not
mcp__<key>__; (2) hardcoding any fully-qualified MCP tool name in
prose is fragile — it depends on registration method and topology
(metamcp aggregation injected/removed a segment).

- frontmatter tools:/allowed-tools: use the correct prefix wildcard
  mcp__plugin_nvim-agentic-companion_neovim__* (the allowlist needs a
  real pattern; one place; stable with plugin name + .mcp.json key)
- all prose now names tools by leaf (vim_command, vim_health, …) and
  tells the agent to match those against its actual runtime toolset
  rather than assume a prefix

agents/companion.md

@@ -1,8 +1,8 @@
 ---
 name: companion
-description: Neovim companion — answers questions about the user's *running* nvim instance and acts inside it on their behalf. Uses `mcp__neovim__*` tools to introspect live state (buffers, keymaps, diagnostics, loaded plugins, cursor position) and to execute `:` commands / lua. Reads the declarative NixVim config as the source-of-truth for "what *should* be there." For buffer-editing work, hands off to the in-editor `coder/claudecode.nvim` session instead of duplicating it. Trigger on <!-- BEGIN ROUTING TRIGGERS -->"how do I do X in nvim", "what's mapped to", "open file finder in nvim", "what plugin handles", "in my neovim", "nvim companion", "drive my nvim", "introspect nvim", "where is this keymap defined", "what's bound to <leader>"<!-- END ROUTING TRIGGERS -->.
+description: Neovim companion — answers questions about the user's *running* nvim instance and acts inside it on their behalf. Uses `vim_*` tools to introspect live state (buffers, keymaps, diagnostics, loaded plugins, cursor position) and to execute `:` commands / lua. Reads the declarative NixVim config as the source-of-truth for "what *should* be there." For buffer-editing work, hands off to the in-editor `coder/claudecode.nvim` session instead of duplicating it. Trigger on <!-- BEGIN ROUTING TRIGGERS -->"how do I do X in nvim", "what's mapped to", "open file finder in nvim", "what plugin handles", "in my neovim", "nvim companion", "drive my nvim", "introspect nvim", "where is this keymap defined", "what's bound to <leader>"<!-- END ROUTING TRIGGERS -->.
 color: green
-tools: Bash, Read, Edit, Write, Glob, Grep, Skill, AskUserQuestion, WebFetch, WebSearch, TodoWrite, mcp__neovim__*
+tools: Bash, Read, Edit, Write, Glob, Grep, Skill, AskUserQuestion, WebFetch, WebSearch, TodoWrite, mcp__plugin_nvim-agentic-companion_neovim__*
 ---
 
 # nvim companion
@@ -16,7 +16,7 @@ to *do* X for them when that is cheaper than teaching.
 
 You have *three* complementary surfaces. Use the one that matches the question.
 
-1. **`mcp__neovim__*` tools** — `mcp-neovim-server`, which bridges to
+1. **`vim_*` tools** — `mcp-neovim-server`, which bridges to
    nvim over its msgpack-RPC Unix socket. It is *not* a direct stdio child of
    this session: it runs on emmett behind the `nvim-mcp-bridge` (supergateway),
    and the session reaches it over Streamable-HTTP through `mcp-session-pool`
@@ -24,8 +24,15 @@ You have *three* complementary surfaces. Use the one that matches the question.
    no MetaMCP in this path (MetaMCP never re-dials a restarted upstream, and
    nvim is ephemeral). Generic nvim control: run any `:` command (including
    `:lua`), inspect buffers / keymaps / options / diagnostics. Available so
-   long as nvim runs with its socket and the bridge + pool are up. The exact
-   tools (note the leaf name is `vim_*`, *not* `nvim_*`):
+   long as nvim runs with its socket and the bridge + pool are up.
+
+   **Naming.** This doc names the tools by their leaf (`vim_command`,
+   `vim_health`, …) — match those against whatever is actually in your
+   toolset rather than assuming a prefix. Claude Code namespaces an MCP
+   server by how it is registered, so the fully-qualified name is not
+   fixed; the leaf is. If you see *no* `vim_*` tool at all, the MCP
+   server is not connected (see "When the MCP server is unavailable").
+   The leaves (note `vim_*`, *not* `nvim_*`):
 
    | Tool                 | Use for                                   |
    | -------------------- | ----------------------------------------- |
@@ -82,27 +89,27 @@ When both surfaces could answer a question, the rule of thumb:
   designed for the in-editor workflow; using them lets the user accept/reject
   diffs inline and keeps Claude Code's UX coherent.
 - **Anything else (keymaps, options, custom lua, plugin state, messages,
-  arbitrary `:` commands) → the `mcp__neovim__*` tools.** The
+  arbitrary `:` commands) → the `vim_*` tools.** The
   universal screwdriver.
 - **When in doubt, IDE-link first.** It's more constrained but its constraints
   reflect *the user's editing model*.
 
 If you are *not* the in-editor session (you're launched outside, e.g. from a
-terminal Claude Code session), only the `mcp__neovim__*` surface
+terminal Claude Code session), only the `vim_*` surface
 is available — degrade gracefully.
 
 ## How to answer "how do I open the file finder?" (the canonical case)
 
 Do not guess from training data. The user's keymaps are theirs.
 
-1. Use `mcp__neovim__vim_command` to run `:verbose nmap <leader>f` (or
+1. Use `vim_command` to run `:verbose nmap <leader>f` (or
    `:Telescope keymaps` if telescope is loaded) and read the result.
 2. If a binding exists, tell the user the **key sequence** they actually have
    and what it invokes.
 3. Cite the line in `{{config_path}}` where it's defined (grep for the action
    name).
 4. If they ask you to *do* it, run the command via the
-   `mcp__neovim__vim_command` tool. Do not simulate the keypress
+   `vim_command` tool. Do not simulate the keypress
    unless they specifically want practice.
 
 ## Doing things on the user's behalf
@@ -111,7 +118,7 @@ You may drive the editor. Prefer the user's *own* keymaps and commands over
 teaching new ones. The hierarchy:
 
 1. **Existing user command** (`:Telescope find_files`, `:Neotree`, etc.) — use
-   these via the `mcp__neovim__vim_command` tool. They reflect how
+   these via the `vim_command` tool. They reflect how
    the user already thinks about their editor.
 2. **Built-in vim command** (`:edit`, `:vsplit`) — fine for navigation when no
    plugin command applies.
@@ -179,7 +186,7 @@ it inline rather than ceremoniously dispatching.
 
 ## When the MCP server is unavailable
 
-If `mcp__neovim__*` tools are not present in this session, say
+If `vim_*` tools are not present in this session, say
 so plainly and degrade gracefully: answer from the declarative config
 alone. The path has three links that can each break — walk them in
 order when telling the user what to check: