MCP (Model Context Protocol)

Antes desse padrão, todo aplicativo que quisesse dar a um modelo acesso a uma agenda, um banco de dados ou um repositório precisava escrever seu próprio conector. O MCP divide o trabalho em dois. Um servidor envolve uma capacidade, como um sistema de arquivos ou um gerenciador de chamados, e descreve o que oferece. Um cliente, dentro do aplicativo de IA, descobre essa descrição e a repassa ao modelo, que então pode chamar essas capacidades. Os servidores podem oferecer ferramentas que executam ações, recursos que fornecem dados para leitura e prompts que reúnem instruções prontas. Servidores típicos conectam agenda, notas, rastreador de bugs, planilha, banco de dados, e-mail, repositório de código ou navegador, todos expostos do mesmo jeito previsível. Recursos podem ser arquivos, linhas de tabelas, capturas de tela ou logs; prompts, modelos como uma lista de revisão de código ou um resumo de reunião. Pense numa gaveta de carregadores incompatíveis trocada por uma tomada universal.

Os servidores rodam na sua própria máquina, conversando com o aplicativo por entrada e saída padrão, ou remotamente por HTTP. É outra camada, distinta da chamada de ferramentas. Pela chamada de ferramentas, o modelo pede uma função numa requisição; pelo MCP, o aplicativo encontra e alcança, antes de tudo, muitas dessas funções. O aplicativo costuma traduzir as ferramentas MCP descobertas em definições de ferramentas comuns para o modelo, de modo que os dois se complementam, e o modelo nunca se conecta diretamente a um servidor. Servidores remotos levantam ainda a questão da autenticação: descubra como um servidor prova quem o está chamando e onde suas credenciais vão parar. Um auxiliar local serve para a primeira opção; um serviço compartilhado de equipe, para a segunda.

Essa comodidade traz riscos que merecem atenção. Um servidor pode ler e alterar tudo a que você der acesso, e um malicioso ou descuidado pode vazar dados ou disparar ações prejudiciais. Descrições e resultados vindos de um servidor são texto que o modelo lê, então podem esconder instruções para dirigi-lo. Instale servidores de fontes confiáveis, conceda as permissões mais estreitas, revise o que cada ferramenta faz e prefira pedidos de aprovação para tudo o que grava, envia ou apaga. Um bom hábito é ler as ferramentas que um servidor anuncia antes de ativá-lo, como as permissões de um app de celular. A armadilha mais conhecida é a injeção de prompt, em que um resultado envenenado manda o modelo vazar um arquivo.

Sendo preciso sobre o que existe hoje: nas Missões, o NeverNo pode se conectar a um servidor MCP remoto que você mesmo adiciona (endereço e token opcional), enquanto a API não hospeda servidores MCP nem se conecta a eles por conta própria. A API oferece chamada de funções nas completions de chat, em que o seu próprio código define e executa as ferramentas, além de um endpoint Messages compatível com a Anthropic. Os modelos cujo capabilities.tools é true na lista /models aceitam ferramentas.

Uma ferramenta sua que fale MCP ainda pode usar o NeverNo como modelo, apontando seu endereço base para https://neverno.ai/api/v1, já que os endpoints seguem os formatos da OpenAI e da Anthropic. As conexões MCP ficam então nessa ferramenta, não no NeverNo. O DeepSeek V4 Flash, um modelo privado e gratuito com janela de contexto de 128.000 tokens, é um dos modelos da lista.