MCP não é ruim. Seu agente é. — Jan Čurn, Apify

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: MCP Doesn’t Suck. Your Agent Does. — Jan Čurn, Apify · Canal: AI Engineer · 18:15 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de prompts e contexto, Ferramentas de desenvolvimento com IA

Resumo

Jan Čurn argumenta que muitas críticas ao MCP — como o alto consumo de contexto — decorrem de limitações do harness, não do protocolo em si. Ele apresenta soluções como progressive tool discovery e code mode, e explica por que CLIs funcionam bem como interface local para agentes, enquanto MCP é mais adequado ao acesso remoto. Em seguida, demonstra o MCPC, uma CLI que permite usar recursos do MCP e combinar chamadas em código. Por fim, mostra resultados preliminares de Connector evals, que comparam o desempenho de diferentes conectores.

Pontos-chave

Registrar todas as ferramentas MCP no contexto de uma só vez pode consumir muitos tokens e reduzir a eficiência do agente.
O modo como o harness implementa o MCP é responsabilidade de quem desenvolve o agente; a especificação não determina essa implementação.
Subagentes podem separar contextos, mas não eliminam o custo dos tokens nem os riscos de manter dados sensíveis no contexto.
Progressive tool discovery permite carregar ferramentas apenas quando são necessárias.
Code mode trata ferramentas e servidores MCP como código, que modelos podem explorar e executar.
CLIs oferecem descoberta progressiva por padrão e podem ser executadas como código por meio de um ambiente local.
Na proposta do palestrante, MCP é apropriado para acesso remoto padronizado, enquanto CLI funciona como interface local para agentes.
MCPC é uma CLI para interagir com servidores MCP, com suporte a saída JSON, autenticação e tarefas assíncronas.
Os resultados preliminares apresentados sugerem que MCPC e CLI têm desempenho semelhante nos testes, enquanto MCP bruto pode consumir mais tokens.

Capítulos

Início	Capítulo	Resumo
00:12	O debate em torno do MCP	Jan Čurn apresenta o MCP e as críticas de que o protocolo consumiria contexto demais e deveria ser substituído por CLIs.
02:16	Consumo de contexto e limites dos subagentes	O palestrante atribui o consumo excessivo de contexto à implementação do harness e observa que subagentes não eliminam custos nem riscos.
04:20	Descoberta progressiva e code mode	Ele descreve formas de carregar ferramentas sob demanda e de permitir que agentes as explorem e usem como código.
06:51	Por que combinar MCP e CLI	A apresentação compara o uso local de CLIs com o acesso remoto padronizado oferecido pelo MCP.
10:31	MCPC: uma CLI para servidores MCP	Jan Čurn apresenta o MCPC e demonstra conexão com servidores locais e remotos, autenticação, descoberta de ferramentas e tarefas assíncronas.
16:14	Composição em JSON e avaliação de conectores	O palestrante mostra o uso de chamadas em JSON e resultados preliminares que comparam MCPC, CLI e MCP.

Citações

Não é um problema do protocolo; é um problema do harness. — 03:18

Por que colocar as 100 ferramentas no contexto o tempo todo se você raramente precisa delas? — 05:20

Como interface local, a CLI é ótima; para acesso remoto, o MCP é melhor. — 09:59

Por favor, parem de dizer que CLI é melhor que MCP, porque MCP mais CLI é o melhor. — 18:15

Conceitos e entidades

MCP (conceito): Protocolo apresentado como um padrão para conectar agentes a ferramentas e recursos, especialmente em acesso remoto.
Harness (conceito): Camada de implementação que determina como um agente usa ferramentas e protocolos como MCP.
progressive tool discovery (conceito): Abordagem que disponibiliza ferramentas no contexto do agente apenas quando elas são necessárias.
Code Mode (conceito): Abordagem que permite ao agente interagir com ferramentas tratando-as como código.
CLI (conceito): Interface de linha de comando que, segundo o palestrante, funciona bem como interface local para agentes.
MCPC (ferramenta): CLI apresentada por Jan Čurn para conectar e interagir com servidores MCP.
Connector evals (ferramenta): Framework apresentado para comparar o desempenho de diferentes conectores, como CLI, MCP e MCPC.
Jan Čurn (pessoa): Fundador e CEO da Apify e palestrante desta apresentação.
Apify (empresa): Empresa da qual Jan Čurn é fundador e CEO, mencionada na apresentação do MCPC.
Claude Code (ferramenta): Agente citado como exemplo de cliente que pode usar a configuração compartilhada do MCPC.

Tradução completa (pt-BR)

