Client integration depth

Wiring Vaner as an MCP server is the minimum integration. To make sure the agent actually uses Vaner instead of just being able to, we install up to four layers per client. Clients differ wildly in what they support.

This page is the source of truth for:

• The four-layer leverage stack. what each layer does and why MCP alone is rarely enough.
• Per-client capability matrix. which layers each supported client actually exposes (per their official docs, sourced 2026-05).
• Vaner's current install footprint. which layers Vaner writes today, and the gaps we know about.

The four layers

Layer 1: MCP server

The technical wiring. Adds a vaner entry to the client's MCP server config so the client can call vaner.* tools.

This is the floor. Without it, nothing else matters; with it alone, you depend entirely on the model's training to know it should call Vaner. Models often don't.

Layer 2: Primer

A "system-prompt-like" markdown block telling the model when and how to use Vaner. Examples:

• "Before spelunking the codebase, call vaner.resolve with a short description of the task."
• "At the end of any non-trivial work, call vaner.feedback with the resolution_id and a rating."

Empirically: when the primer is missing, models don't reliably call vaner.resolve even when Vaner is wired. The primer is what turns possible into actual usage. Most clients support a per-project rules file (CLAUDE.md, .cursor/rules/*.mdc, AGENTS.md, etc.) that the model reads on every session.

Layer 3: Skills (or workflows / prompts / modes)

An agent-callable subroutine, usually a markdown document with metadata, shipped separately from the primer. Two flavors:

• Auto-loaded (Claude Code, Cursor, Codex CLI): the model reads each skill's description and decides when to invoke it. Vaner's vaner-feedback skill is auto-loaded; the model uses it whenever it's about to record feedback.
• User-invoked (Cline workflows, Windsurf workflows, Continue prompts): the user types /<skill-name> to trigger it. Less leverage, since the model won't call it on its own.

Some clients (Roo Code with run_slash_command) blur the line by letting the agent invoke its own slash commands.

Layer 4: Plugins / hooks

The deepest integration. A plugin bundle ships multiple layers atomically (MCP server + primer + skills + hooks + monitors) and registers code that runs at session lifecycle moments (SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop, FileChanged, etc.).

Hooks are what let Vaner do active work between turns: pre-fetch context when the user starts typing, surface fresh prepared work as the session opens, record feedback after a tool call lands. This is the layer that turns Vaner from "tool the agent can call" into "engine quietly preparing work for the agent in the background."

Plugin-system support is the most uneven layer. Some clients have rich hook APIs (Claude Code, Cursor 1.7+, Windsurf, Cline), some have plugins without hooks (Claude Desktop's MCPB), and some have neither (Zed, Continue).

Capability matrix

What each client supports per layer (based on official docs as of 2026-05). Cells link to the doc page where the feature is described.

Vaner's current install footprint

What vaner init and the Vaner Desktop app actually write today, per layer:

Gap analysis

After Phase C of the IDE/agent visibility plan, the leverage stack is filled in for every client where Vaner can ship today. What's left is gated on upstream releases or is UX-only:

Awaiting upstream

VS Code Copilot skill. Agent Skills standard, currently experimental in VS Code 1.108. Will ship when the feature graduates to stable.

Codex CLI hooks. Codex CLI exposes SessionStart, UserPromptSubmit, PreToolUse, PermissionRequest, PostToolUse, and Stop events behind a codex_hooks = true feature flag. Will ship when the flag goes stable.

UX-only, lower priority

Claude Desktop MCPB bundle. Claude Desktop has no lifecycle hooks but does have one-click MCPB install bundles. A Vaner MCPB would let users install via double-click instead of editing claude_desktop_config.json by hand. UX win, not a leverage win.

Genuinely not applicable

Zed skills/plugin. Zed has no agent-callable subroutine concept and no AI session-lifecycle hooks for third parties. Primer-only.

Continue plugin/hooks. Continue has no lifecycle hook system. Hub bundles cover plugin-style distribution but only for assistants/blocks, not lifecycle behaviour.

Roo plugin. Roo Code has no documented hook API. Slash commands (invocable by the agent via run_slash_command) are the deepest layer Roo exposes today.

Claude Desktop primer/skill. both are cloud-only on Claude Desktop; no local-disk surface for Vaner to write into.

How this informs the verification UI

The desktop wizard's final "Vaner is ready" panel reports per-client status using this same matrix. A row goes green only when every applicable layer for that client is wired, not just MCP. A client where Vaner is in mcp.json but no primer is installed gets an amber chip, because the likely failure mode is "the AI can call Vaner but doesn't."

See Pass 4 plan for implementation details.