Skip to main content
Além de ser um cliente MCP (consumir ferramentas externas — ver MCP Integration), o ChatCLI também pode ser um servidor: outros agentes/clientes — Claude Code, Claude Desktop, IDEs, editores, até outro ChatCLI — podem dirigir o ChatCLI via protocolo.
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 (alias mcp-serve) — servidor MCP (Model Context Protocol). Negocia a revisão 2025-03-26 ou 2024-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 readOnlyHint derivada 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 via prompts/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 capability elicitation 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

Ou em um config JSON:
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_chunk e plan; a IDE renderiza tool calls colapsáveis e um plano ao vivo em vez de um transcript em stream.
  • Slash commands/coder, /config, /model e uma allowlist headless são anunciados ao cliente e funcionam da caixa de prompt da IDE.
  • Dialogs de permissão — comandos perigosos e regras ask da política de segurança disparam session/request_permission (Allow/Reject nativo na IDE) em vez de auto-aprovar/bloquear cego.
  • Cancelamentosession/cancel interrompe um prompt em voo e fecha qualquer tool call aberta.
  • Restauração de sessãosession/load (capability loadSession: true) traz de volta um session id anterior (estado vivo, ou o espelho de autosave mcp-<id> após restart) e faz replay da conversa no cliente; o /session da caixa de prompt opera por sessão e vincula a sessões nomeadas para continuidade cross-surface.
Setup completo (JetBrains ~/.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