00:12 Legal. Olá a todos. Bem-vindos à nossa palestra. É uma das últimas palestras da conferência. Então, obrigado por terem vindo. Esta palestra se chama “MCP não é uma droga. Seu agent é”. Meu nome é Han Chern. Sou o fundador e CEO da Appify. Não sei se vocês viram estes cartazes por aqui. Talvez eu dê um zoom. Na verdade, fizemos um grande esforço para trazer pessoas para esta palestra. Não deu muito certo. Mas, enfim, obrigado por terem vindo. Então, como vocês sabem, MCP é um padrão para

00:43 acessar ferramentas e recursos com segurança, certo? Basicamente, é um padrão para a interação entre agent e ferramentas, e foi apresentado pela Anthropic há quase dois anos. Na verdade, tomou o mundo de assalto, certo? E, no ano passado, MCP virou o queridinho do mundo da IA. Muita gente criou seus servidores. Acho que agora existem de 10 mil a 15 mil servidores, certo? Muitos clientes adotaram o padrão, e ele acabou se tornando um padrão usado pelo Claude ou pelo ChatGPT para conectar ferramentas e conectores aos

01:14 seus agentes de IA. Havia tantos servidores MCP que as pessoas tiveram que criar diretórios de servidores MCP. E havia tantos diretórios que as pessoas tiveram que criar até diretórios de diretórios de servidores MCP. Tempos bem malucos, né? Então, quando MCP conecta agents a ferramentas, todo mundo adora MCP, certo? Certo. Bem, não exatamente. Na verdade, especialmente no ano passado, houve muito ódio contra MCP. Por exemplo, a Anthropic admite que MCP é uma droga; MCP é a abstração errada.

01:45 A Anthropic está se esforçando muito para consertar MCP. MCP foi um erro. Vida longa às CLIs, certo? MCP está morto e enterrado. Open Claw me mostrou que API e CLI vão vencer. Há um motivo para eu não ter adicionado suporte a MCP ao Open Claw, exceto pelo conversor MCorter de MCP para CLI. Ah, interessante. MCPs são quase sempre inúteis. Vou defender essa opinião até o fim, se for preciso. Todo MCP poderia ser uma CLI determinística. É isso que vou fazer no ano que vem.

02:16 E Gary Tan, que também vai falar hoje, disse: “MCP é uma droga, sinceramente”. Meu Deus. E Peter Levels: “Graças a Deus, MCP morreu”. Então, pensei: o que está acontecendo? Por que todo mundo está atacando MCPs? Isso é loucura. Primeiro, vamos analisar o problema: do que as pessoas estão falando? O problema mais citado era: “MCP consome contexto demais”. E isso é verdade. A primeira maneira como os agents implementaram MCP foi muito ingênua. Eles pensaram: “MCP fornece ferramentas; então, se você tem 10 servidores MCP, tem 10 ferramentas MCP”, ou seja, 100 ferramentas, e os agents registravam todas essas ferramentas no contexto imediatamente.

02:47 Então, antes mesmo de você fazer uma pergunta, MCP já consumiria umas 100 ferramentas no seu contexto. Talvez um terço do seu contexto desaparecesse sem que nenhum trabalho tivesse sido feito. E, sinceramente, isso é bem louco, se você pensar a respeito. Depois, você chamaria ferramentas, acrescentando conteúdo ao contexto; os resultados também seriam adicionados de volta ao contexto. Basicamente, o contexto só iria

03:18 crescendo muito, e, com o tempo, você perderia precisão, gastaria muito dinheiro e assim por diante. É uma maneira muito ineficiente de fazer isso. Mas esse não é um problema de MCP; é um problema do harness. Se você olhar a especificação de MCP, o que ela diz sobre como projetar o harness? Absolutamente nada. Fica a critério da implementação. Então, cabe a você, ao criar seu agent, garantir que está usando MCP com eficiência. Não é um problema do protocolo, certo? Quais são as soluções para isso? Bem,

03:49 a primeira solução, bastante ingênua, é: “Vamos dividir o contexto entre subagents”. Se houver uma tarefa, você pode delegá-la a um novo subagent, com seu próprio contexto. Assim, ela não ocupa a context window principal. Isso é ótimo, mas você ainda precisa pagar pelos tokens. Eles não desaparecem. E os problemas mencionados antes continuam existindo. Por exemplo, se a ferramenta MCP retornar resultados sensíveis, como uma senha, basicamente isso

