Home
Blog
O MCP está morto? O que aprendemos Construindo com MCP, CLI e habilidades de agente

O MCP está morto? O que aprendemos Construindo com MCP, CLI e habilidades de agente

Engineering

April 01, 2026

Cheney Zhang

Quando o CTO da Perplexity, Denis Yarats, disse na ASK 2026 que a empresa estava a desprivilegiar o MCP internamente, isso desencadeou o ciclo habitual. O CEO da YC, Garry Tan, foi contra - o MCP consome muita janela de contexto, o auth está quebrado, ele construiu um substituto para o CLI em 30 minutos. O Hacker News publicou um artigo fortemente anti-MCP.

Há um ano atrás, este nível de ceticismo público teria sido invulgar. O Protocolo de Contexto de Modelo (MCP) foi posicionado como o padrão definitivo para a integração de ferramentas de agentes de IA. O número de servidores duplicava semanalmente. Desde então, o padrão tem seguido um arco familiar: rápido entusiasmo, ampla adoção, depois desilusão na produção.

A indústria está a responder rapidamente. A Lark/Feishu da Bytedance abriu o código aberto da sua CLI oficial - mais de 200 comandos em 11 domínios de negócio com 19 competências de agente incorporadas. A Google lançou o gws para o Google Workspace. O padrão CLI + Skills está rapidamente a tornar-se o padrão para ferramentas de agentes empresariais, não uma alternativa de nicho.

Na Zilliz, lançámos o Zilliz CLI, que lhe permite operar e gerir o Milvus e o Zilliz Cloud (Milvus totalmente gerido) diretamente a partir do seu terminal sem sair do seu ambiente de programação. Além disso, criámos o Milvus Skills e o Zilliz Skillspara que os agentes de codificação de IA, como o Claude Code e o Codex, possam gerir a sua base de dados de vectores através de linguagem natural.

Também criámos um servidor MCP para o Milvus e o Zilliz Cloud há um ano. Essa experiência ensinou-nos exatamente onde é que o MCP falha - e onde é que ainda se encaixa. Três limitações arquitectónicas empurraram-nos para o CLI e Skills: inchaço da janela de contexto, design passivo da ferramenta e a incapacidade de reutilizar o LLM do próprio agente.

Nesta postagem, analisaremos cada problema, mostraremos o que estamos construindo e apresentaremos uma estrutura prática para escolher entre MCP, CLI e Habilidades do agente.

O MCP consome 72% da sua janela de contexto na inicialização

Uma configuração padrão do MCP pode consumir cerca de 72% da sua janela de contexto disponível antes que o agente execute uma única ação. Conecte três servidores - GitHub, Playwright e uma integração de IDE - em um modelo de 200 mil tokens, e as definições de ferramentas ocupam cerca de 143 mil tokens. O agente ainda não fez nada. Já está três quartos cheio.

O custo não é apenas de tokens. Quanto mais conteúdo não relacionado for colocado no contexto, mais fraco será o foco do modelo no que realmente importa. Uma centena de esquemas de ferramentas no contexto significa que o agente passa por todos eles em cada decisão. Os investigadores documentaram o que designam por podridão do contexto - a degradação da qualidade do raciocínio devido à sobrecarga de contexto. Nos testes realizados, a precisão da seleção de ferramentas desceu de 43% para menos de 14% à medida que o número de ferramentas aumentava. Mais ferramentas, paradoxalmente, significam uma pior utilização das ferramentas.

A causa principal é arquitetónica. O MCP carrega todas as descrições de ferramentas na íntegra no início da sessão, independentemente de a conversa atual vir a usá-las. Trata-se de uma escolha de conceção ao nível do protocolo, não de um erro - mas o custo aumenta com cada ferramenta que se acrescenta.

As competências dos agentes adoptam uma abordagem diferente: divulgação progressiva. No início da sessão, um agente lê apenas os metadados de cada habilidade - nome, descrição de uma linha, condição de acionamento. Um total de algumas dezenas de tokens. O conteúdo completo da habilidade é carregado somente quando o agente determina que é relevante. Pense nisso desta forma: O MCP alinha todas as ferramentas à porta e obriga-o a escolher; o Skills dá-lhe primeiro um índice e o conteúdo completo a pedido.

