Skip to main content
O MCP (Model Context Protocol) e um protocolo aberto para interoperabilidade de ferramentas com modelos de IA. O ChatCLI integra com servidores MCP, permitindo que a IA acesse ferramentas externas como sistema de arquivos, buscas web, bancos de dados e qualquer serviço compatível.

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):
Outros flags do 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

O transporte stdio inicia um processo local e se comunica via stdin/stdout usando JSON-RPC 2.0:
Uso: Servidores locais distribuidos como pacotes npm, binarios standalone ou scripts.

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:
O /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 retorna TOKEN_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).
A autenticação estática 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 com mcp_ 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?

Sem overrides, 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

Adicione overrides na configuração do servidor MCP:

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

O campo overrides não desinstala nem modifica o plugin built-in. Ele apenas o esconde do prompt do LLM. O plugin continua disponível internamente e volta automaticamente quando necessário. Isso é shadow, não delete.

Deploy via Helm

O Helm chart cria automaticamente um ConfigMap com o mcp_servers.json e monta em /etc/chatcli/mcp/.

Deploy via Operator (Instance CRD)

Quando usando o ChatCLI Operator, configure MCP diretamente no recurso Instance:
Ou referencie um ConfigMap existente:
O controller automaticamente:
  1. Gera um ConfigMap <instance>-mcp com mcp_servers.json
  2. Monta em /etc/chatcli/mcp/ (read-only)
  3. Passa --mcp-config /etc/chatcli/mcp/mcp_servers.json ao 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:
Para verificar se uma ferramenta e MCP:

Servidores MCP Populares

Consulte modelcontextprotocol.io para a lista completa de servidores MCP disponíveis.

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.
As ferramentas MCP são expostas nos 3 modos do ChatCLI:

Deferred Schemas (Economia de Tokens)

Para economizar tokens no system prompt, o ChatCLI usa deferred schemas:
  1. Apenas nome + descrição são enviados no prompt (lightweight)
  2. Antes do primeiro uso, o modelo consulta o catálogo com @tools describe e recebe o bloco completo: servidor de origem, descrição, JSON Schema de parâmetros e forma de invocação
  3. 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.
Isso pode economizar centenas de tokens por turno quando há muitas ferramentas MCP conectadas — e com servidores corporativos verbosos, dezenas de KB por requisição.

Dynamic tool discovery

Alguns servidores MCP têm uma lista de tools dinâmica (a capability tools.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:
  1. 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.
  2. O registry é reconciliado: tools novas adicionadas, schemas alterados substituídos, tools que sumiram removidas — tocando apenas as tools daquele servidor.
  3. No próximo turn boundary o agente é avisado do que mudou, para usar as tools novas imediatamente:
O modelo recebe os nomes das tools adicionadas/removidas e o lembrete de fazer @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 restart forç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 contra mcp_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.
Combinação útil para diagnosticar conexão: /mcp status (estado), depois /mcp logs <nome> (o motivo). Sem precisar reiniciar com CHATCLI_LOG_LEVEL=debug.

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 sem id (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, sse e http — cada transport tem seu próprio listener:
    • sse: o GET /sse que 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 sem id são tratadas como notifications.
  • Persistência durável em ~/.chatcli/mcp/channels.jsonl (até 10 MiB, rota­ciona, 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 channels em mcp_servers.json aceita allow-list literal.
  • Rules engine opcional em ~/.chatcli/mcp/triggers.json com 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

Com isso, alerts caem em /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:
Cada falha de CI cita o user com um prompt no banner; /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.