04:20 fica no seu contexto e pode ser usado indevidamente por outras chamadas de ferramentas ou pelo aplicativo, certo? Então, o contexto é um lugar péssimo para passar valores sensíveis ou grandes volumes de dados. E os subagents só empurram esse problema um pouco mais para a frente, mas não o eliminam. Qual é a segunda solução? Acho que foi no fim do ano passado que primeiro a Anthropic e depois o Cursor introduziram algo chamado descoberta progressiva de ferramentas. A ideia é tão simples que chega a doer, ainda assim as pessoas tiveram que fazer isso. Mas a ideia era: “Se colocarmos todas as ferramentas no contexto, consumiremos tokens demais. Então, que tal colocar as ferramentas no contexto progressivamente, somente quando forem necessárias?” Por exemplo, a Anthropic introduziu no Claude essa ferramenta chamada tool search tool. Basicamente, ela ajuda você a encontrar outras ferramentas e só as adiciona ao contexto quando necessário, certo? E faz sentido. Por que você adicionaria todas as 100 ferramentas ao seu

04:50 contexto o tempo todo se raramente precisa delas? Normalmente, você só precisa de uma ou duas, e, desse jeito, pode economizar uma quantidade enorme de contexto desde o início. Basicamente, isso torna tudo mais eficiente, mais barato, mais rápido de executar e assim por diante. Faz sentido, né? Então, todo mundo deveria fazer isso. Não. A terceira solução também foi introduzida no fim do ano passado, pela Cloudflare. Ela se chama modo de código. A ideia principal é: “Vamos parar de tratar as ferramentas MCP

05:20 como funções que precisam estar no contexto e passar a tratá-las como código. Na verdade, os modelos são muito bons em escrever e analisar código, porque podem usar ferramentas como grep, encontrar a definição certa e navegar pelo código muito bem. Assim, também podem navegar pelas descrições das ferramentas, pelas informações sobre elas e por aí vai. É uma ideia bem simples e direta: vamos converter ferramentas MCP e servidores em

05:51 código e tratá-los como código. Bem simples, mas extremamente eficaz. Acontece que os modelos são melhores em escrever e chamar código do que em chamar ferramentas, porque tool calling é uma construção artificial que precisamos ensinar aos LLMs. Isso não existe no mundo real nem nos dados de treinamento reais; precisa ser sintetizado e incorporado ao modelo. Mas, infelizmente, até a implementação do modo de código da Cloud é muito difícil de usar. É muito vinculada à plataforma deles e não é muito direta. Então, pouca gente está usando o modo de código, exceto em alguns exemplos. A maioria dos agents ainda está vivendo na idade das trevas e não oferece esses recursos. A maioria dos clientes MCP também não oferece suporte a eles, o que é uma pena, porque o protocolo evoluiu bastante e ganhou muitos recursos novos, mas os clientes não dão suporte a eles. Então, qual é a diferença das CLIs? Por que as pessoas comparam CLI a MCP? Bem, na verdade,

06:21 os agents nunca carregam a CLI inteira no contexto. Não é como se o agent fosse explorar todos os comandos da ferramenta de CLI, procurar a ajuda e colocar tudo no contexto. Não, não. Ele faz isso progressivamente por padrão. Então, o agent só chama a ferramenta de CLI quando necessário. E, às vezes, na verdade, já conhece as ferramentas de cor. Por exemplo, os comandos básicos do Linux já são conhecidos pelos agents, porque eles aparecem nos dados de treinamento desde sempre. Mas eles também podem aprender sobre as ferramentas de CLI pela ajuda, porque

06:51 O modo é muito difícil de usar. Ele é muito, digamos, vinculado à plataforma deles, e não é muito simples de usar, sabe? Então, na verdade, poucas pessoas usam o modo de código, sabe? Com exceção de alguns exemplos, certo? Então, a maioria dos agents ainda vive na Idade das Trevas, e eles não oferecem suporte a esses recursos, sabe? E a maioria dos clientes MCP também não. É uma pena, porque o protocolo evoluiu bastante e ganhou muitas coisas novas, mas os clientes não oferecem suporte a elas. Então, como a CLI é diferente, sabe? Por que as pessoas comparam a CLI ao MCP? Bem, na verdade,

07:24 os agents nunca carregam a CLI inteira para o contexto. Não é como se o agent fosse explorar todos os comandos da ferramenta de CLI, procurar ajuda e colocar isso no contexto. Não, não. Por padrão, ele faz isso progressivamente. Então, o agent só chama a ferramenta de CLI quando necessário e, às vezes, na verdade, já conhece as ferramentas de cor. Por exemplo, os comandos básicos do Linux, os agents já conhecem porque os veem nos dados de treinamento desde sempre, sabe? Mas eles também podem aprender sobre as ferramentas de CLI pela ajuda, porque

07:56 Há ajuda e, na verdade, os agents executam ferramentas CLI como código por padrão, certo? Então, para executar ferramentas CLI, é preciso ter algum ambiente de execução, como um sandbox ou uma máquina onde seja possível executar os comandos. E, quando você invoca essas ferramentas CLI, quero dizer, o modo de código é o padrão: você as executa como código, como código bash, mas ainda é código. Então, basicamente, o modo de código está disponível para CLI desde o início, enquanto