As ferramentas CLI oferecem uma vantagem semelhante. Um agente executa git --help ou docker --help para descobrir recursos sob demanda, sem pré-carregar cada definição de parâmetro. O custo do contexto é pago à medida que se vai utilizando, e não à cabeça.

Em pequena escala, a diferença é insignificante. Em escala de produção, é a diferença entre um agente que funciona e um que se afoga em suas próprias definições de ferramentas.

A arquitetura passiva do MCP limita os fluxos de trabalho do agente

O MCP é um protocolo de chamada de ferramenta: como descobrir ferramentas, chamá-las e receber resultados. Design limpo para casos de uso simples. Mas essa limpeza é também uma restrição.

Espaço de ferramentas plano sem hierarquia

Uma ferramenta MCP é uma assinatura de função plana. Sem subcomandos, sem conhecimento do ciclo de vida da sessão, sem noção de onde o agente está num fluxo de trabalho de várias etapas. Fica à espera de ser chamado. É só isso que ele faz.

Um CLI funciona de forma diferente. git commit, git push e git log são caminhos de execução completamente diferentes que partilham uma única interface. Um agente executa --help, explora a superfície disponível de forma incremental e expande apenas o que precisa - sem carregar toda a documentação de parâmetros no contexto.

As habilidades codificam a lógica do fluxo de trabalho - o MCP não pode

Uma competência de agente é um ficheiro Markdown que contém um procedimento operacional padrão: o que fazer primeiro, o que fazer a seguir, como lidar com falhas e quando apresentar algo ao utilizador. O agente recebe não apenas uma ferramenta, mas todo um fluxo de trabalho. As competências moldam ativamente a forma como um agente se comporta durante uma conversa - o que as desencadeia, o que preparam antecipadamente e como recuperam de erros. As ferramentas MCP só podem esperar.

A MCP não consegue aceder ao LLM do agente

Esta é a limitação que realmente nos impediu.

Quando construímos o claude-context - um plugin MCP que adiciona pesquisa semântica ao Claude Code e outros agentes de codificação de IA, dando-lhes um contexto profundo de toda uma base de código - queríamos recuperar trechos de conversas históricas relevantes do Milvus e apresentá-los como contexto. A recuperação da pesquisa vetorial funcionou. O problema era o que fazer com os resultados.

Recuperar os 10 melhores resultados, e talvez 3 sejam úteis. Os outros 7 são ruído. Entregue todos os 10 ao agente externo, e o ruído interfere na resposta. Nos testes, vimos que as respostas se distraíam com registos históricos irrelevantes. Precisávamos de filtrar antes de passar os resultados.

Tentámos várias abordagens. Adicionar uma etapa de reavaliação dentro do servidor MCP utilizando um modelo pequeno: não era suficientemente exato e o limiar de relevância precisava de ser ajustado por caso de utilização. Usar um modelo grande para reavaliação: tecnicamente correto, mas um servidor MCP é executado como um processo separado, sem acesso ao LLM do agente externo. Teríamos que configurar um cliente LLM separado, gerenciar uma chave de API separada e lidar com um caminho de chamada separado.

O que queríamos era simples: deixar o LLM do agente externo participar diretamente da decisão de filtragem. Recuperar os 10 melhores, deixar o próprio agente julgar o que vale a pena manter e retornar apenas os resultados relevantes. Sem um segundo modelo. Sem chaves API adicionais.

O MCP não pode fazer isso. O limite do processo entre o servidor e o agente é também um limite de inteligência. O servidor não pode usar o LLM do agente; o agente não pode controlar o que acontece dentro do servidor. É ótimo para ferramentas CRUD simples. No momento em que uma ferramenta precisa de fazer um julgamento, esse isolamento torna-se um verdadeiro constrangimento.

