1
filterproconsultoria
4 min de leitura ·

Fiz um conector MCP em português para organizar trabalho com clientes no Claude: o que aprendi

Nos últimos meses, acompanhei um padrão repetido no uso de IA: o profissional assina o Claude ou o ChatGPT, abre uma conversa em branco, cola notas de reunião ou um PDF de cliente e pede um "resumo". O resultado costuma ser o de sempre — verbos no infinitivo como "deve-se revisar a planilha", nenhuma definição nominal de quem faz o quê e ideias descartadas no meio do papo promovidas a "decisões aprovadas".

Quem atende vários clientes (em contabilidade, advocacia, consultoria ou engenharia) logo bate no teto dessa abordagem. Sem estrutura, a IA vira uma máquina de gerar retrabalho.

Quando a Anthropic anunciou a especificação aberta do Model Context Protocol (MCP), vi ali a chance de resolver essa fricção na raiz: em vez de esperar que o usuário cole prompts gigantescos a cada nova conversa, por que não conectar um servidor que injeta regras operacionais, modelos de entregáveis e procedimentos padronizados diretamente no contexto do modelo?

Foi assim que nasceu o PRAXIS, um conector MCP desenvolvido em português do Brasil. O conector foi aprovado no diretório de conectores do Claude em 28/09/2026, publicado em 30/09 e registrado no registro oficial do MCP em 06/10/2026.

Compartilho aqui os bastidores técnicos e as decisões de arquitetura para colocar um conector MCP em produção.

1. A escolha do transporte: por que Streamable HTTP em vez de stdio

A maioria dos tutoriais de MCP foca no transporte stdio — processos de linha de comando rodando localmente na máquina do desenvolvedor, comum em integrações com VS Code ou Cursor.

Para quem usa o Claude no navegador ou no aplicativo desktop/mobile tradicional, o stdio não funciona. O usuário de negócios não quer abrir um terminal nem rodar contêineres Docker para falar com a IA. Ele precisa de um conector remoto, registrado nas configurações do assistente com poucos cliques.

Adotamos o transporte remoto Streamable HTTP, em JavaScript, rodando num Cloudflare Worker. A arquitetura precisava ser leve, stateless e com latência mínima, já que a cada chamada de ferramenta o assistente faz um round-trip completo até o servidor remoto antes de sintetizar a resposta.

2. O dilema da autenticação em conectores remotos

No diretório do Claude, servidores remotos expostos a usuários finais exigem OAuth.

Como o PRAXIS opera sob um modelo de assinatura de software, desenhamos o fluxo de autorização onde o usuário recebe um token de licença (px_...) por e-mail e, ao clicar em conectar no Claude, é redirecionado para a tela web do PRAXIS. Lá ele valida seu token e a sessão do conector é vinculada de forma transparente, sem expor chaves de API sensíveis nem exigir senhas complexas.

3. A regra de ouro da privacidade (LGPD e sigilo)

Aqui esteve a decisão arquitetural mais importante do projeto.

Quem atende clientes lida com contratos, balancetes fiscais e dados sigilosos. Se o nosso conector recebesse o texto desses documentos para "processar", nós nos tornaríamos operadores de dados sensíveis, criando um risco inaceitável de segurança e LGPD para os escritórios.

Por isso, desenhamos uma separação estrita de responsabilidades:
"Seus documentos não passam pelo servidor do PRAXIS. Ele entrega regras, modelos e procedimentos; quem lê o seu material é a IA que você já usa."

O servidor MCP expõe 7 ferramentas estritamente de leitura (read-only):

  • praxis_organizacao: regras de formatação e conduta adaptadas ao segmento;
  • praxis_modelo: matrizes de entregáveis (atas executivas, diagnósticos, planos de ação, relatórios);
  • praxis_skill: catálogo de 131 procedimentos operacionais prontos em 10 áreas;
  • praxis_exemplo: projeto de referência totalmente estruturado;
  • praxis_ajuda: comandos, guias de continuidade e suporte;
  • praxis_licenca: verificação de status da licença e versão;
  • praxis_sugestao: canal direto para envio de feedbacks ao desenvolvedor.

Quando o usuário pede para o Claude estruturar uma ata, o Claude chama o PRAXIS via conector, recebe o modelo e as restrições de inferência, e executa o processamento do texto bruto ali mesmo, na conversa dele. Nada do cliente trafega para o nosso backend. O que é produzido fica na tela do usuário para copiar ou salvar.

Escrevi mais sobre isso no artigo como usar IA com documentos de clientes com segurança.

4. Claude Web vs Claude Code: duas formas de trabalhar

Percebemos rapidamente que o perfil do usuário dita a experiência de uso:

  • No Claude Web/App (pelo conector MCP): tudo acontece na interface conversacional. É a escolha preferida de consultores, advogados e contadores para resolver uma reunião ou documento pontual.
  • No Claude Code: quem prefere manter arquivos em disco usa um plugin que organiza uma pasta local no computador. Assim, o histórico e o estado das pendências permanecem salvos em Markdown local, permitindo que a sessão seguinte continue exatamente de onde a anterior parou.

5. O que aprendi na revisão da Anthropic

Preparar um conector para o diretório do Claude é um ótimo exercício de engenharia. Três lições práticas para quem for construir um servidor MCP:

  1. Nomes e descrições das ferramentas importam mais do que código: o modelo decide qual tool chamar baseado no texto do campo description. Seja cirúrgico e descritivo.
  2. Evite ferramentas que façam "mágica" demais: quebre em funções atômicas e previsíveis.
  3. Tratamento rigoroso de erros: se o servidor retornar um erro mal formatado, a sessão da IA trava.

Conclusão

O ecossistema MCP ainda está no começo, mas resolve a maior deficiência dos assistentes modernos: transformar IAs de brinquedos de chat em ferramentas integradas ao fluxo operacional sério.

Se você quiser conhecer o produto no ar e testar a organização no Claude, acesse: https://praxis.filterpro.dev.br

Carregando publicação patrocinada...