08:27 o MCP precisou, de certa forma, evoluir até chegar a isso, sabe? E isso é importante: os agents conhecem o shell de cor. Quer dizer, o shell do Linux, do Linux ou do Unix, existe desde 1969, quando Ken Thompson e Dennis Ritchie criaram o Linux. E, quando você olha para o terminal básico, aquela caixa preta com 80 colunas e, não sei, 25 linhas, vê uma representação realmente condensada do que está acontecendo no computador, certo? Cada byte, cada caractere ali é

08:59 otimizado, sabe, há mais de 40 anos para transmitir apenas as informações mais importantes, certo? Então, ele é realmente muito otimizado para as pessoas. Mas acontece que os agents gostam disso. Os agents realmente conhecem o shell de cor. Eles sabem muito bem como executar comandos CLI, como conectá-los por pipe. Sabem mesmo como usar bem um shell, porque viram isso em muitos dados de treinamento. Além disso, os laboratórios de IA podem sintetizar uma quantidade infinita de dados de treinamento usando o shell, certo? Basta conectar diferentes comandos por pipe, explorar os comandos, extrair

09:29 informações das páginas de manual e, basicamente, fornecer tudo isso aos modelos. Então, eles conhecem muito bem o shell. Mas as CLI são caixas-pretas locais, sem um protocolo padrão de transporte. Basicamente, quero dizer, elas são literalmente caixas-pretas. São como um terminal preto, certo? E você não vê o que está acontecendo por dentro. Por exemplo, se você quisesse instrumentar essas CLI na sua empresa, teria que inspecionar o protocolo e descobrir: “Ah, elas usam uma API ou WebSockets?” Você não

09:59 sabe; não pode injetar as credenciais nelas. Então, basicamente, CLI são ótimas para interfaces locais, mas, para acesso remoto, o MCP é melhor. Quer dizer, ainda não vi nenhum agent usando conectores CLI; isso não existe, porque não faz sentido. Existem conectores MCP. Então, que tal usarmos MCP para acesso remoto padrão e CLI para acesso local do agent, ou como interface local do agent, com todas as vantagens que descrevi? Assim, você pode disponibilizar todos os recursos de protocolo do MCP por meio de uma simples chamada de ferramenta que todos os

10:31 agents já conhecem, chamada bash, certo? Então, basicamente, toda a complexidade do MCP fica escondida atrás de uma única chamada de ferramenta: bash. E você não precisa se preocupar com sessões, autorização, tudo ou nada. Então, senhoras e senhores, apresento a vocês o MCPC, nosso cliente CLI universal para MCP. Isso começou como um projeto de hobby em dezembro, também conhecido como inverno do Claude, e, de um projeto de hobby,

11:02 acabou evoluindo para provavelmente o cliente MCPC com mais recursos do mercado. Você pode instalá-lo pelo npm ou pelo Bun. E como ele funciona? O design do MCPC busca, acima de tudo, oferecer suporte a tudo o que o protocolo MCP tem a oferecer: tarefas, recursos, prompts, basicamente tudo, certo? E máxima compatibilidade, para que seja muito fácil executá-lo em qualquer lugar e a qualquer momento. O MCP é superleve. Não há LLM.

11:33 É só um wrapper. É um wrapper CLI sobre o protocolo MCP que abstrai o protocolo, por assim dizer, mas nada além disso. Ele deve ser fácil de usar tanto para agents quanto para pessoas, obviamente, e precisa oferecer suporte ao modo de código em todos os aspectos. Na verdade, cada comando do MCPC tem uma opção para ser executado com –json, que retorna apenas uma representação JSON pura dos dados, em conformidade com a especificação do MCP. Assim, você pode combinar diferentes chamadas CLI com ferramentas como jq, conectá-las por pipe e realmente criar sequências de chamadas de ferramentas em código.

12:03 Vou mostrar como funciona, com uma demonstração rápida. Ainda temos um tempinho. Esta é a interface básica do MCPC. Ele tem um comando de ajuda. Na verdade, otimizamos bastante a ajuda para facilitar que os agents comecem a usá-lo imediatamente, sem nenhuma skill externa. Então, primeiro vou

12:36 me conectar a um servidor local. Ah, não, não, não. Ele oferece suporte a stdio, que são os processos locais executados no seu computador. Aqui, estou me conectando ao servidor MCP chamado file system FS. Ao me conectar, consigo ver o nome do servidor, o protocolo, os recursos, as ferramentas e os comandos disponíveis. Por exemplo, posso obter uma lista dos comandos do servidor de sistema de arquivos.

