Add optional MCP sidecar lifecycle support

[alsi-lawr]

Summary

Add optional support for running an MCP sidecar alongside agent-term.nvim.

The Neovim plugin should not implement the MCP protocol itself and does not need to expose a broad plugin-state API to the MCP layer. The sidecar should own MCP protocol/tooling and talk directly to Neovim through Neovim RPC where it needs editor state or editor actions.

Motivation

MCP-capable terminal agents can already consume external MCP servers. agent-term.nvim can support that workflow by handling the Neovim-side lifecycle: ensuring an RPC server exists, starting/stopping the sidecar, and wiring supported agents to the sidecar where appropriate.

This preserves the core project direction: native terminal-agent TUI hosting, with optional richer editor integration through MCP.

Prior art

linw1995/nvim-mcp is the closest architectural precedent:

• Lua Neovim plugin component
• external compiled MCP server
• live connection to Neovim via socket/pipe
• tools backed by Neovim state and LSP
• stdio/HTTP transports
• multiple Neovim instance support

The important precedent is not that agent-term.nvim should expose its own large API surface. It is that a plugin can manage Neovim socket lifecycle while an external sidecar owns the MCP server and uses Neovim RPC directly.

Proposed architecture

agent terminal TUI
  -> MCP client support in Codex/Gemini/Claude/etc.
  -> external MCP sidecar
  -> Neovim msgpack-RPC socket
  -> nvim_* API / nvim_exec_lua where needed

Responsibilities:

agent-term.nvim Lua layer:
  - ensure/start/stop Neovim RPC server
  - start/stop/restart MCP sidecar process
  - provide configuration for sidecar command/env/transport
  - install/register agent MCP config where supported
  - keep terminal hosting/session behaviour unchanged

MCP sidecar:
  - own MCP protocol/transport
  - own MCP tool schemas and tool registry
  - query Neovim editor state through RPC
  - perform editor actions through RPC
  - implement richer workflows such as diagnostics, open buffers, navigation, and diffs

The plugin is largely stateless from the MCP server's perspective. The sidecar should not need dedicated Agent Term state helpers beyond whatever is required for lifecycle/configuration. Legacy hook-based context state should remain separate.

Scope notes

• MCP support must be optional.
• Do not replace the native TUI workflow.
• Do not require MCP for normal terminal hosting.
• Do not implement MCP protocol handling in Lua.
• Do not expose a broad agent_term API surface to the MCP server unless a concrete need appears.
• Prefer Neovim RPC for editor context, diagnostics, file operations, and diff workflows.
• Start by evaluating whether to use nvim-mcp, integrate with it, or provide a small dedicated sidecar.

Candidate plugin commands

Exact names can be decided during implementation, but the lifecycle likely needs commands equivalent to:

:AgentTermMcpStart
:AgentTermMcpStop
:AgentTermMcpRestart
:AgentTermMcpStatus
:AgentTermInstallMcp

Open questions

• Should the sidecar be an existing server such as nvim-mcp, or a dedicated agent-term-mcp sidecar?
• If dedicated, should the sidecar be implemented in Rust, .NET/F#/C#, or another runtime? I want to choose a language that a) I can support and b) I find interesting enough to continue with.
• Which transport should be supported first: stdio, HTTP, WebSocket, or per-agent native config?
• Should sidecar lifecycle be global, per project, or per active Neovim instance?
• How should users configure sidecar command/env/arguments?

Acceptance criteria for an initial spike

• Document the chosen sidecar architecture and tradeoffs.
• Ensure agent-term.nvim can start a Neovim RPC server if one is not already running.
• Add lifecycle support for starting/stopping/status-checking the MCP sidecar.
• Verify at least one supported agent can connect to the sidecar.
• Keep existing terminal hosting and hook/context behaviour unchanged.