MCP Server — ChatCLI as a server (and ACP)

chatcli mcp-server exposes ChatCLI’s FULL surface over MCP: chat with the complete experience pipeline (memory, contexts, skills, knowledge), the real agent/coder loops with per-call provider routing and quality toggles, every built-in tool, all skills as prompts, local state as chatcli:// resources, and cross-channel conversation continuity. chatcli acp exposes ChatCLI over the Agent Client Protocol with chat/agent/coder modes, live streaming and cancellation.

Beyond being an MCP client (consuming external tools — see MCP Integration), ChatCLI can also be a server: other agents/clients — Claude Code, Claude Desktop, IDEs, editors, even another ChatCLI — can drive ChatCLI over the protocol.

These are two external subcommands, both speaking JSON-RPC over stdio (stdin/stdout carry the protocol; all logging goes to the file logger):

• chatcli mcp-server (alias mcp-serve) — an MCP (Model Context Protocol) server. Negotiates revision 2025-03-26 or 2024-11-05.
• chatcli acp — an ACP (Agent Client Protocol) server, for editors (Zed) and agent-to-agent use.

---

chatcli mcp-server

Exposes ChatCLI’s entire capability surface — not a curated subset:

Harness tools

Tool	What it does
ask_chatcli	Chat with the full ChatCLI experience pipeline — the user’s long-term memory and profile, /context attachments for the session, pinned and trigger-activated skills, knowledge retrieval and token-aware history compaction: the same enrichment an interactive turn gets. Keeps server-side history per session; accepts per-call provider / model overrides; plain: true skips the pipeline for a cheap raw turn.
coder_task	The full agent loop on a task — recommended for anything that needs autonomous work. Reads/edits files, runs commands and uses every built-in tool, memory, knowledge and any MCP server ChatCLI is itself connected to. The session id scopes which /context attachments and knowledge bases the run sees and carries the run’s own conversation: agent/coder runs keep per-session history across calls, not a process-global one. Accepts provider / model and quality toggles.
agent_task	The command-oriented (ReAct) loop that proposes shell commands step by step. Prefer coder_task for general work. Same routing, quality and per-session conversation/scoping options.
manage_session	Persist and restore the conversations behind ask_chatcli’s session parameter — save/load/attach/detach/status/list/delete/clear/active, plus full-text search across the saved-session store and fork to copy a saved session. Shares the /session store with the interactive REPL. save and load now bind the live session to the saved name, and attach binds even to a not-yet-existing one: every turn is written through to the file and writes made by other surfaces (REPL, gateway, another server) are adopted before each turn — cross-surface continuity; detach drops the binding, status reports it. Live sessions also autosave by default as rolling mcp-<session> mirrors after every turn (CHATCLI_MCP_SESSION_AUTOSAVE; unset follows CHATCLI_SESSION_AUTOSAVE), and clear saves one last time before discarding.
list_providers	The routing surface: configured providers, active provider/model, and each provider’s cataloged models.

The quality parameter maps to the CHATCLI_QUALITY_* namespace, so a caller can turn on plan, refine, verify, reflexion, convergence and lessons for a single run:

{ "name": "agent_task", "arguments": {
    "task": "audit the auth flow",
    "provider": "DEVIN", "model": "gpt-5.6-sol",
    "quality": { "CHATCLI_QUALITY_ENABLED": "true" }
} }

Every plugin tool

All registered built-in and external plugins are advertised individually (37 on a default build): files (read, search, tree, coder), web (websearch, webfetch, http, api-explorer), memory (memory, recall), knowledge (knowledge, context, compress, docs-flatten), visuals (diagram, graphview, image), plus moa, lsp, scheduler, session, osv, wikipedia, registry-tags, todo, tools, channels, send, proc, skill, speak…

• Each tool carries its usage embedded in the description and a readOnlyHint annotation derived from ChatCLI’s per-plugin capability metadata.
• Arguments follow the same contract the agent uses: a JSON envelope ({"cmd":"read","args":{...}}) or a flat string.
• Interactive tools that require a live terminal (ask, voice, park) are never exposed — over stdio they would hang forever.

Exposure policy — CHATCLI_MCP_TOOLS

Value	Behavior
all (default)	Every tool, including write/exec — starting the server is the opt-in.
safe	Only tools whose capability metadata reports read-only.
read,search,recall	Explicit allowlist (comma-separated, with or without @).

Skills as MCP prompts

Every installed skill is served through prompts/list / prompts/get — the client can pull ChatCLI’s whole skill catalog as ready-to-use prompts.

Local state as MCP resources — chatcli://

Everything the user built in ChatCLI is browsable read-only through resources/list / resources/read:

URI	Content
chatcli://memory/index · longterm · profile · projects · stats	The user’s long-term memory, profile and tracked projects
chatcli://contexts · chatcli://contexts/{name}	The /context store catalog and each context’s rendered content
chatcli://knowledge/{kb} · chatcli://knowledge/{kb}/{source}?offset=N	Knowledge-base TOC and paged document reads
chatcli://skills · chatcli://skills/{name}	Skill catalog with triggers (so a client can reproduce activation semantics) and each skill’s body
chatcli://sessions · chatcli://sessions/{name}	Saved-session names and their JSON content

Mutations go through the tools surface (memory, context, manage_session, …). CHATCLI_MCP_RESOURCES=off disables the resources surface entirely.

Cross-channel continuity — the conversation hub

The server joins the conversation hub in resume mode: it adopts the principal’s active conversation instead of rotating it, so a thread started in the interactive REPL or on a gateway channel (Telegram, Slack…) continues seamlessly from any MCP client — and the turns made over MCP show up back in the REPL. CHATCLI_MCP_HUB=off opts out; CHATCLI_MCP_HUB_PRINCIPAL isolates the MCP thread under its own principal.

Unattended safety — CHATCLI_MCP_DANGER

stdin carries the protocol, so the server runs unattended (every interactive confirmation auto-approves, like the gateway daemon). Dangerous commands in coder_task exec calls are always hard-blocked regardless of policy; for the remaining shell-command gate, CHATCLI_MCP_DANGER=block declines dangerous commands in-band (the model sees the refusal and replans) instead of auto-approving. Default is allow, matching the gateway.

Approval prompts via elicitation

Clients that declare the elicitation capability at initialize get a better contract: coder-policy ask rules and dangerous coder_task exec commands raise an elicitation/create approval form in the client instead of the blanket behavior above. Only an explicit accept with approve: true runs the action — decline, cancel or a transport failure denies, and the model replans in-band. Clients without the capability (most wrapped CLIs) keep the exact contract of the previous section; no server→client request is ever sent to them.

No provider configured? Still useful

An MCP client brings its own model — ChatCLI’s direct tools don’t need a local LLM. Without any key/OAuth in ChatCLI, the LLM-backed tools (ask_chatcli, agent_task, coder_task) are simply hidden from tools/list, and every direct tool keeps working (persistent memory, knowledge bases, LSP, diagrams, scheduler… driven by the caller’s model). Configure a provider and restart to enable the harness tools.

Connecting from Claude Code

claude mcp add chatcli -- chatcli mcp-server

Or in a JSON config:

{
  "mcpServers": {
    "chatcli": {
      "command": "chatcli",
      "args": ["mcp-server"],
      "env": { "LLM_PROVIDER": "CLAUDEAI", "LLM_MODEL": "claude-sonnet-4-6" }
    }
  }
}

The agent and coder render to stdout; the backend captures that output during the run and returns it as the tool result. Direct tool calls are stdout-captured too, so a chatty plugin can never corrupt the protocol channel. Long-running calls don’t block the read loop — requests dispatch concurrently, which is what makes cancellation work.

---

chatcli acp

A full Agent Client Protocol server: sessions with chat/agent/coder modes, structured tool calls and plan updates, slash commands and native IDE permission dialogs — the way to run ChatCLI inside JetBrains IDEs and Zed.

chatcli acp

• Structured updates — agent/coder runs emit native tool_call/tool_call_update, agent_thought_chunk and plan frames; the IDE renders collapsible tool calls and a live plan instead of a streamed transcript.
• Slash commands — /coder, /config, /model and a headless allowlist are advertised to the client and work from the IDE prompt box.
• Permission dialogs — dangerous commands and security-policy ask rules raise session/request_permission (native Allow/Reject in the IDE) instead of blanket auto-approve/block.
• Cancellation — session/cancel interrupts an in-flight prompt and closes any open tool call.
• Session restore — session/load (capability loadSession: true) brings a prior session id back to life (live state, or its mcp-<id> autosave mirror after a restart) and replays the conversation into the client; /session from the prompt box operates per session and binds to named sessions for cross-surface continuity.

Full setup (JetBrains ~/.jetbrains/acp.json, Zed agent_servers), the command surface, security model and protocol details live on the dedicated page: ACP — ChatCLI inside your IDE.

---

See also

• ACP — ChatCLI inside your IDE — the ACP server in depth: IDE setup, slash commands, permission dialogs
• MCP Integration — ChatCLI as an MCP client, including chatcli mcp add
• Environment Variables — LLM_PROVIDER, LLM_MODEL, CHATCLI_MCP_TOOLS
• Command Reference — external subcommands