13:08 Posso obtê-los em formato JSON, então, mais uma vez, é algo que você pode usar como código, porque é JSON. Também posso me conectar a servidores MCP remotos. Primeiro, preciso fazer login. Vamos usar o servidor MCP da Apify. Ele abre um navegador onde faço a autenticação. Basta escolher uma conta. Agora, o MCPC

13:38 está conectado e salvou as credenciais com segurança no chaveiro local do sistema operacional. Então, podemos usá-las para nos conectar com segurança a diferentes recursos. Vou me conectar ao servidor MCP da Apify. Espero que funcione. Certo. Agora, recebo as informações básicas sobre o servidor, incluindo instruções. Na verdade, o protocolo MCP tem instruções, pelas quais o servidor explica o que faz, mas a maioria dos clientes ainda não oferece suporte a esse recurso básico, o que é meio absurdo.

14:10 O MCPC oferece suporte a isso, claro. Ele também pode listar as ferramentas, os comandos disponíveis e assim por diante. Então, quando executo o MCPC, vejo que tenho três sessões MCP. Na verdade, o MCPC mantém essas sessões. Basicamente, se eu sair, ele as mantém ativas e posso voltar a elas mais tarde, certo? Ou seja, ele mantém o estado para você. E você pode simplesmente se conectar ou configurar tudo uma vez e depois deixar o seu Claude Code ou Codex usar essa configuração, sem precisar se preocupar em compartilhar a

14:40 configuração entre esses diferentes agents. Basicamente, o agent simplesmente usa a mesma configuração. Eu estava falando da descoberta progressiva de ferramentas, certo? O MCPC tem um comando chamado grep. Por exemplo, posso procurar todas as ferramentas ou servidores que contenham a palavra “find”, certo? E vejo que o servidor MCP FS, o servidor de sistema de arquivos, tem três ferramentas que correspondem a esse termo de pesquisa, e a Apify tem quatro.

15:11 Certo. Posso tentar outro comando. Por exemplo, posso tentar executar uma ferramenta chamada Apify Regular Browser, que é uma das nossas ferramentas para pesquisar na web. O protocolo MCP tem esse novo recurso chamado tarefa assíncrona. Mais uma vez, a maioria dos clientes não oferece suporte a ele, mas aqui basta acrescentar task e executar essa tarefa de forma assíncrona. Isso significa que ela começa no servidor enquanto eu posso fazer outras coisas localmente e, depois, buscar os resultados, verificar o andamento e assim por diante.

15:42 Podemos ver que está sendo executada em segundo plano e, depois, posso obter os resultados ou me desconectar e fazer outra coisa. Então, mais uma vez, o MCPC é um dos poucos clientes que oferecem suporte a tarefas assíncronas, o que é bem legal, e você pode abrir o resultado imediatamente no seu navegador. Certo, vou me desconectar. Por exemplo… Estou ficando um pouco sem tempo, então vou continuar a apresentação. Fizemos algumas demonstrações aqui.

16:14 E, na verdade, você pode usar o comando d-JSON para retornar tudo em JSON e depois encadear esses comandos para criar basicamente scripts de shell que executam servidores MCP em segundo plano sem desperdiçar seus tokens de contexto. A propósito, recentemente também adicionamos suporte para X4 X42, porque descobrimos que não há muitas ferramentas para gerenciar suas carteiras locais. Então, também adicionamos isso ao MCPC. Como agora oferecemos suporte ao X42, ele é, na verdade, uma das

16:44 ferramentas mais legais que você pode usar para X42. Há comandos especiais, como, por exemplo, proxies para isolamento em sandbox. Não vou entrar em detalhes, mas também queríamos entender qual é o desempenho do MCP e do MCPC em comparação com o CLI nativo. Então, criamos esse novo framework chamado connector evals. Normalmente, evals ou benchmarks comparam diferentes agents. Por exemplo, o Terminal Bench compara se o Codex é melhor que o Claude Code. Mas nós meio que invertemos isso e criamos um framework para comparar diferentes conectores entre si. É mais eficaz usar o CLI ou MCP ou MCPC ou qualquer outra ferramenta? Então, aqui estão alguns resultados, na verdade. E dá para ver que, acho que todos esses testes usam Claude Code com Sonnet 5. Por exemplo, neste gráfico, o eixo x mostra quanto tempo a tarefa levou para ser concluída,