Uma Habilidade de Agente resolve isto diretamente. Uma competência de recuperação pode chamar a pesquisa vetorial para os 10 melhores, fazer com que o LLM do próprio agente avalie a relevância e devolver apenas o que for aprovado. Nenhum modelo adicional. O agente faz a filtragem sozinho.

O que criámos em vez disso com CLI e Skills

Vemos a CLI + Skills como a direção para a interação agente-ferramenta - não apenas para a recuperação de memória, mas em toda a pilha. Esta convicção orienta tudo o que estamos a construir.

memsearch: Uma camada de memória baseada em habilidades para agentes de IA

Criámos o memsearch, uma camada de memória de código aberto para o Claude Code e outros agentes de IA. A habilidade é executada dentro de um subagente com três estágios: O Milvus trata da pesquisa vetorial inicial para uma descoberta alargada, o LLM do próprio agente avalia a relevância e expande o contexto para resultados promissores, e uma pesquisa final acede às conversas originais apenas quando necessário. O ruído é eliminado em cada fase - o lixo da recuperação intermédia nunca chega à janela de contexto primário.

A principal conclusão: a inteligência do agente faz parte da execução da ferramenta. O LLM que já está no ciclo faz a filtragem - sem segundo modelo, sem chave API extra, sem ajuste de limiar frágil. Este é um caso de utilização específico - recuperação de contexto de conversação para agentes de codificação - mas a arquitetura é generalizável a qualquer cenário em que uma ferramenta necessite de julgamento e não apenas de execução.

Zilliz CLI, Skills e Plugin para Operações de Bases de Dados Vectoriais

Milvus é a base de dados vetorial open-source mais adoptada do mundo, com mais de 43 mil estrelas no GitHub. O Zilliz Cloud é o serviço totalmente gerido do Milvus com funcionalidades empresariais avançadas e é muito mais rápido do que o Milvus.

A mesma arquitetura em camadas mencionada acima impulsiona as nossas ferramentas de desenvolvimento:

O Zilliz CLI é a camada de infraestrutura. Gestão de clusters, operações de recolha, pesquisa de vectores, RBAC, cópias de segurança, faturação - tudo o que faria na consola do Zilliz Cloud, disponível a partir do terminal. Os humanos e os agentes utilizam os mesmos comandos. O Zilliz CLI também serve de base para o Milvus Skills e o Zilliz Skills.
O Milvus Skill é a camada de conhecimento para o Milvus de código aberto. Ele ensina os agentes de codificação de IA (Claude Code, Cursor, Codex, GitHub Copilot) a operar qualquer implantação do Milvus - Milvus Lite, Standalone ou Distributed - por meio do código Python do pymilvus: conexões, design de esquema, CRUD, pesquisa híbrida, pesquisa de texto completo, pipelines RAG.
O Zilliz Skill faz o mesmo para o Zilliz Cloud, ensinando os agentes a gerir a infraestrutura da nuvem através do Zilliz CLI.
O Zilliz Plugin é a camada de experiência do programador para o Claude Code - envolve o CLI + Skill numa experiência guiada com comandos de barra como /zilliz:quickstart e /zilliz:status.

A CLI lida com a execução, as Skills codificam o conhecimento e a lógica do fluxo de trabalho, o Plugin fornece o UX. Nenhum servidor MCP no circuito.

Para obter mais detalhes, confira estes recursos:

O MCP está realmente morrendo?

Muitos desenvolvedores e empresas, incluindo nós aqui na Zilliz, estão se voltando para CLI e Skills. Mas será que o MCP está mesmo a morrer?

A resposta curta: não - mas o seu âmbito está a diminuir para onde realmente se encaixa.

O MCP foi doado à Linux Foundation. Os servidores activos são mais de 10.000. Os downloads mensais do SDK são de 97 milhões. Um ecossistema desse tamanho não desaparece por causa de um comentário numa conferência.

Um tópico do Hacker News - "Quando é que o MCP faz sentido vs CLI?" - obteve respostas que favoreceram maioritariamente o CLI: "As ferramentas CLI são como instrumentos de precisão", "Os CLIs também são mais rápidos do que os MCPs". Alguns desenvolvedores têm uma visão mais equilibrada: Habilidades são uma receita detalhada que ajuda a resolver um problema melhor; MCP é a ferramenta que ajuda a resolver o problema. Ambas têm o seu lugar.

