O MCP não morreu, mas não é mais a resposta padrão. Este artigo compara servidores MCP com CLIs, arquivos de habilidades e APIs diretas, mostra onde servidores remotos ainda levam vantagem em autenticação, tarefas longas e trilhas de auditoria, e termina com um checklist de cinco minutos que você pode usar hoje.
A cada poucos meses alguém publica que o MCP está morto, e a cada poucos meses uma equipe leva mais um servidor MCP para produção. As duas coisas são verdadeiras ao mesmo tempo. Os modelos ficaram muito melhores em executar comandos de shell, ler documentação e escrever scripts pequenos, então muitas das razões iniciais para encapsular cada ferramenta em um protocolo perderam força. Mesmo assim, alguns trabalhos ainda precisam de uma interface padronizada, autenticada e remota, à qual qualquer agente possa se conectar sem cola personalizada. Este artigo separa os dois grupos. Você vai ver onde uma CLI simples ou um arquivo de habilidades supera um servidor MCP, onde o servidor ainda ganha e como decidir em cerca de cinco minutos.
O Model Context Protocol, ou MCP, é um padrão aberto que a Anthropic lançou em novembro de 2024. Ele define como uma aplicação de IA (o cliente) pede a um programa separado (o servidor) três coisas: ferramentas que ela pode chamar, recursos que ela pode ler e prompts que ela pode reutilizar. As mensagens trafegam como JSON-RPC, por entrada e saída padrão em servidores locais, ou por Streamable HTTP em servidores remotos. OpenAI e Google adotaram o protocolo em 2025, e depois ele passou para a Agentic AI Foundation, da Linux Foundation, então nenhum fornecedor isolado o controla.
Pense nele como um adaptador de viagem. A tomada na parede (o serviço) e o plugue (o agente) nunca precisam saber um do outro. O adaptador no meio resolve a incompatibilidade.
Antes do MCP, conectar M assistentes a N serviços significava M vezes N integrações personalizadas. Cada par tinha seu próprio fluxo de login, suas próprias peculiaridades de esquema e seus próprios bugs. O MCP transformou isso em M mais N: você escreve um servidor por serviço, um cliente por assistente, e toda combinação funciona. Essa economia é real e explica por que milhares de servidores públicos apareceram em cerca de um ano após o lançamento.
💡 Vale lembrar: o MCP é encanamento, não inteligência. Julgue-o pelo fato de o encanamento custar menos que a alternativa para o seu trabalho específico, e não pela moda do mês.
As críticas não estão erradas. Três reclamações aparecem repetidamente, e cada uma se sustenta quando medida.
Cada ferramenta que um servidor expõe chega com um nome, uma descrição e um esquema JSON. A maioria dos clientes carrega todas elas na janela de contexto do modelo no início da sessão. Aqui vai um cálculo aproximado e ilustrativo: um servidor com 40 ferramentas, a cerca de 400 tokens por esquema, acrescenta 16.000 tokens. Conecte cinco servidores desse tamanho e você terá gasto 80.000 tokens antes de o usuário digitar uma única palavra.
Essa conta tem três partes: dinheiro, latência e atenção. Os tokens custam dinheiro em cada requisição, prompts mais longos respondem mais devagar, e um contexto lotado deixa menos espaço para o material de que o modelo realmente precisa. A qualidade da seleção também tende a cair quando dois servidores expõem cada um uma ferramenta chamada search e o modelo precisa adivinhar qual você queria.
Agentes de programação dominam git, gh, curl, jq, docker e psql. Essas ferramentas aparecem nos dados de treinamento milhares de vezes, têm uma flag --help e sua saída é texto simples. Quando um modelo consegue executar gh pr list --json title,author e interpretar o resultado, um servidor MCP do GitHub acrescenta uma camada sem acrescentar muita capacidade.
Uma CLI também compõe. O modelo encadeia um comando em outro, grava a saída em um arquivo e lê apenas as linhas de que precisa. Uma chamada de ferramenta MCP devolve o resultado inteiro para o contexto, a menos que o autor do servidor tenha planejado a paginação, e muitos não planejaram.
Os arquivos de habilidades seguem outro caminho. Uma skill é uma pasta com uma descrição curta em markdown e, opcionalmente, scripts. Só o nome e um resumo de uma linha ficam no contexto até que o agente decida que precisa da skill, e só então ele lê as instruções completas. Você paga quando o trabalho acontece, e não em cada requisição.
Para fluxos internos como "como fazemos o deploy", "como escrevemos as notas de versão" ou "como consultamos o data warehouse", uma skill mais um script costuma ser o caminho mais curto. Não há servidor para hospedar, nenhum transporte para depurar, e tudo fica no repositório, ao lado do código que descreve.
Agora o outro lado. Estas são as situações em que trocar o MCP por scripts cria mais trabalho, e não menos.
Um script em um notebook pode ler um token de API de uma variável de ambiente. Isso funciona para um desenvolvedor. Deixa de funcionar quando cinquenta pessoas precisam de acesso a um CRM, cada uma com permissões diferentes, e a equipe de segurança quer tokens que expirem. O fluxo de autorização do MCP se apoia no OAuth 2.1, então um servidor remoto pode pedir que cada usuário faça login, emitir tokens com escopo e revogá-los em um único lugar. O agente nunca guarda um segredo de longa duração colado no histórico do shell.
Servidores hospedados também continuam funcionando onde não existe shell algum: um app de chat, um cliente mobile, uma barra lateral de navegador. Uma CLI precisa de um terminal. Um servidor MCP remoto precisa de uma conexão de rede.
Algumas tarefas levam minutos, não milissegundos. A geração de imagens e de vídeos é o exemplo mais claro. Uma requisição inicia um job, uma GPU em algum lugar o pega, e quem chamou precisa voltar mais tarde para conferir. Um comando de shell que bloqueia por noventa segundos é desconfortável. Uma ferramenta com um contrato definido de início, consulta e resultado é mais fácil de acertar.
O conector próprio da PicassoIA segue esse padrão. Sua API é no estilo Replicate: cria-se uma predição, consulta-se seu status e busca-se a saída. Pela conexão MCP, um agente pode acessar quatro modelos, PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video e Seedance 2.5 Lite para vídeo com áudio, sem que ninguém escreva endpoints à mão. A plataforma permite cinco predições simultâneas por conta, compartilhadas entre as credenciais de API e as conexões MCP, então um agente que dispara dez requisições ao mesmo tempo precisa respeitar esse limite. Um servidor bem construído esconde essa contabilidade atrás de resultados de ferramenta claros, bem parecido com um passe de cozinha que mantém os pedidos em sequência enquanto os cozinheiros trabalham em paralelo.
Imagine uma equipe de conteúdo pedindo a um agente um post de lançamento, cinco imagens de destaque e um clipe animado curto. A escrita acontece dentro do modelo. As imagens e o clipe são remotos, lentos e sujeitos a limites de taxa, exatamente o tipo de carga que o MCP trata bem.
Quando um agente toca em dados de produção, alguém pergunta quem fez o quê. Um gateway MCP central pode registrar cada chamada de ferramenta, aplicar listas de permissão por equipe e bloquear ações arriscadas antes que cheguem ao serviço. Fazer o mesmo com scripts avulsos significa caçar logs em vários notebooks.
Os revisores agradecem. Eles podem ler um log e um arquivo de política e ver o que o agente tinha permissão para fazer, em vez de auditar cinquenta históricos de shell diferentes.
Aqui está a mesma comparação como uma tabela de referência rápida.
| Situação | Melhor escolha | Por que combina |
|---|---|---|
| Git local, arquivos, ferramentas de build | CLI | Os modelos já conhecem os comandos, sem configuração |
| Fluxo de equipe, como notas de versão | Skill mais script | Carregado sob demanda, fica no repositório |
| Produto SaaS com permissões por usuário | Servidor MCP remoto | Login OAuth, revogação, logs centralizados |
| Geração de imagem ou vídeo | MCP ou API direta | Jobs assíncronos, limites compartilhados de concorrência |
| Coleta pontual de dados dentro de um script | Chamada de API direta | Menos partes móveis |
| Agente dentro de um app de chat sem shell | Servidor MCP remoto | Nenhum terminal disponível |
| Ferramenta necessária em 1 de cada 100 sessões | Skill ou MCP com carregamento sob demanda | Evita pagar o custo do esquema toda vez |
Repare que a resposta raramente é tudo em MCP ou nada de MCP. A escolha certa depende de quem chama a ferramenta, de quanto tempo ela roda e de com que frequência ela é necessária.
As críticas tiveram efeito, e o ecossistema reagiu. Duas mudanças importam mais.
A equipe de engenharia da Anthropic descreveu, no fim de 2025, um padrão em que o agente escreve código que chama ferramentas MCP, em vez de encaminhar cada chamada pela janela de contexto. As definições de ferramentas aparecem como arquivos que o agente pode navegar, os resultados intermediários ficam dentro de um sandbox, e só a resposta final volta para o modelo. No exemplo trabalhado por eles, o uso de tokens caiu de cerca de 150.000 para cerca de 2.000, uma redução de 98,7%.
Vários clientes agora carregam as definições de ferramentas sob demanda. O modelo pesquisa em um catálogo, puxa as duas ou três ferramentas de que precisa e ignora o resto. É a abordagem do catálogo de fichas: a biblioteca tem milhares de fichas, mas você abre uma gaveta de cada vez. Isso elimina a maior reclamação da seção anterior sem abrir mão do padrão.
Os autores de servidores também se adaptaram. Um servidor com seis ferramentas de alto nível, bem descritas, supera um que espelha, linha por linha, uma API REST com 300 endpoints, porque o modelo tem menos opções e cada opção significa algo.
Percorra isto antes de construir ou instalar qualquer coisa.
A maioria dos conjuntos de ferramentas maduros usa as três coisas. Um agente de programação roda o shell para git e testes, lê uma skill com as convenções da equipe e se conecta a dois ou três servidores MCP remotos para o rastreador de tickets, o banco de dados e a geração de mídia. Você pode testar as mesmas ideias de chamada de ferramentas com os LLMs disponíveis na PicassoIA, como Claude Sonnet 5, GPT 5.6 Sol, Kimi K2.6 e Gemini 3.5 Flash. A escolha do modelo importa menos do que manter a superfície de ferramentas pequena e honesta.
ls ou cat acrescenta um processo, um transporte e um esquema em troca de nada que o shell já não ofereça.Então, precisamos mais do MCP? Para ferramentas locais e conhecidas, geralmente não. Para serviços remotos, autenticados, lentos e compartilhados, geralmente sim. Essa divisão é a resposta inteira, e ela vai continuar mudando conforme os clientes ficarem mais inteligentes para carregar ferramentas.
Se você quer ver um fluxo assíncrono e remoto em ação sem ler uma especificação, gere algo. Abra a Picasso IA, escolha PicassoIA Image para uma imagem estática rápida, refine-a com PicassoIA Image Editor Pro e depois anime o resultado com PicassoIA Video. Cada imagem deste artigo começou como um prompt em linguagem simples, e o mesmo fluxo está disponível para um agente pela conexão MCP. Veja tudo em picassoia.com/en/all-models, digite uma ideia e descubra até onde uma única frase consegue levar você.
Escolha seu idioma
