Jan Čurn, founder and CEO of Apify, examines the 'MCP is dead' backlash and argues that common complaints such as context bloat and token burn stem from naive client implementations rather than the MCP protocol itself. He covers three industry fixes: sub-agents, progressive tool discovery, and Code Mode; explains why CLIs feel better to agents locally while MCP suits remote, authenticated access; demos mcpc, Apify's open-source universal CLI client for MCP (stdio and remote servers, OAuth, persistent sessions, grep-based tool discovery, async tasks, x402); and shares early results from Connector Evals comparing raw MCP, CLIs, and mcpc. Recorded at the AI Engineer World's Fair 2026 in San Francisco. # Channel Identity Observations — "MCP Doesn't Suck. Your Agent Does." (Jan Čurn, Apify) ## Speaker / Channel Self-Description - The speaker **explicitly identifies himself as founder and CEO of Apify**: > "My name is Han Chern. I'm the founder and CEO of Appify." - The talk is a **conference presentation** (one of the last talks of a conference; another speaker, Gary Tan, is mentioned as speaking the same day), suggesting the channel publishes or distributes conference talk content rather than (or in addition to) studio-produced tutorials. ## Explicit Claims About Products / Projects Presented - **mcp-cli ("MCPC")** is introduced as Apify's project: - Framed as "our universal CLI client for MCP" - Origin claim: "this started as a hobby project… during the uh December so or also known as winter of cloth" and evolved into "probably the the most uh featurerich uh MCPC like cline on on the market" - Distribution: "You can install it like through npm or ban [bun]" - **Connector evals framework**: "we build this like new uh framework called connector evals" to compare connectors rather than agents. - Recent feature claim: "recently we added support also for X4 X42" (local wallet management). ## Observable Presentation Patterns - **Technical depth**: Detailed discussion of MCP specification, progressive tool discovery, Cloudflare's code mode, sub-agent context splitting, and benchmark methodology (token cost vs. task duration). - **Live demonstration**: The speaker performs an on-stage demo connecting to local (stdio) and remote (Apify) MCP servers, showing session persistence, `grep` for tool discovery, and asynchronous tasks. - **Argumentative/opinion-driven structure**: The talk opens by cataloguing public criticism of MCP ("MCP sucks honestly", "MCP is dead in the water", "Every MCP could have been a deterministic CLI") and argues the problem lies with agent implementations, not the protocol — closing with "MCP plus CLI is the best." - **Evidence via benchmarks**: Performance claims are backed by charts comparing MCPC, CLI, and raw MCP using "cloud code with sonet 5," though the speaker caveats: "these tests are still like fairly early." ## Intended Audience - **AI agent developers and MCP tool builders** — evidenced by: - Assumed familiarity with terms like context windows, tool calling, stdio transports, sandboxes, keychains, `jq` piping - Direct address to builders: "it's your job when you're building your agent to make sure you use MCP effectively" - Closing call for community contribution to evals: "be happy if you come and check it out and um contribute" ## Claimed Scope - The channel's demonstrated scope (from this video) covers: - AI agent architecture and MCP protocol advocacy - Apify's developer tools (Apify MCP server, mcp-cli, connector evals) - Developer-conference talk content ## Notes on Distinguishing Claims vs. Demonstration - **Creator claims** (unverified in material): "most featurerich MCPC client on the market," MCPC being "one of the few clients that supports asynchronous task," benchmark superiority of MCP+CLI. - **Demonstrated**: live CLI workflow, session persistence, JSON output mode, tool-search command, async task kickoff — shown during the demo portion of the transcript. - No curated metadata was supplied; identity observations rest solely on title and transcript. # Delivery Observation — "MCP Doesn't Suck. Your Agent Does." (Jan Čurn, Apify) ## Overall register Conversational, informal conference-talk delivery with frequent filler ("like", "you know", "right?") and direct audience address. The speaker alternates between problem framing, survey of prior solutions, live demo, and a punchy closing thesis. ## Recurring rhetorical habits - **Tag questions / audience check-ins** appear throughout: > "it took the world by storm, right?" > "Pretty wild times, right?" > "So it kind of makes sense, right?" > "So, please stop saying CLA is better than MCP" - **Contrast framing as narrative engine** — the talk is structured around "X vs. Y" (MCP vs. CLI, context bloat vs. progressive discovery): > "So basically CLI are great for local interface but for remote access MCP is better." - **Complaint-then-pivot pattern** — criticizes clients, not the protocol: > "but that's not the problem of MCP that's problem of of the harness" > "most clients still don't support this basic primitive right which is kind of crazy." ## Teaching habits - **Repetition for emphasis**, often with intensifiers: > "agents know the shell by heart I mean Linux shell..." > "And agents actually know shell by heart. They really know..." - **Historical/contextual anchoring** to explain why things are the way they are: > "Linux or Unix has been around from like 1969 when uh Ken Thompson and Dis Richie actually created Linux" > "every character there is is optimized you know like over 40 years" - **Concession before rebuttal** — grants the critic's point, then reframes: > "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" - **Enumerated solutions** — explicitly numbered progression: "first solution... solution number two... solution number three." - **Live demo with candid, self-deprecating narration**: > "Oh no no no." > "I hope this works. All right." > "Okay, I'm running out of time a little bit so I'll continue with the presentation" ## Vocabulary tendencies - Hedged superlatives with softeners: "probably the the most featurerich", "extremely effective", "so simple that it hurts". - Casual intensifiers: "honestly this is pretty crazy", "which is kind of crazy", "pretty wild times". - Colloquial framing of tech critiques via quoted headlines: > "MCP was a mistake. Long live CLIs... MCP is dead in the water." > "MCP sucks honestly. Oh my god." ## Recurring thematic phrases - **"by heart"** (used multiple times about agents knowing the shell). - **"black box"** — applied twice to CLI: > "But CLI are a local black box with no standard outend transport protocol." > "I mean they are literally a black box." - **Client-blame framing**: "most agents are living in the dark ages", "clients don't support it". ## Uncertainty notes - The speaker self-introduces as "Han Chern" per the transcript, which conflicts with the title's "Jan Čurn" — transcription uncertainty, not inferred. - Filler density ("like", "you know") is consistently high throughout, so it is a stable pattern, but exact counts are not reported here. - Emotional state, confidence, or motivation is not observable and is not claimed. # Position Record: "MCP Doesn't Suck. Your Agent Does." **Source:** Video `01a15ca7-21e4-7ab5-81df-861b1be7bab7` **Speaker:** Jan Čurn, Apify (per curated title metadata; the transcript renders the name as "Han Chern" and identifies the speaker as founder and CEO of Apify) **Format:** Conference talk with a live tool demonstration **Basis:** Transcript only. No timestamps, slides, or cited sources are provided. --- ## 1. Central Thesis > "Please stop saying CLI is better than MCP because **MCP plus CLI is the best**." The speaker argues that criticism of MCP is largely misdirected. Problems attributed to MCP are said to stem from **agent harness implementation** and missing client support, not from the protocol itself. The proposed synthesis is: - **MCP** for standard *remote* access - **CLI / bash** for *local* agent interface - A single bash tool call can expose the full MCP protocol surface to agents --- ## 2. Background Claims - MCP is a standard for secure agent-to-tool and agent-to-resource access, introduced by Anthropic roughly two years before the talk. - The speaker reports growth to an estimated **10,000–15,000 servers**, broad client adoption, and the emergence of registries of registries. - **Attributed critiques (as reported by the speaker, not independently verified):** - Anthropic reportedly said MCP "sucks" and is "the wrong abstraction." - Open Claw's creator reportedly said "API and CLI will win." - Gary Tan, described as a speaker later in the same conference, reportedly said "MCP sucks honestly." - Peter Levels reportedly said "thank god MCP is dead." - Another unnamed quote: "Every MCP could have been a deterministic CLI." > These are secondhand quotations relayed by the speaker. Their accuracy and context are not established in the transcript. --- ## 3. Claimed Problems with MCP ### 3.1 Context Bloat - **Claim:** The naive implementation registers all MCP tools in context up front. With 10 servers, roughly 100 tools could be loaded before any work begins, potentially consuming "maybe one-third" of the context window. - **Consequences stated:** Accuracy loss over time, high cost, and ineffective operation. - **Attribution of cause:** The speaker explicitly places this on the **harness**, not the protocol. The MCP specification "says absolutely nothing" about harness design, so the implementer is responsible for using it effectively. ### 3.2 Sensitive Data in Context - **Claim:** Tool results (e.g., passwords) that enter context can be read or abused by other tool calls or the application. - **Stated implication:** Context is a poor place to pass sensitive values or large data. --- ## 4. Evaluated Mitigations | Approach | Speaker's Assessment | Stated Limitation | |---|---|---| | **Sub-agents** | "Great" but insufficient. Splits context. | Tokens still cost money; sensitive values and large data still circulate. "Only push that problem a little further." | | **Progressive tool discovery** (Anthropic's tool search, then Cursor) | "So simple that it hurts"; "makes sense." | The speaker then answers "So everybody should be doing it? **No.**" No reason is stated in the transcript for this reversal; the sentence is left unexplained. | | **Code mode** (Cloudflare, late last year) | "Pretty simple," "extremely effective." | Reportedly "very difficult to use," tied to Cloudflare's platform, and rarely adopted outside a few examples. | ### 4.1 Reasoning Behind Code Mode - Models are better at writing and calling code than at tool calling. - Tool calling is described as an "artificial construct" that must be synthesized into training data. Code is described as abundant in real training data. - Models can navigate code definitions and tool descriptions using code-navigation techniques. --- ## 5. The CLI Argument ### 5.1 Why CLI Works for Agents 1. **Progressive by default.** Agents do not load full CLI documentation. They call tools only when needed and discover usage via `--help` or existing knowledge. 2. **Prior knowledge.** Agents "know the shell by heart," learned from extensive training data. 3. **Synthetic data advantage.** Shell usage can be used to generate large training corpora (piping commands, reading manual pages). 4. **Code by default.** Running CLI tools is "code mode by default" in the form of bash. ### 5.2 Historical Framing - Unix/shell is described as optimized over roughly 40 years for human consumption. - **Transcript note:** The speaker attributes the shell's origins to "Linux… from like 1969… Ken Thompson and Dis Richie." The described origin (1969, Thompson and Ritchie) corresponds to **Unix**, not Linux. The record preserves the speaker's wording; the distinction is noted for accuracy. ### 5.3 Limits of CLI (as stated by the speaker) - CLIs are "a local black box with no standard output or transport protocol." - They are hard to instrument in an enterprise. One cannot easily tell whether a tool uses APIs or websockets, or inject credentials. - **Conclusion:** "CLI are great for local interface but for remote access MCP is better." - The speaker says they have "yet to see" an agent using CLI connectors for remote access. ### 5.4 The Synthesis - MCP is used for standard remote access. - CLI is used for local agent access. - The full MCP protocol complexity (sessions, authorization, and similar features) is "hidden behind single tool call bash." --- ## 6. Product Presentation: MCPC **Stated affiliation:** The speaker is founder and CEO of Apify, which the speaker presents MCPC as connected to. The transcript does not contain further information about the product's commercial model, and no inference is drawn about motives. **Described characteristics:** - A universal CLI client for MCP, installable via npm or Bun. - Origin: a hobby project during "winter of Claude Code" (December), now described as "probably the most feature-rich MCP client on the market," with a comparison to Cline. - **Design goals:** full MCP feature support (tasks, resources, prompts), maximum compatibility, ease of use for both agents and humans, and first-class support for code mode. - Every command supports a `--json` option producing MCP-compliant JSON, which can be piped through tools such as `jq`. - Lightweight: "no LLM, just a wrapper." **Features demonstrated (live, with timing constraints acknowledged):** - Connecting to a local stdio server (filesystem) and listing capabilities and commands. - Remote authentication via browser, with credentials stored in the OS keychain. - Connecting to the Apify MCP server and reading server instructions, which the speaker notes most clients ignore. - Persistent sessions that survive the user leaving, shareable across agents such as Claude Code and Codex. - `grep`-style progressive discovery across tools and servers. - Asynchronous task execution (an MCP feature the speaker says most clients lack), run in the background and checked later. - Recent addition of x402 wallet support, described as "one of the coolest tools" for that protocol. The speaker says the group lacked local wallet-management tools and so added this to MCPC. - Sandboxing proxies, which the speaker chose not to detail. **Demo limitation:** The speaker said "I'm running out of time a little bit" and skipped part of the presentation. --- ## 7. Benchmark Claims: Connector Evals - **Method:** A new framework, "connector evals," compares connectors (CLI, MCP, MCPC) rather than agents. It is described as an inversion of benchmarks such as Terminal Bench, which compare agents. - **Setup (as stated):** Tests appear to use Claude Code with a model transcribed as "Sonet 5." The transcript's model name should be treated as uncertain. - **Metrics:** Time to completion (x-axis) and token cost (y-axis). **Reported results (qualitative only; no numbers in transcript):** - MCPC and native CLI perform **similarly**. - Raw MCP finishes **faster** "for whatever reason" but **consumes more tokens**. - A second test showed a similar pattern, with MCPC and CLI comparable and raw MCP performing worse on the cost metric. **Qualifications stated by the speaker:** - "These tests are still fairly early." - Invitation for others to check and contribute. --- ## 8. Tensions and Unresolved Points 1. **Harness versus protocol.** The speaker says context bloat is a harness problem, not an MCP problem. Yet the speaker also argues that most clients fail to support modern MCP features, which is a client-implementation issue. The record does not resolve whether the protocol's design contributes to these failures. 2. **Progressive discovery.** Presented as obvious and beneficial, then immediately qualified with "No." The reason for the qualification is not stated. 3. **Code mode.** Described as "extremely effective" and natural to models, yet also "very difficult to use" and "not a lot of people are actually using" it. The speaker does not reconcile effectiveness with low adoption. 4. **Remote versus local.** The speaker says CLI is "a local black box" and unsuitable for remote access, yet the bash-based bridge (MCPC) is presented as a way to deliver remote MCP through local CLI. The argument relies on MCPC to bridge this gap, and the transcript does not discuss security implications of exposing remote credentials through local shells beyond keychain storage. 5. **Benchmark evidence.** Results are described as early and are qualitative in the transcript. The speaker's "MCP plus CLI is best" conclusion is stronger than the reported comparisons (CLI and MCPC are similar; raw MCP is faster but more expensive) directly support. 6. **Speaker affiliation.** The speaker leads Apify and presents a product (MCPC) and an evaluation framework. These are stated facts about the presenter; the transcript does not discuss conflicts of interest. 7. **Attributed quotes.** Several critiques of MCP are attributed to named individuals as relayed by the speaker. They are not verified within the transcript. --- ## 9. Transcript Notes - The speaker's name appears as "Han Chern" in the transcript; the title identifies the speaker as Jan Čurn. - Some terms appear to be transcription errors: "Antropic" (Anthropic), "Appify" (Apify), "cloth" (Claude), "Dis Richie" (Dennis Ritchie), "Sonet 5" (Sonnet, version uncertain), "Open Claw" (OpenClaw). - The speaker refers to "Linux" in a passage describing Unix history; see Section 5.2. # Video Attribution & Provenance Record ## Speaker Identification | Speaker | Role | Notes | |---|---|---| | **Jan Čurn** (transcribed as "Han Chern") | **Speaker — Founder & CEO, Apify** (transcribed as "Appify") | Self-identified on stage: *"My name is Han Chern. I'm the founder and CEO of Appify."* | - **Format:** Conference talk — the speaker states it is *"one of the last talks of the conference."* No moderator, panelists, or other identified voices. - **No narrator or guest speakers** appear in the transcript. ## Third-Party Parties Referenced (claims attributed by the speaker) ### Organizations / People - **Anthropic** (transcribed at times as "Antropic") — credited as the introducer of MCP ("introduced by Anthropic about almost two years ago"); credited with introducing **progressive tool discovery** and the **tool search tool** in Claude. - **Cursor** — also credited with introducing progressive tool discovery. - **Cloudflare** — credited with introducing **Code Mode** (treating MCP tools as code). - **Gary Tan** — described as *"going to speak today as well"*; quoted on a slide: *"MCP sucks honestly."* - **Peter Levels (levelsio)** — quoted on a slide: *"thank god MCP is dead."* - **Ken Thompson and Dennis Ritchie** (transcribed as "Dis Richie") — cited by the speaker as creators of Unix/Linux (transcript says "created Linux"), ~1969. - **Open Claw (open-source agent)** — referenced via quoted community posts; associated with the CLI-over-MCP position. - **MCP community quotes** — the speaker recites a series of critical quotes/slides ("Anthropic admits that MCP sucks," "MCP is the wrong abstraction," "MCP was a mistake. Long live CLIs," "MCPs are mostly useless," etc.). These are presented as slide content quoted by the speaker; **original authors of individual quotes other than Gary Tan and Peter Levels are not identified in the transcript.** ### Tools / Products Mentioned - **MCPC** — the speaker's own project: *"our universal CLI client for MCP,"* started as a hobby project in December ("winter of Claude"), installable via npm or brew. **This is promotional content for the speaker's own product** — flagged as promotion. - **Apify MCP server** — speaker's company product, used in the demo. **Promotional.** - **Connector Evals** — benchmark framework built by the speaker's team comparing connectors (CLI vs. raw MCP vs. MCPC). **Promotional.** - Others referenced: Claude Code, Codex, Terminal Bench, jq, jq-piped shell composition, stdio transport, X402 (transcribed "X4/X42") payment support in MCPC (**promotional**). ## Provenance of Claims - All technical claims (MCP server counts of "10 to 15,000," benchmark results with "Claude Code with Sonnet 5," etc.) are **unverifiable speaker assertions** made live; no documents, papers, or datasets are cited beyond the slides shown. - Benchmark charts are described but results are characterized by the speaker as *"still fairly early."* - Quoted criticism of MCP originates from unnamed social media posts plus identified quotes from Gary Tan and Peter Levels. ## Availability & Limitations - **Comments availability:** Not stated anywhere in the transcript — unknown. - **Curated metadata:** None supplied beyond title and video ID. - **Slides:** Quoted indirectly through the speaker's reading; slide text cannot be independently verified from the transcript alone. - **Transcription noise:** Speaker name and company name contain likely transcription errors ("Han Chern" / "Appify" vs. title's "Jan Čurn" / "Apify"); title metadata is treated as authoritative for identity. 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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. 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 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 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 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 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. 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 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 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 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 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 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 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 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 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.