Isso é justo - mas levanta uma questão prática. Se a receita em si pode orientar o agente sobre quais as ferramentas a utilizar e como, será ainda necessário um protocolo de distribuição de ferramentas separado?

Depende do caso de uso.

O MCP sobre stdio - a versão que a maioria dos programadores executa localmente - é onde os problemas se acumulam: comunicação instável entre processos, isolamento de ambiente confuso, elevado custo de token. Nesse contexto, existem alternativas melhores para quase todos os casos de utilização.

A MCP sobre HTTP é uma história diferente. As plataformas de ferramentas internas da empresa precisam de gerenciamento centralizado de permissões, OAuth unificado, telemetria e registro padronizados. As ferramentas fragmentadas de CLI realmente lutam para fornecer isso. A arquitetura centralizada do MCP tem um valor real nesse contexto.

O que a Perplexity realmente abandonou foi principalmente o caso de uso stdio. Denis Yarats especificou "internamente" e não apelou à adoção dessa opção por toda a indústria. Essa nuance perdeu-se na transmissão - "Perplexity abandona MCP" espalha-se consideravelmente mais depressa do que "Perplexity desprioriza MCP em vez de stdio para integração interna de ferramentas".

O CIM surgiu porque resolveu um problema real: antes dele, cada aplicação de IA escrevia a sua própria lógica de chamada de ferramentas, sem um padrão partilhado. O MCP forneceu uma interface unificada no momento certo, e o ecossistema desenvolveu-se rapidamente. A experiência de produção revelou então as limitações. Esse é um arco normal para ferramentas de infraestrutura - não uma sentença de morte.

Quando usar MCP, CLI ou Skills

	MCP sobre stdio (Local)	MCP sobre HTTP (Empresa)
Autenticação	Nenhuma	OAuth, centralizado
Estabilidade da conexão	Problemas de isolamento de processos	HTTPS estável
Registo de dados	Nenhum mecanismo padrão	Telemetria centralizada
Controlo de acesso	Nenhum	Permissões baseadas em funções
A nossa opinião	Substituir por CLI + Skills	Manter para ferramentas empresariais

Para as equipas que escolhem a sua pilha de ferramentas de IA agêntica, eis como as camadas se encaixam:

Camada	O que ela faz	Melhor para	Exemplos
CLI	Tarefas operacionais, gestão de infra-estruturas	Comandos executados por agentes e humanos	git, docker, zilliz-cli
Competências	Lógica do fluxo de trabalho do agente, conhecimento codificado	Tarefas que necessitam de julgamento LLM, SOPs de várias etapas	milvus-skill, zilliz-skill, memsearch
APIs REST	Integrações externas	Ligação a serviços de terceiros	API do GitHub, API do Slack
MCP HTTP	Plataformas de ferramentas empresariais	Autenticação centralizada, registo de auditoria	Gateways de ferramentas internas

Comece a usar

Tudo o que discutimos neste artigo está disponível hoje:

memsearch - a camada de memória baseada em habilidades para agentes de IA. Coloque-a no Claude Code ou em qualquer agente que suporte Skills.
Zilliz CLI - gere o Milvus e o Zilliz Cloud a partir do seu terminal. Instale-o e explore os subcomandos que os seus agentes podem utilizar.
Milvus Skill e Zilliz Sk ill - dê ao seu agente de codificação de IA conhecimentos nativos do Milvus e do Zilliz Cloud.

Tem dúvidas sobre pesquisa vetorial, arquitetura de agente ou criação com CLI e Skills? Junte-se à comunidade Milvus Disc ord ou reserve uma sessão gratuita do Office Hours para falar sobre o seu caso de utilização.

Pronto para construir? Registe-se no Zilliz Cloud - as novas contas com um e-mail de trabalho recebem $100 em créditos gratuitos. Já tem uma conta? Inicie sessão aqui.

