Quando se fala em agentes de inteligência artificial hoje em dia, quase todo mundo pensa em chatbots web fechados ou em scripts rodando soltos no terminal. A pergunta que sempre me faço antes de adotar qualquer ferramenta é bem direta: eu tenho o controle real do que esses agentes estão executando na minha máquina, de onde os dados passam e de como esse aplicativo foi construído?
Foi com essa curiosidade que decidi testar o Tucano.sh (código aberto no GitHub). Ele se propõe a ser um cliente desktop nativo para gerenciar, criar e orquestrar agentes de IA com suporte a múltiplos provedores e ao protocolo MCP (Model Context Protocol).
Neste texto, compartilho minhas anotações práticas de uso: o que me impressionou positivamente, os atritos reais que encontrei na configuração e os testes práticos de controle de aplicativos do sistema operacional.
Identidade visual e primeiras impressões#
A primeira coisa que salta aos olhos no projeto é o cuidado gráfico. O Tucano tem uma das interfaces mais bonitas e limpas que vi recentemente em ferramentas de IA. É simples, agradável e você bate o olho entendendo a hierarquia das informações em poucos segundos. Lembra muito o padrão de acabamento visual que desenvolvedores refinados costumam aplicar em produtos modernos.
O projeto disponibiliza instaladores para os três principais sistemas operacionais:
- Windows (instalador
.exex86/64) - macOS (pacote
.dmg) - Linux (formatos
.AppImagee.deb)
Para os meus testes, baixei a versão Linux em AppImage, que já vem empacotada com todas as dependências e roda direto sem poluir o sistema.
O onboarding inicial e a configuração de provedores#
Ao abrir o aplicativo pela primeira vez, ele exibe uma introdução animada com o mascote do tucano e alguns personagens estilizados de agentes com rostos quadrados e coloridos (lembrando um pouco a identidade visual dos mascotes da Anthropic/Claude).
Assim que a animação termina, o aplicativo pergunta como os agentes devem me chamar e já apresenta uma prévia lateral de como a tela de chat vai funcionar. Digitei meu nome e cliquei em começar.
Na tela seguinte surgem as configurações de modelos. Aqui senti meu primeiro ponto de atrito: a quantidade de opções simultâneas pode assustar quem está chegando agora. Na minha visão, faria mais sentido destacar três grandes provedores de cara e deixar um aviso claro dizendo que é possível adicionar outros mais tarde.
Por outro lado, o app teve um ponto muito positivo: ele detectou automaticamente o OpenCode na minha máquina local e me permitiu selecionar o modelo padrão ali mesmo.
Ao clicar para autenticar contas externas, reparei em um detalhe técnico curioso: o aplicativo abriu o fluxo de login em uma sessão isolada, sem herdar os cookies ou o login que eu já tinha ativo no meu navegador padrão. Tive que fazer login com a minha conta Google novamente para conectar ao Codex.
Outro ponto que me fez falta nessa etapa foi uma barra de busca na lista de modelos. Para encontrar um modelo gratuito no OpenRouter, precisei rolar manualmente uma lista imensa de opções até achar o que eu queria.
A tela seguinte traz uma sacada que achei excelente: a separação entre o modelo que decide e o modelo que responde. Isso dá uma flexibilidade enorme para usar um modelo mais rápido para raciocínio e outro mais detalhista para a resposta final. Porém, a ausência de um campo de busca me fez perder tempo novamente rolando listas compridas. Mudei a configuração para Gemini 3.8 e segui adiante.
Em seguida, o app pede algumas informações sobre o perfil do usuário para compor o contexto inicial dos agentes. Preenchi com uma breve descrição do meu dia a dia e continuei.
Conectando MCP e importando skills#
Chegando na etapa de integrações, o Tucano pergunta para quais agentes eu gostaria de disponibilizar servidores MCP.
Como estou desenvolvendo o NEXUS (que conta com um servidor MCP próprio), aproveitei para conectar a URL e o token do meu ambiente local. O aplicativo conectou sem qualquer complicação.
Para validar a integração na prática, pedi para o Tucano ler as ferramentas e recursos expostos pelo servidor MCP do NEXUS. Ele executou a leitura de todas as ferramentas e esquemas sem qualquer dificuldade.
Na tela posterior, o sistema permite importar as skills que o usuário já utiliza. Bastou marcar os itens desejados na lista e clicar em importar.
Criando o primeiro agente#
A etapa de criação de agente é muito ágil. Pedi para o sistema gerar um assistente focado em listar eventos culturais e acontecimentos da cidade.
O sistema processou o pedido rapidamente e gerou a estrutura do agente.
Ao selecionar o agente criado, o aplicativo abre uma tela de permissões detalhadas: você define se ele roda isolado, quais ferramentas do sistema ele pode acionar e a quais servidores MCP ele tem acesso.
Definidas as permissões, o app perguntou qual tarefa inicial o assistente deveria executar e finalmente me levou para a área de trabalho principal.
A rotina na tela principal e o teste de controle de tela#
Logo no primeiro contato com a tela principal, senti falta de algo que uso o tempo todo no OpenBot: um seletor rápido de modelo diretamente na barra superior.
No Tucano, para alternar o modelo ativo da conversa precisei clicar no modelo, rolar a página inteira de configurações do agente e só lá embaixo encontrar o seletor. É um detalhe de usabilidade que cansa quando você testa respostas comparativas entre provedores diferentes.
Ainda na tela de ferramentas do agente, encontrei a opção de conceder acesso aos aplicativos da máquina. Para habilitar essa funcionalidade, o aplicativo solicita a instalação do componente agent-desktop. A instalação foi rápida e descomplicada.
Com o controle liberado, decidi testar os limites práticos da capacidade de visão e controle do agente sobre janelas virtualizadas no Linux:
- Teste com Waydroid (virtualização Android): Liberei o acesso ao Waydroid para ver se o agente conseguia interagir com jogos ou interfaces móveis. Ele conseguiu disparar e abrir o Waydroid, mas não identificou o conteúdo que estava sendo renderizado dentro da janela virtualizada. Pedi para ele ler o que aparecia na tela (abri o Chrome com meu site local), mas ele permaneceu em processamento e não conseguiu enxergar o conteúdo gráfico. Para tirar a dúvida, fiz o mesmo teste no OpenBot: o OpenBot tentou depurar o processo no Waydroid, mas acabou entrando em loop. Ou seja, ambos os sistemas ainda sofrem para lidar com camadas de renderização gráfica virtualizadas.
- Teste com Steam: Liberei o aplicativo da Steam e pedi ao agente para abrir o jogo Epic Seven. Ele abriu o cliente da Steam corretamente, mas se perdeu ao tentar localizar e iniciar o jogo específico. Ao pedir para ele descrever o que estava visível na tela da Steam, a resposta demorou bastante e ele informou que não conseguiu ler os elementos. No OpenBot, esse mesmo teste de leitura da tela da Steam funcionou e ele conseguiu listar os elementos da interface.
Diferente do Openbot o qual conseguiu ler a tela do Steam e identificar os botões, o Tucano não conseguiu ler a tela e ficou preso em um loop tentando identificar os elementos.
Esses testes mostram que, embora a proposta de controle de desktop seja muito promissora, a integração com janelas complexas ou aceleradas por hardware ainda está nos estágios iniciais na maioria dos clientes locais.
Recursos adicionais do sistema#
Navegando pelas seções laterais do Tucano, encontrei módulos bem pensados para organização:
- Aprovações: Centraliza as ações que exigem confirmação do usuário antes que o agente execute algo potencialmente sensível.
- Memória: Painel onde você visualiza e edita tudo o que os agentes armazenaram a respeito das suas preferências e histórico.
- Wiki: Espaço para documentação interna, servindo de base de conhecimento para os agentes consultarem durante tarefas.
- Rotinas: Agendamento e automação de tarefas periódicas.
- Skills: Catálogo de extensões instaladas e disponíveis.
- Boletim: Painel de resumo das atividades recentes de cada agente.
Mais abaixo, duas abas merecem destaque:
- Uso e limites: Gráficos claros de consumo de tokens, contagem de requisições e histórico das IAs utilizadas.
- Conectores: Este é um dos pontos altos do software. Além de conectar servidores MCP customizados com facilidade, ele traz uma lista pronta de conectores populares fáceis de plugar.
Nas configurações gerais, você encontra opções para alternar workspaces, idioma, gerenciar modelos e provedores, configurar canais de notificação (como Telegram e GitHub) e conectar instâncias remotas de servidores Tucano.
O saldo dessa primeira experiência#
Colocando tudo na balança, o Tucano é uma grata surpresa no ecossistema open source. Ele entrega gratuitamente uma interface moderna, organizada e que não cobra assinaturas extras para você usar seus próprios modelos e servidores locais. O aplicativo segura a mão do usuário desde a primeira abertura até a criação do primeiro assistente funcional.
Os principais pontos que merecem evolução nas próximas versões são:
- Filtro de busca em listas de modelos: É cansativo rolar dezenas de itens para achar modelos específicos.
- Troca rápida de modelo na barra superior: Essencial para o fluxo diário de conversa sem precisar abrir telas secundárias.
- Didática do onboarding para leigos: Quem já conhece termos como MCP, endpoint e tokens se vira bem, mas um usuário comum pode travar logo nas primeiras etapas se não houver um modo simplificado com padrões pré-configurados.
Minha nota geral para o aplicativo nesta fase é 8/10. O projeto tem uma base muito sólida, uma identidade visual excelente e muito potencial para amadurecer. Vale a pena acompanhar o repositório oficial no GitHub e experimentar na sua própria máquina.
Este artigo foi útil?
Deixe uma reação rápida para apoiar o conteúdo:
Veja também
Este post está licenciado sob CC BY-NC.
Comentários
Participe da discussão abaixo.
0 comentários