São dois subcomandos externos, ambos falando JSON-RPC sobre stdio (stdin/stdout carregam o protocolo; todo log vai para o file logger):
chatcli mcp-server(aliasmcp-serve) — servidor MCP (Model Context Protocol). Negocia a revisão2025-03-26ou2024-11-05.chatcli acp— servidor ACP (Agent Client Protocol), para editores (Zed) e uso agente-a-agente.
chatcli mcp-server
Expõe a superfície completa do ChatCLI — não um subconjunto curado:
Tools do harness
O parâmetro
quality mapeia para o namespace CHATCLI_QUALITY_*, então o chamador pode ligar plan, refine, verify, reflexion, convergence e lessons para uma única execução:
Todas as plugin tools
Todos os plugins built-in e externos registrados são anunciados individualmente (37 em um build padrão): arquivos (read, search, tree, coder), web (websearch, webfetch, http, api-explorer), memória (memory, recall), knowledge (knowledge, context, compress, docs-flatten), visuais (diagram, graphview, image), além de moa, lsp, scheduler, session, osv, wikipedia, registry-tags, todo, tools, channels, send, proc, skill, speak…
- Cada tool carrega o usage embutido na descrição e a annotation
readOnlyHintderivada da metadata de capabilities por-plugin do ChatCLI. - Os argumentos seguem o mesmo contrato do agente: envelope JSON (
{"cmd":"read","args":{...}}) ou string plana. - Tools interativas que exigem terminal vivo (
ask,voice,park) nunca são expostas — via stdio travariam para sempre.
Política de exposição — CHATCLI_MCP_TOOLS
Skills como MCP prompts
Toda skill instalada é servida viaprompts/list / prompts/get — o client pode puxar o catálogo inteiro de skills do ChatCLI como prompts prontos.
Estado local como MCP resources — chatcli://
Tudo que o usuário construiu no ChatCLI fica navegável (somente leitura) via resources/list / resources/read:
Mutações passam pela superfície de tools (
memory, context, manage_session, …). CHATCLI_MCP_RESOURCES=off desativa a superfície de resources por completo.
Continuidade cross-channel — o hub de conversas
O servidor entra no hub de conversas em modo resume: adota a conversa ativa do principal em vez de rotacioná-la, então um fio iniciado no REPL interativo ou num canal do gateway (Telegram, Slack…) continua de qualquer client MCP — e os turnos feitos via MCP aparecem de volta no REPL.CHATCLI_MCP_HUB=off desativa; CHATCLI_MCP_HUB_PRINCIPAL isola o fio do MCP sob um principal próprio.
Segurança unattended — CHATCLI_MCP_DANGER
O stdin carrega o protocolo, então o servidor roda unattended (toda confirmação interativa auto-aprova, como no gateway daemon). Comandos perigosos em chamadas exec do coder_task são sempre bloqueados independente da política; para o gate restante de comandos shell, CHATCLI_MCP_DANGER=block recusa comandos perigosos in-band (o modelo vê a recusa e replaneja) em vez de auto-aprovar. Default é allow, igual ao gateway.
Prompts de aprovação via elicitation
Clientes que declaram a capabilityelicitation no initialize ganham um contrato melhor: regras ask da política do coder e comandos exec perigosos do coder_task abrem um formulário de aprovação via elicitation/create no cliente, em vez do comportamento cego acima. Só um accept explícito com approve: true executa a ação — decline, cancel ou falha de transporte negam, e o modelo replaneja in-band. Clientes sem a capability (a maioria dos CLIs wrapeados) mantêm exatamente o contrato da seção anterior; nenhum request servidor→cliente é enviado a eles.
Sem provider configurado? Ainda é útil
Um client MCP traz o próprio modelo — as tools diretas do ChatCLI não precisam de LLM local. Sem key/OAuth no ChatCLI, as tools que dependem de LLM (ask_chatcli, agent_task, coder_task) simplesmente somem do tools/list, e todas as tools diretas continuam funcionando (memória persistente, knowledge bases, LSP, diagramas, scheduler… dirigidas pelo modelo do chamador). Configure um provider e reinicie para habilitar as tools do harness.
Conectando do Claude Code
O agent e o coder renderizam no stdout; o backend captura essa saída durante a execução e devolve como resultado da tool. Chamadas diretas de tool também são capturadas, então um plugin falante nunca corrompe o canal do protocolo. Chamadas longas não bloqueiam o loop de leitura — as requests despacham concorrentemente, que é o que faz o cancelamento funcionar.
chatcli acp
Um servidor Agent Client Protocol completo: sessões com modos chat/agent/coder, tool calls e plano estruturados, slash commands e dialogs nativos de permissão da IDE — o caminho para rodar o ChatCLI dentro de IDEs JetBrains e do Zed.
- Updates estruturados — runs de agent/coder emitem frames nativos
tool_call/tool_call_update,agent_thought_chunkeplan; a IDE renderiza tool calls colapsáveis e um plano ao vivo em vez de um transcript em stream. - Slash commands —
/coder,/config,/modele uma allowlist headless são anunciados ao cliente e funcionam da caixa de prompt da IDE. - Dialogs de permissão — comandos perigosos e regras
askda política de segurança disparamsession/request_permission(Allow/Reject nativo na IDE) em vez de auto-aprovar/bloquear cego. - Cancelamento —
session/cancelinterrompe um prompt em voo e fecha qualquer tool call aberta. - Restauração de sessão —
session/load(capabilityloadSession: true) traz de volta um session id anterior (estado vivo, ou o espelho de autosavemcp-<id>após restart) e faz replay da conversa no cliente; o/sessionda caixa de prompt opera por sessão e vincula a sessões nomeadas para continuidade cross-surface.
~/.jetbrains/acp.json, agent_servers do Zed), a superfície de comandos, o modelo de segurança e os detalhes do protocolo vivem na página dedicada: ACP — ChatCLI dentro da sua IDE.
Veja também
- ACP — ChatCLI dentro da sua IDE — o servidor ACP a fundo: setup de IDE, slash commands, dialogs de permissão
- MCP Integration — ChatCLI como cliente MCP, incluindo o
chatcli mcp add - Variáveis de Ambiente —
LLM_PROVIDER,LLM_MODEL,CHATCLI_MCP_TOOLS - Referência de Comandos — subcomandos externos