17:14 e o eixo y mostra o custo em tokens. Dá para ver que o MCPC e o CLI têm um desempenho bem parecido, enquanto o MCP bruto terminou mais rápido, por algum motivo, mas consumiu mais tokens. Este é outro teste. De novo, o MCPC e o CLI são bastante comparáveis. O MCP bruto tem um desempenho pior. E há mais um, com resultado parecido. Na verdade, esses testes ainda estão em estágio bem inicial. Mas fiquem à vontade para conferir

17:45 e contribuir. Então, por favor, parem de dizer que o CLI é melhor que o MCP, porque MCP mais CLI é o melhor. Muito obrigado pela atenção.

18:15 e contribuir. Então, por favor, parem de dizer que a CLI é melhor que o MCP, porque MCP mais CLI é o melhor. Muito obrigado pela atenção.

Transcrição original

[00:12] Cool. Hello everyone. Welcome to our talk. It’s like one of the last talks of uh the conference. So, thanks for coming. U this talk is called MCP doesn’t suck, your agent does. My name is Han Chern. I’m the founder and CEO of Appify. And I don’t know if you’ve seen the these ones around here. Maybe I’ll zoom here. Actually, we went great lengths to uh bring people to this talk. Uh didn’t quite work out. But anyway, thanks for coming. So, as you know, uh MCP is a standard to

[00:43] securely access tools and resources, right? Basically, standard for agentto tool interaction and it’s been introduced by by Antropic about almost two years ago and actually it took the world by storm, right? And actually last year MCP became the darling of the AI world like really like like a lot of people build their servers uh I think like now there’s like 10 to 15,000 servers right a lot of clients adopted it and actually it became a standard you know like used by cloud or chpt to plug tools and connectors to

[01:14] your to your AI agents. There was like even so many MCP uh servers that that people had to create registries of MCP servers and there were so many registries that people have to create even MCP server registry registries. Pretty wild times, right? So when MCP connects agents with tools, everybody loves MCP, right? Right. Well, not exactly. Actually, especially last year, there have been a lot of hate about MCP. Like for example, Antropic admits that MCP sucks from to MCP is the wrong

[01:45] abstraction. Antropic is trying so hard to fix MCP. MCP was a mistake. Long live CLIs, right? MCP is dead in the water. Open Claw has shown me that API and CLI will will win. There is a reason I didn’t add MCP support to Open Claw except via MCorter MCP to CLI converter. Oh, that’s interesting. MCPS are mostly useless. I’ll die on this hill if I have to. Every MCP could have been a deterministic CLI. That’s

[02:16] what I’m going to do next year. And from Gary Tan who’s going to speak today as well, MCP sucks honestly. Oh my god. And uh Peter levels, thank god MCP is dead. So I’m like what’s happening? Why are everybody hitting MCPS, right? This is crazy. So first like let’s look at the problem like what are people talking about? So the most slighted problem was like hey MCP eats too much context and actually that’s true. I mean the first like way how agents implemented MCP was very naive right they were like hey MCP

[02:47] gives you tools so there is like if you have 10 MCP servers you just like 10 MCP tools so there’s like 100 tools and agents would register all these tools in the context right away so before you actually even ask any question MCP would like eat like 100 like you know tools in in your context maybe like onethird of your context would be gone without actually like doing any work and honestly this is pretty crazy I mean if you think about it right and then you would be calling tools basically adding to the context the results would be added back to the context again and basically the context would just like

[03:18] grow very long and the wrote over time you lose accuracy it cost a lot of money and so on it’s very ineffective way how to do that but that’s not the problem of MCP that’s problem of of the harness and if you look at the MCP specification what it says about like how you should design the harness like it says absolutely nothing it’s up to the implementation right so it’s your job when you’re building your agent to make sure you use MCP effectively. It’s not a problem of the protocol, right? So what are the solutions of this? So

[03:49] first solution like fairly naive is like hey let’s split the context into sub agents. So if there’s some task you can basically delegate it to a new sub agent it own context. So basically it doesn’t pull you the main context window. I mean that’s great but you still have to pay money for those tokens. It doesn’t go away. And the problems like u before are still still around. For example, if the MCP tool uh returns some some sensitive results like password, basically it

[04:20] stays in your context and it can be abused by other other tool calls or basically like u application, right? So basically context is is is a really bad place to uh pass sensitive value or like large data and sub agents only push that problem a little further but still don’t remove it. So what’s the solution number two? Uh I think it was end of the last year. I think first uh Antropic and then cursor introduced something which is called progressive tool discovery. And uh I mean it’s it’s so simple that it

[04:50] hurts even that like people have to you know like do this. But uh the idea was like hey if we put all the tools into the context it just consumes too much tokens. So how about we put those tools into the context progressively only when you need them right? So for example, Antropic uh in cloth introduced this like tool just called like tool search tool and basically that tool helps you find other tools and only add those to the context when needed, right? And it kind of makes sense. I why would you like add all the 100 tools in your

