Visão Geral
1
Carrega configuração
O MCP Manager carrega a configuração de servidores MCP.
2
Inicia servidores
Inicia os servidores configurados (stdio, SSE ou Streamable HTTP).
3
Descobre ferramentas
Descobre as ferramentas disponíveis em cada servidor.
4
Expoe ao modelo
Expoe as ferramentas ao modelo de IA como
ToolDefinition.5
Roteia chamadas
Roteia chamadas de ferramentas para o servidor correto.
Configuração
O subcomando chatcli mcp (recomendado)
Gerencie servidores pelo shell — mesma experiência do claude mcp add, escrevendo em ~/.chatcli/mcp_servers.json atomicamente (chaves de extensão mantidas à mão sobrevivem ao rewrite; re-adicionar um nome substitui a entrada):
add: --cwd DIR (diretório de trabalho do stdio), --description TEXTO, --disabled (adiciona sem habilitar).
Arquivo de Configuração
Crie~/.chatcli/mcp_servers.json:
Capacidades estendidas do servidor
Além do mínimo (name, command, args, env, transport, enabled, overrides), o entry de cada servidor aceita um conjunto de campos opt-in cobrindo os mesmos casos suportados por Claude Code, Cline, Cursor e AWS EKS MCP — auto-aprovação de tools, filtragem enabledTools/disabledTools, timeouts próprios, working directory, headers HTTP custom e autenticação HTTP (bearer/basic/header, compartilhada por sse e http), além de metadados (description, tags, category) que aparecem em /mcp status.
Qualquer chave fora do schema tipado é preservada verbatim no round-trip (catch-all Extensions), então copiar uma config de outro cliente funciona sem perder anotações vendor-specific.
Referência completa com semântica, exemplos e troubleshooting: Configuração de MCP Servers.
Variáveis de Ambiente
Via Flag do Servidor
Transportes
- stdio
- SSE (HTTP+SSE)
- http (Streamable HTTP)
O transporte Uso: Servidores locais distribuidos como pacotes npm, binarios standalone ou scripts.
stdio inicia um processo local e se comunica via stdin/stdout usando JSON-RPC 2.0:Autorização OAuth 2.1 (servidores remotos)
Servidores MCP remotos (http/sse) cada vez mais protegem o acesso com OAuth 2.1 em vez de um token estático — o servidor MCP da AWS é o caso motivador. O ChatCLI suporta isso de ponta a ponta e não precisa de client ID, secret ou endpoints na sua config: tudo é descoberto em runtime.
Quando um servidor responde a uma requisição com 401 e um desafio OAuth, o ChatCLI:
1
Descobre o authorization server
Lê o header
WWW-Authenticate, busca a Protected Resource Metadata (RFC 9728) e então a Authorization Server Metadata (RFC 8414) para aprender os endpoints de authorization, token e registro.2
Registra um cliente dinamicamente
Registra um cliente público PKCE via Dynamic Client Registration (RFC 7591) — você nunca cola um
client_id.3
Roda o fluxo no navegador
Abre o navegador para o fluxo authorization-code + PKCE via callback no localhost, vinculando o token ao servidor pelo resource indicator (RFC 8707).
4
Guarda e renova o token
Persiste os tokens de acesso/refresh no cofre de auth criptografado (AES-256-GCM, o mesmo do
/auth login) e os renova de forma transparente daí em diante.Autorizando um servidor
Com um servidor remoto configurado, autorize-o de duas formas:/mcp status mostra um servidor aguardando autorização com o estado 🔒 authorization required e uma dica de login. Após um login bem-sucedido o servidor reconecta e suas ferramentas mcp_* ficam disponíveis.
Quando o refresh token expira
Refresh tokens eventualmente morrem no lado do servidor (o sign-in da AWS retornaTOKEN_EXPIRED; servidores OAuth padrão retornam invalid_grant). O ChatCLI trata esses erros como terminais: a renovação automática para imediatamente em vez de retentar para sempre, a falha fica registrada para que as chamadas de tool falhem rápido sem round-trips extras, e o servidor é marcado 🔒 authorization required — mesmo no meio da sessão, muito depois do handshake inicial. As chamadas de tool exibem a dica acionável do @mcp-login (o agent consegue se reautorizar sozinho, abrindo seu navegador), e um /mcp login <nome> recupera manualmente. Falhas transitórias (oscilações de rede, 5xx) mantêm o comportamento normal de retry.
Nenhuma mudança de config é necessária para um servidor OAuth — basta adicioná-lo como um servidor
http/sse normal (chatcli mcp add --transport http aws-mcp https://…/mcp). A primeira chamada de tool dispara o pedido de autorização. Para fixar a porta do callback loopback (para allowlists estritas de redirect-URI), defina CHATCLI_MCP_OAUTH_PORT (padrão 8765; cai numa porta efêmera se estiver ocupada).bearer/basic/header documentada acima continua valendo para servidores que aceitam um token já emitido; o OAuth é usado apenas quando um servidor ativamente o exige.
Nomeacao de Ferramentas
Ferramentas MCP são automaticamente prefixadas commcp_ e recebem a descrição do servidor de origem:
O prefixo
mcp_ evita colisões com ferramentas nativas do ChatCLI.Overrides de Built-ins (Shadow + Fallback)
Quando um servidor MCP oferece uma ferramenta que substitui um plugin nativo (ex:@webfetch, @websearch), use o campo overrides para declarar quais built-ins ele substitui. O ChatCLI esconde automaticamente os built-ins listados enquanto o servidor MCP estiver conectado. Se o servidor desconectar, os built-ins são restaurados imediatamente — o usuário nunca perde a capacidade.
Por que usar overrides?
Semoverrides, o LLM vê duas ferramentas que fazem a mesma coisa (ex: @webfetch e mcp_web_fetch) e escolhe aleatoriamente. Com overrides, o comportamento é determinístico: o LLM só vê a ferramenta MCP, sem ambiguidade.
Configuração
Adicioneoverrides na configuração do servidor MCP:
- CLI (mcp_servers.json)
- Helm (values.yaml)
- Operator (Instance CRD)
Como funciona
O sync de shadow acontece a cada turno de conversa, não apenas no startup. Isso significa que se o MCP server cair no meio de uma conversa, os built-ins voltam na próxima mensagem — sem restart necessário.
Regras importantes
Deploy via Helm
- Servidores MCP Inline
- ConfigMap Existente
mcp_servers.json e monta em /etc/chatcli/mcp/.
Deploy via Operator (Instance CRD)
Quando usando o ChatCLI Operator, configure MCP diretamente no recursoInstance:
- Gera um ConfigMap
<instance>-mcpcommcp_servers.json - Monta em
/etc/chatcli/mcp/(read-only) - Passa
--mcp-config /etc/chatcli/mcp/mcp_servers.jsonao container
O CRD
MCPSpec espelha exatamente o formato do mcp_servers.json. Cada campo do MCPServerSpec corresponde a um campo do JSON — incluindo overrides para shadow de built-ins.Verificando Status
O MCP Manager expoe o status de cada servidor:Servidores MCP Populares
MCP no Modo Client (TTY)
Desde a versão mais recente, o MCP funciona diretamente no modo interativo (TTY), não apenas no modo servidor.
O ChatCLI auto-detecta o arquivo
~/.chatcli/mcp_servers.json e inicializa os servidores automaticamente ao iniciar.Deferred Schemas (Economia de Tokens)
Para economizar tokens no system prompt, o ChatCLI usa deferred schemas:- Apenas nome + descrição são enviados no prompt (lightweight)
- Antes do primeiro uso, o modelo consulta o catálogo com
@tools describee recebe o bloco completo: servidor de origem, descrição, JSON Schema de parâmetros e forma de invocação - O modelo invoca com os argumentos corretos
@tools list também indexa as tools MCP junto com as builtins, agrupadas por servidor de origem — cada entrada carrega a tag [MCP:servidor], então o modelo sempre sabe de qual servidor a tool vem.
Como fallback, se o modelo invocar uma tool MCP sem os parâmetros obrigatórios, o schema completo é retornado como feedback para correção.
Descrições no índice são limitadas: a descrição de cada tool no índice do system prompt é reduzida à primeira linha, com teto de 160 caracteres. Servidores MCP corporativos trazem descrições de vários parágrafos — com 100+ tools conectadas, só as descrições sem clamp somam dezenas de KB a cada requisição, exatamente o piso de payload que estoura limites de corpo de proxy/WAF corporativo (veja Context Recovery). A descrição completa e o schema continuam a um @tools describe de distância.
Dynamic tool discovery
Alguns servidores MCP têm uma lista de tools dinâmica (a capabilitytools.listChanged): conectam expondo um catálogo mínimo e o expandem em runtime. O HTTP Toolkit é o caso canônico — expõe só start ao conectar, e depois que o start roda ele registra as tools reais e emite uma notificação notifications/tools/list_changed.
O ChatCLI trata isso de ponta a ponta:
- A notificação dispara um refresh debounced por servidor (rajadas coalescem numa única chamada
tools/list). O refresh roda de forma assíncrona — um round-trip síncrono a partir da goroutine leitora do transport causaria deadlock no pump de resposta. - O registry é reconciliado: tools novas adicionadas, schemas alterados substituídos, tools que sumiram removidas — tocando apenas as tools daquele servidor.
- No próximo turn boundary o agente é avisado do que mudou, para usar as tools novas imediatamente:
@tools describe antes do primeiro uso. Dispatch de tools, @tools list/describe e o completer leem o registry vivo, então a mudança fica visível em todo lugar de uma vez. O evento tools/list_changed também é registrado no inbox de canais para auditoria — mas, como evento de protocolo tratado, não incha o contador de unread.
Controlado por CHATCLI_MCP_DYNAMIC_TOOLS (default ligado); aparece em /config integrations.
Comando /mcp
Gerencie servidores MCP diretamente do terminal interativo. Todos os subcomandos que aceitam um nome de servidor têm autocomplete — pressione Tab após /mcp <subcomando> para listar os servidores configurados.
Exemplo: status e logs
Semântica de start/stop
A diferença entre
/mcp restart e /mcp reload:/mcp restartforça um restart mesmo se a config não mudou (útil para “recarregar credentials” após editar shell env)./mcp reloadé um diff-and-apply contramcp_servers.json— não reinicia nada que não tenha mudado.
Buffer de logs por servidor
Cada servidor stdio mantém um ring buffer de 200 linhas alimentado pelo stderr do processo filho. Isso significa que:/mcp logs <nome>mostra as últimas 200 linhas sem precisar de--debug;- Servidores muito tagarelas não consomem memória ilimitada — linhas antigas saem do início;
- Capturas como
npm 404, panic stacks e mensagens de inicialização ficam disponíveis mesmo após o startup terminar.
Push notifications — MCP Channels
Além de tools (request/response), o ChatCLI aceita push notifications de qualquer servidor MCP nos três transports. Notifications são mensagens JSON-RPC semid (a forma que a spec reserva para “o server quer me dizer algo, não pediu nada em troca”). O ChatCLI captura, persiste e injeta automaticamente nas próximas conversas, e — opcionalmente — aciona o agent via rules de trigger.
O essencial
- Funciona em
stdio,sseehttp— cada transport tem seu próprio listener:sse: o GET/sseque já carrega tool responses recebe notifications no mesmo stream.http: um GET separado no endpoint (opt-in pelo cliente, opcional pela spec) puxa notifications. Servidores que não suportam respondem 405/404/501 e o listener para limpo, sem retry.stdio: linhas JSON-RPC no stdout semidsão tratadas como notifications.
- Persistência durável em
~/.chatcli/mcp/channels.jsonl(até 10 MiB, rotaciona, recarrega no boot). - Auto-injection das 5 mais recentes no system prompt de
chat/agent/coder(uncached pra não trashar cache). - Filtro per-server: campo
channelsemmcp_servers.jsonaceita allow-list literal. - Rules engine opcional em
~/.chatcli/mcp/triggers.jsoncom 3 modos:notify(banner discreto, default),confirm(yes/no manual),auto(executa o agent — requer whitelist de tools). - Slash commands:
/channel list,/channel ack,/channel pause,/channel rules,/channel confirm <id>,/channel run <seq>,/channel inject.
Exemplo mínimo — server com channels
/channel list, aparecem no banner do próximo prompt e são injetados automaticamente no contexto do agent.
Exemplo — trigger que investiga falhas de CI
~/.chatcli/mcp/triggers.json:
/channel confirm <id> aceita e o agent começa a investigar.
Documentação completa de channels, rules e troubleshooting: MCP Channels. Schema completo do campo
channels e referência do triggers.json: MCP Config.Próximos passos
MCP Channels
Push messages dos três transports (
stdio, sse, http) com persistência durável, filtro por servidor e rules engine (notify/confirm/auto).Plugins agênticos
Sistema de plugins do ChatCLI — comparativo com MCP.
Tool Use Nativo
APIs nativas Anthropic/OpenAI que potencializam MCP.
Configuração MCP
Formato completo de
mcp_servers.json e exemplos.