Perguntas frequentes

Qual é o problema do MCP para agentes de IA?

O MCP tem três limitações arquitectónicas principais na produção. Primeiro, ele carrega todos os esquemas de ferramentas na janela de contexto no início da sessão - conectar apenas três servidores MCP em um modelo de 200 mil tokens pode consumir mais de 70% do contexto disponível antes que o agente faça qualquer coisa. Em segundo lugar, as ferramentas CIM são passivas: esperam ser chamadas e não podem codificar fluxos de trabalho de várias etapas, lógica de tratamento de erros ou procedimentos operacionais padrão. Em terceiro lugar, os servidores MCP são executados como processos separados sem acesso ao LLM do agente, pelo que qualquer ferramenta que necessite de julgamento (como a filtragem de resultados de pesquisa por relevância) requer a configuração de um modelo separado com a sua própria chave API. Estes problemas são mais graves com o MCP sobre stdio; o MCP sobre HTTP atenua alguns deles.

Qual é a diferença entre o CIM e as Competências de Agente?

O MCP é um protocolo de chamada de ferramenta que define como um agente descobre e invoca ferramentas externas. Uma Habilidade de Agente é um arquivo Markdown que contém um procedimento operacional padrão completo - gatilhos, instruções passo a passo, tratamento de erros e regras de escalonamento. A principal diferença arquitetónica: As habilidades são executadas dentro do processo do agente, para que possam aproveitar o LLM do próprio agente para chamadas de julgamento, como filtragem de relevância ou reanálise de resultados. As ferramentas MCP são executadas num processo separado e não podem aceder à inteligência do agente. As habilidades também usam a divulgação progressiva - apenas metadados leves são carregados na inicialização, com o conteúdo completo sendo carregado sob demanda - mantendo o uso da janela de contexto mínimo em comparação com o carregamento de esquema inicial do MCP.

Quando é que devo continuar a utilizar a MCP em vez da CLI ou do Skills?

O MCP sobre HTTP ainda faz sentido para plataformas de ferramentas empresariais onde é necessário OAuth centralizado, controlo de acesso baseado em funções, telemetria padronizada e registo de auditoria em muitas ferramentas internas. Ferramentas CLI fragmentadas lutam para fornecer esses requisitos corporativos de forma consistente. Para fluxos de trabalho de desenvolvimento local - em que os agentes interagem com ferramentas em sua máquina - a CLI + Skills normalmente oferece melhor desempenho, menor sobrecarga de contexto e lógica de fluxo de trabalho mais flexível do que o MCP sobre stdio.

Como as ferramentas da CLI e as habilidades do agente trabalham juntas?

A CLI fornece a camada de execução (os comandos reais), enquanto as Skills fornecem a camada de conhecimento (quando executar quais comandos, em que ordem e como lidar com falhas). Por exemplo, o Zilliz CLI trata de operações de infraestrutura como a gestão de clusters, CRUD de colecções e pesquisa de vectores. O Milvus Skill ensina ao agente os padrões pymilvus corretos para a conceção de esquemas, pesquisa híbrida e pipelines RAG. A CLI faz o trabalho; a Skill conhece o fluxo de trabalho. Este padrão em camadas - CLI para execução, Skills para conhecimento, um plugin para UX - é a forma como estruturámos todas as nossas ferramentas de desenvolvimento na Zilliz.

MCP vs Skills vs CLI: quando devo usar cada um?

Ferramentas CLI como git, docker, ou zilliz-cli são melhores para tarefas operacionais - elas expõem subcomandos hierárquicos e carregam a pedido. Habilidades como milvus-skill são melhores para a lógica de fluxo de trabalho do agente - elas carregam procedimentos operacionais, recuperação de erros e podem acessar o LLM do agente. O MCP sobre HTTP ainda se encaixa em plataformas de ferramentas empresariais que precisam de OAuth centralizado, permissões e registo de auditoria. O MCP sobre stdio - a versão local - está a ser substituído por CLI + Skills na maioria das configurações de produção.