[05:20] context all the time if you rarely need them? Like typically you just like need maybe one or two and actually this way you can save like huge amount of context right away. basically makes it more effective, cheaper, you know, faster to run and so on. So it kind of makes sense, right? So like every everybody should be doing it. No. And then solution number three also introduced uh end of last year by Cloudflare. It’s called code mode, right? And the big idea is like hey let’s not treat MCP

[05:51] tools as you know like functions like that you you know you would have to the context but treat them as as a code and actually models are really good at writing and and analyzing code because you know they can use tools like grab they can find the right you know definition like they can navigate the code pretty well and that way they can navigate also the two descriptions and information about the tools and so on. So it’s it’s a pretty like simple idea very straightforward that so let’s convert tools MCP tools and servers into

[06:21] into code and treat it as code right pretty simple but extremely effective right because it it turns out models are better at writing and calling code code than than than calling tools because cool tool calling is an artificial construct basically that we have to teach the the LLMs to do it’s like it doesn’t exist like in a in a real world like in real training data like this those has to like syn syn synthetized and put into the model. But unfortunately uh even cloud implementation of code

[06:51] mode is like very difficult to use. It’s like very like tied to their platform and it’s it’s not really straightforward you know. So not a lot of people are actually using code mode you know uh except few examples right so still most agents are living in the dark ages and this they don’t they don’t support these features you know and most mcp clients and it’s a pity because the protocol has evolved a lot a lot of new things but the clients don’t support it so how are CLI different you know why people compare CLI to MCP well actually

[07:24] agents never load the full CLI into context it’s not like the agent would explore all the all the commands of the CLI tool like find a help and put it in the context. No, no, it does it it it’s doing it progressively by default. So the agent uh is calling the CLI tool only when needed and sometimes actually it knows the tools by heart like so for example the basic Linux commands the agents already know because they have seen it training data since you know forever but also they can like learn about the tools uh the CLI tools from help because

[07:56] there is help and actually uh agents run CLI tools uh as code by default right so in order to run CLI tools you have to have some runtime like sand sandbox or machine that you can like run the commands in. So and when you like invoke these like CLI tools I mean it’s code mode by by default you you run it as a code it’s like bash code but it’s still code so you know it’s basically like code mode like uh is available to to CLI from scratch while

[08:27] MCP only had to like sort of like grow into it you know and this is important like agents know the shell by heart I mean Linux shell Linux or Unix has been around from like 1969 when uh Ken Thompson and Dis Richie actually created Linux and when you look like the basic terminal that black box of like 80 columns and I don’t know 25 rows it’s like really like condensed representation of what’s happening in the computer right like like every bite every every character there is is

[08:59] optimized you know like over 40 years to really convey only the most important information right so it’s really really like optimized you know for for people but it turns out like agents like this as And agents actually know shell by heart. They really know like how to do call call C cli commands, how to pipe them. They really know like how to use a shell well because they have seen it in so much training data. Plus for for the AI labs, you can actually synthesize like infinite amount of training data from using shell, right? You can just like pipe different commands together, explore the commands, extract

[09:29] information from your manual pages and basically feed this all to the models. So they know the shell really really well. But CLI are a local black box with no standard outend transport protocol. So basically I mean they are literally a black box. It’s a black terminal thing right and you don’t see what’s happening inside. So for example if you wanted to like you know instrument like these like CLI uh in your enterprise you would have to sort of like in introspect the protocol and like uh oh are they using API or websockets or you know you don’t

[09:59] know you cannot inject their credentials into that. So basically CLI are great for local interface but for remote access MCP is better. I mean I have yet to see uh some agent like using CLI connectors it doesn’t exist because it doesn’t make sense. You have MCP connectors. So how about we use MCP for standard remote access and CLI for local agent access or local agent interface with all the goodies like uh that I described. Well, that way you can provide all the protocol features of MCP through a simple tool call that all the

[10:31] agents already know which is called bash right. So basically the full complexity of MCP is hidden behind single tool call bash and you don’t need to worry about the sessions authorization all out nothing. So uh ladies and gentlemen let me introduce you uh MCPC which is like our universal CLI client for MCP. uh we this started as a hobby project uh during the uh December so or also known as winter of cloth and u from a hobby

[11:02] project it actually like u you know evolved into probably the the most uh featurerich uh MCPC like cline on on the market. So you can install it like through npm or ban and how it works right. So the design goes for MCPC where hey we really want to support support like everything the MCP protocol has to has to offer you know task resources proons basically everything right and maximum compatibility to make it really easy to run anywhere anytime. MCP is like super lightweight. There is no LLM.

[11:33] It’s just a a wrapper. It’s a CLI wrapper over the MCP protocol that sort of like abstracts away the protocol thing but nothing else. It’s very it’s supposed to be easy to use for both agents and humans obviously and it needs to support code mode all the way and actually every command in MCPC has like a option to run with D-JSON which returns just like pure JSON representation of the data again MCP specification compliant. So actually you can compose the different like uh CLI

[12:03] calls together with tools like jq pipe them together and really build like a sequences of of of of tools uh of tool calls in code. So I’ll show you how it looks like uh just a quick demo u we still have some time. So here is the basic interface of mcpc right. So it has help actually the help like we optimized a lot the help to kind of like make it really easy for agents to pick up right away without any external skills. Right. So uh first let me

[12:36] connect to uh a local server. Oh no no no. Uh so it supports stddio which is like the local processes uh running on your computer. So here I’m connect to MCP server called file system FS and when I connect I can suddenly like see the server name protocol capabilities tools and available commands right so for example I can get a list of the commands of the of the file system server

[13:08] I can get them get them in JSON format so again this is like something you can use as a code because it’s JSON right and then I can also connect uh to remote MCP servers So first I need to uh login. So let’s say appy mcp server. I it opens a browser where I run authentication. So just like pick some uh pick some account. So now uh the MCPC

[13:38] is is is logged in and basically it’s it securely save the credentials into your local OS keychain. So we can now use them like uh to connect securely to to different resources. So uh let me connect to Appify MCP server. I hope this works. All right. So now I get like the basic information about the server including instructions. You know actually MCP protocol has instructions where server kind of explains what it does but most clients still don’t support this basic primitive right which is kind of crazy.

[14:10] MCPC are supported of course then it can list the tools available commands and so on. So now when I run MCPC I see I have like three MCP sessions. Actually MCPC purses those sessions right? So basically if I go away it keeps those sessions alive and I can come back to them later right? So basically it keeps a state for you and actually you can just connect or set up once and then like let your code cloud code or codex use it without you sort of having to worry about it and sharing the

[14:40] configuration between these different agents. Basically the agent just just just use the same setup. And uh I was mentioning the progressive tool discovery, right? Uh so MCPC has this command called grap and I can for example like look for all tools or servers that contain the word find, right? And I see there is like the the the FS the fast system MCP server has like three tools that match this this uh this the search string and API has four

[15:11] right. So I can you know try another command for example I can try to run a tool called ampify regular browser which is like one of our tools to search web and actually MCP protocol has like this new feature called asynchronous task again most clients don’t support it but here I just like add task and I run this task asynchronously that means like it starts on the server and I can like you know do locally other things you know and then just like pick up the results later and you know check the progress and so

[15:42] So we can see it’s running in the background and then eventually I can get the results or I can actually detach you know and do something else. So again like MCPC is one of the few clients that supports uh it supports uh asynchronous task which is pretty cool and you can get it right away in your in your uh browser. Okay, I’ll detach and for example okay I’m running out of time a little bit so I’ll continue with the presentation there. So we did some demos here

[16:14] and actually you can use the the d-JSON command to uh return everything in JSON and then pipe these together to create like basically like like shell scripts that run MCB servers in the background without wasting your your your context tokens. By the way, recently we added support also for X4 X42 because it turns out uh there are not too many like tools to manage your local wallets. U so we added it to to MCPC as well. So because like we want we are we are supporting X42 now. So uh it’s actually one of the

[16:44] coolest tools like you can use for X42 now. uh there are like special commands like for example proxies for sandboxing you know I will not go into detail there but also we wanted to to to understand what is the performance of the MCP MCPC and versus like native CLI right so we will we build this like new uh framework called connector evals and like typically like evals or you know this like benchmarks uh compare like different agents like hey for example like terminal bench is comparing whether

[17:14] codeex is better than cloud code and so But we sort of like flipped it and we built a framework to to compare like how different connectors compare with each other, right? Is it is it more effective to UCLI or MCP or MCPC or whatever tool. So here are a few results actually and you can see that like the this is I think uh these all these tests are using cloud code with sonet 5 and you can see that for example this is this chart the x x is is the time how long did it take

[17:45] to finish the task and y chart is the cost of tokens right and you can see that like mcpc and cli are actually performing pretty similarly while row mcp finish faster for whatever reason but actually consume more tokens. It’s like another test. Again, MCPC and CLI are fairly comparable. Raw MCP like performs wars. And there’s another one again similar result, right? So, actually these tests are still like fairly early. Uh but like uh yeah, be happy if you come and check

[18:15] it out and um contribute. So, please stop saying CLA is better than MCP because MCP plus CLI is the best. Thank you very much for your attention.