Anthropic admits that MCP sucks 🔗 **Source:** [Anthropic admits that MCP sucks](https://www.youtube.com/watch?v=1piFEKA9XL0) > [!note]+ Document Notes > tags: [ai-agents, mcp, software-architecture] > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=1piFEKA9XL0 > date created: 2024-12-19 10:30 > > # 🏷️ Title: Anthropic admits that MCP sucks > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Evaluate current MCP implementations for token efficiency — 00:00-02:15 #ai-tooling - [H2] Research code execution alternatives to direct tool calls — 08:45-12:30 #development - [H3] Implement progressive tool discovery in agent workflows — 15:20-18:00 #optimization ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Anthropic MCP Blog](https://www.anthropic.com/news/mcp-code-execution) - [Cloudflare Code Mode](https://blog.cloudflare.com/code-mode) ## 📝 Summary - Anthropic published a blog post acknowledging that MCP (Model Context Protocol) has significant efficiency problems when used traditionally - The core issue: loading all tool definitions upfront and passing intermediate results through context makes agents slower, more expensive, and less effective - Anthropic's solution mirrors Cloudflare's "code mode" - having agents write code to interact with MCP servers instead of direct tool calls - This code execution approach reduces token usage by up to 98.7% compared to traditional MCP implementations - The admission suggests fundamental flaws in the MCP specification that require workarounds to be practical ## 📖 Main Content Model Context Protocol (MCP) was designed as a universal standard for connecting AI agents to external tools and data sources. However, Anthropic's recent blog post "Code execution with MCP: Building more efficient agents" reveals critical performance and usability issues with traditional MCP implementations. The fundamental problems stem from two architectural decisions: tool definition overloading (loading hundreds or thousands of tool definitions into context upfront) and intermediate result accumulation (each tool call adds to growing context windows). These issues compound as agents scale, leading to exponentially increasing token costs, slower response times, and degraded model performance. Anthropic's proposed solution involves treating MCP servers as code APIs rather than direct tool calls. Instead of loading tool definitions into context, agents explore a file system structure containing TypeScript definitions and write code to interact with tools. This approach provides several benefits: progressive tool discovery, data filtering before context inclusion, state persistence, and improved privacy through local code execution. The irony is striking - MCP's creators are advocating for a workaround that essentially bypasses their own protocol's design. The code execution approach achieves 98.7% token reduction compared to traditional MCP usage, suggesting the original specification may be fundamentally flawed for practical applications. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=1piFEKA9XL0?t=0) — [H1] MCP Ecosystem Problems - Key idea: More companies building MCP observability tools than useful MCP products - Evidence: "I know way more companies building observability tools for MCP stuff than I know companies actually making useful stuff with MCP" #### ⏱️ [02:15](https://www.youtube.com/watch?v=1piFEKA9XL0?t=135) — [H2] Anthropic's Admission - Key idea: Anthropic acknowledges MCP inefficiency in their own blog post - Evidence: "Direct tool calls consume context for each definition and result. Agents scale better by writing code to call tools instead" #### ⏱️ [04:30](https://www.youtube.com/watch?v=1piFEKA9XL0?t=270) — [H3] Tool Definition Overloading Problem - Key idea: Loading all tools upfront wastes massive amounts of context - Evidence: "In cases where agents are connected to thousands of tools, they'll need to process hundreds of thousands of tokens before reading a request" #### ⏱️ [06:45](https://www.youtube.com/watch?v=1piFEKA9XL0?t=405) — [H2] Context Window Accumulation - Key idea: Each tool call carries forward all previous context, exponentially increasing costs - Evidence: "Every additional tool call is carrying all of the previous context. So every time a tool is being called the entire history is being re hit as input tokens" #### ⏱️ [08:15](https://www.youtube.com/watch?v=1piFEKA9XL0?t=495) — [H1] Code Execution Solution - Key idea: Writing code to call tools is more efficient than direct MCP tool calls - Evidence: "The agent can then write code to interact with MCP servers. This approach addresses both challenges" #### ⏱️ [11:20](https://www.youtube.com/watch?v=1piFEKA9XL0?t=680) — [H1] Dramatic Efficiency Gains - Key idea: Code approach reduces token usage by 98.7% compared to traditional MCP - Evidence: "This reduced the token usage from 150,000 tokens to 2,000 tokens. A time and cost savings of 98.7%" #### ⏱️ [13:45](https://www.youtube.com/watch?v=1piFEKA9XL0?t=825) — [H3] Progressive Tool Discovery - Key idea: Models can explore file systems to find relevant tools on demand - Evidence: "The agent discovers tools by exploring the file system, listing the /servers directory to find all available servers" #### ⏱️ [15:30](https://www.youtube.com/watch?v=1piFEKA9XL0?t=930) — [H2] Privacy and Security Benefits - Key idea: Code execution keeps sensitive data out of model context - Evidence: "Intermediate results stay in the execution environment by default. This way, the agent only sees what you explicitly log or return" #### ⏱️ [17:10](https://www.youtube.com/watch?v=1piFEKA9XL0?t=1030) — [H3] State Persistence Advantages - Key idea: Code execution provides natural state management that MCP lacks - Evidence: "With code, the state stays within the code. As long as it's in memory, it hasn't changed" #### ⏱️ [19:20](https://www.youtube.com/watch?v=1piFEKA9XL0?t=1160) — [H2] Industry Implementation Examples - Key idea: Tools like Trey suffer from MCP's tool overloading problems - Evidence: "There are 23 tools available for the solo coding environment agent... I don't use Superbase... but when I use Trey, every single request I send has this context included" #### ⏱️ [21:35](https://www.youtube.com/watch?v=1piFEKA9XL0?t=1295) — [H3] Data Processing Efficiency - Key idea: Code can filter large datasets before they reach model context - Evidence: "If you fetch a 10,000 row spreadsheet... the agent only has to see five rows with this example instead of the 10,000" #### ⏱️ [23:45](https://www.youtube.com/watch?v=1piFEKA9XL0?t=1425) — [H2] Deterministic vs Probabilistic Execution - Key idea: Code execution is deterministic while LLM tool orchestration is probabilistic - Evidence: "Code is deterministic. So when it writes the code, it's not going to 50% of the time hallucinate" #### ⏱️ [25:30](https://www.youtube.com/watch?v=1piFEKA9XL0?t=1530) — [H1] Circular Reinvention Problem - Key idea: The code execution solution essentially reinvents what MCP was trying to solve - Evidence: "Is this not reinventing MCP again?... And I'm sure this loop won't continue indefinitely as we reinvent the same 15 things over and over" #### ⏱️ [27:15](https://www.youtube.com/watch?v=1piFEKA9XL0?t=1635) — [H1] Developer vs AI People Problem - Key idea: LLM specialists designing tools for developers leads to poor outcomes - Evidence: "This is what happens when we let these LLM people make the things that we have to use as devs. Devs should be defining what devs use" ## 📚 References - [Anthropic MCP Code Execution Blog](https://www.anthropic.com/news/mcp-code-execution) - [Cloudflare Code Mode](https://blog.cloudflare.com/code-mode) - [Daytona Development Environment](https://daytona.io) - [Savala Hosting Platform](https://soy.link/savala) ## 🗣️ Paraphrase - MCP suffers from fundamental architectural problems where loading many tool definitions and accumulating tool results creates exponentially growing context windows that make agents slower and more expensive - Anthropic's own solution involves having agents write code to interact with MCP servers instead of using direct tool calls, achieving 98.7% reduction in token usage - The code execution approach provides better privacy, state management, and data processing capabilities while being more deterministic than probabilistic LLM tool orchestration ## 📰 Newsletter **MCP Reality Check: When AI Protocol Creators Admit Their Own Standard Needs Workarounds** The AI tooling world got a reality check this week when Anthropic published a blog post essentially admitting their Model Context Protocol (MCP) has serious efficiency problems. The irony? Their recommended solution is to bypass MCP's core design. The issue boils down to context bloat. Traditional MCP implementations load hundreds of tool definitions upfront and accumulate every tool result in the conversation context. This creates exponentially growing token usage that makes agents slower, more expensive, and less intelligent. Anthropic's fix involves treating MCP servers as code APIs instead of direct tool calls. Agents write TypeScript code to interact with tools, achieving up to 98.7% reduction in token usage. This approach also provides better privacy (sensitive data stays in code execution environments) and more deterministic behavior. **Key Takeaway for WordPress Developers**: This situation highlights the importance of developer-led API design. When AI specialists design tools for developers without deep software engineering experience, we get protocols that need immediate workarounds to be practical. **Resources**: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create content comparing MCP implementations vs code execution approaches, demonstrate efficiency differences in live demos - Education: Develop workshops on agent architecture patterns, focus on context management and token optimization - Developer experience: Document best practices for agent tool integration, provide templates for code execution patterns - Developer marketing: Position WordPress as developer-first platform vs AI-first tools that ignore developer needs - Community management: Moderate discussions around AI tooling standards, collect feedback on practical implementation challenges #### OSPO - Policy & Governance: Evaluate AI agent integration policies for WordPress core, establish guidelines for AI tool contributions - License Compliance: Review licensing implications of code execution environments, ensure compatibility with WordPress GPL requirements - Security Management: Assess security risks of agent-generated code in WordPress context, develop sandboxing recommendations - Software Inventory: Track AI dependencies in WordPress ecosystem, document agent integration patterns - Developer Support: Provide guidance on secure AI integration, offer consultation on agent architecture decisions #### Community - Maintainers: Support plugin maintainers adopting AI agents responsibly, provide architectural guidance for tool integration - Contributors: Create pathways for AI-assisted contributions, establish review processes for agent-generated code - Sponsors: Fund research into WordPress-specific agent patterns, support development of WordPress MCP servers - Ecosystem: Coordinate cross-project AI integration standards, share learnings from agent implementations #### WordPress - Core: Evaluate AI agent integration points, assess performance impact of agent-driven operations on WordPress - Core Performance: Profile agent workloads against WordPress sites, establish performance budgets for AI features - Core AI: Develop WordPress-specific agent patterns, create reference implementations for common use cases - Playground: Build agent testing environments, create reproducible scenarios for AI tool evaluation - Community: Develop educational resources on responsible AI agent use, create guidelines for community AI projects - Documentation: Document AI integration patterns for WordPress, create guides for secure agent implementation - Meta: Assess .org infrastructure needs for AI agents, evaluate API modifications needed for agent interactions ## 🧪 Hypotheses - Traditional MCP implementations will become increasingly impractical as the number of available tools grows exponentially - Code execution environments will become the dominant pattern for AI agent tool integration within 12-18 months - Developer-led protocol design will consistently outperform AI-researcher-led design for practical software integration - WordPress's plugin architecture provides natural advantages for agent tool discovery compared to MCP's approach ### 📊 Methodology - Benchmark study comparing MCP direct tool calls vs code execution approaches across different tool counts (10, 100, 1000+ tools) - Token usage analysis measuring context growth patterns in real agent workflows over extended sessions - Performance testing of agent response times and accuracy as tool definitions scale - Security assessment comparing attack surfaces of direct tool calls vs sandboxed code execution ### ❓ Questions - How will the MCP standard evolve to address these fundamental architectural problems? - What other AI protocols suffer from similar "designed by AI researchers for developers" problems? - Can progressive tool discovery be retrofitted into existing MCP implementations effectively? ### 🔮 Future Research - Comparative analysis of agent tool integration protocols beyond MCP - Investigation of WordPress-specific agent integration patterns and performance characteristics - Study of security implications for agent code execution in web hosting environments ### 💡 Implications - Practice: Agent developers should prioritize code execution approaches over direct tool calls for better efficiency and privacy - Policy: AI protocol standards need more software engineering input during design phases to avoid practical implementation problems - Security: Code execution environments require proper sandboxing and resource limits, but may be more secure than context-passing approaches - Education: Developer communities need resources on evaluating AI tooling protocols before adoption - Funding: Investment in AI infrastructure should prioritize developer experience and practical implementation over theoretical elegance ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical content with accessible explanations) #### 👀 Visual learners - Present: Code examples, diagrams showing context growth patterns - Improve: Add architecture diagrams comparing MCP approaches, token usage visualizations #### 🔊 Aural learners - Present: Video format with commentary and explanations - Improve: Create accompanying podcast episode, provide chapter markers for key concepts #### 🗣️ Verbal learners - Present: Clear definitions of technical terms, analogies comparing approaches - Improve: Add glossary of MCP terminology, create comparison tables #### 🧩 Kinesthetic learners - Present: Code examples that can be copy-pasted and modified - Improve: Provide interactive demos, hands-on labs comparing approaches #### 🧠 Logical learners - Present: Performance metrics, clear cause-and-effect relationships - Improve: Add decision trees for choosing integration approaches, cost-benefit analysis #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion prompts, references to industry examples - Improve: Create discussion forums, peer review opportunities for implementations #### 🧘‍♀️ Solitary learners - Present: Comprehensive technical explanations, self-contained examples - Improve: Add reflection questions, self-assessment checklists #### 🌿 Naturalistic learners - Present: Ecosystem analogies, natural progression of technology adoption - Improve: Connect to broader software evolution patterns, industry lifecycle thinking ### 📊 Accessibility Assessment #### Screen <!-- deep-read:sections end --> ## 📺 Video  --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=1piFEKA9XL0)* **[00:00]** Oh boy, it's time for another MCP video. If you're not familiar with my takes on MCP, it's my favorite example of AI being a bubble. I know way more companies building observability tools for MCP stuff than I know companies actually making useful stuff with MCP. When you see everyone building the tool layer for a new thing and nobody building the product around the new thing, you know that new thing is probably crap. I still remember back in the day when web 3 was blowing up that I knew about six companies doing OOTH for web 3 and one single company that could potentially benefit from that existing. **[00:32]** Yet here we are with MCP and thankfully people are waking up to the fact that it kind of sucks. Not that the spec sucks, which it does, or that the implementations suck, which they do, but the models suck at using it too. I covered this before with code mode from Cloudflare, which was them realizing that MCP is bad and solving it by letting agents write code to call these things instead of just bundling it all in as a giant pile of context that makes everything run like [ __ ] And it seems like our friends over at Enthropic, you know, the people who made this spec and curse us all with it, are waking up to **[01:03]** the same thing because they just wrote a new article, code execution with MCP, building more efficient agents. And depending on how you choose to read this article, you can see it as them admitting that MCP is not a good protocol because MCP requires you to add a bunch of [ __ ] context that makes the models dumber and worse. Models do not get smarter when you give them more tools. They get smarter when you give them a small subset of really good tools. An MCP does not encourage that way of thinking. MCP encourages you to add 500 plus tools to a model and then nothing [ __ ] works anymore. Do you **[01:33]** know what does work really well though? Today's sponsor. Writing code has never been easier, but actually hosting and deploying it's never been more annoying, especially if you're hopping between clouds constantly, and you're on a stack that isn't really well supported on these new fancy, cool, modern tools. Well, there's somebody here to help you out. Savala, these guys get hosting. I could tell you what I think, but I'd rather just quote their own customers. With Savala, you no longer need to worry about uptime or managing infrastructure. It simply works. If I were to start a new project today, I would choose Savala from the very beginning. So, that's got to be really expensive, right? Uh, no. **[02:05]** It's 78% cheaper for them to use Savala than the stack that they were on previously. And it makes sense once you start playing with it. They just made it so easy to spin up and take down servers. Here's a bunch of servers that I have deployed right now on Savala. It's so easy to spin up new things, link them to GitHub, create the pipelines for deployment, and even spinning up databases is super easy. I click here, I click create DB, peg whatever I want to use, and now it's deployed in a data center directly attached to all of my other stuff. When you look at the applications, things get even cooler. Here's my sub nerds production **[02:36]** deployment that's linked to a GitHub repo. I have Cloudflare in front being used for DOS protection as almost everyone should. But if I want to take more advantage of Cloudflare, like using it as a CDN or for caching data on the edge, I hit settings and I turn it on. That is a single click toggle to enable a CDN for your static assets. I've never used any service that made it that easy to do this type of thing. If you're tired of stressing out about your deployments and you want $50 of credit for free, go get it now at soy.link. link/savala. I'm actually really excited to go into this because I secretly deep **[03:07]** down do want something like MCP to work, but the current implementations just don't. I've yet to have one impress me with its capabilities. There are some that are really cool, but none that are actually useful for my experience. Let's see if they succeeded in making them useful here. Code execution with MCP. Building more efficient agents. Direct tool calls consume context for each definition and result. agents scale better by writing code to call tools instead. Here's how it works with MCP. There we go. There it is. Thank you, **[03:39]** Enthropic, for admitting I was right the whole [ __ ] time. It makes no sense to just clog up your system prompt with a bunch of [ __ ] that probably isn't relevant for the majority of work you're doing. There just isn't enough data for the models to be trained to do that well. Do you know what they do well? Because there's a lot of examples. Write code. It's It's so funny to see this line in an official thing on the Anthropic blog. They're admitting that their spec doesn't work for the thing they build, which is AI models. Hilarious. Let's see how they actually **[04:09]** implemented this cuz I am curious. The model context protocol is an open standard for connecting AI agents to external systems and making them dumber in the process. Connecting agents to tools and data traditionally requires a custom integration for each pairing, creating fragmentation and duplicated effort that makes it difficult to scale truly connected systems. You know, if you were trying to solve this problem to make a generic solution for models connecting to things, you'd probably want to make sure it handles the things that you need with those connection layers. You know, like O. Did you know MCP has no concept of O at all? At all. **[04:42]** Now, there's like 18 implementations of it because there's no way to do proper handshakes with MCP. Your best bets to go and hardcode a custom URL that has a signed like parameter in it that allows it to work. Actually, insane. I I I hate the standard. I really do. Ah, MCP provides a universal protocol that does a third of what you need. Developers implement MCP once in their agent and then five additional layers to make it work. And it unlocks an entire ecosystem of integrations. Since launching MCP in November of 2024, adoption has been **[05:13]** rapid by people trying to sell you things, not people trying to make useful things. The community has built thousands of MCP servers. SDKs are available for all major programming languages and the industry has adopted MCP as the de facto standard for connecting agents to tools and data and also implemented a dozen standards for how to make the data safely accessible. Today, developers routinely build agents with access to hundreds or thousands of tools across dozens of MCP servers. However, as the number of connected tools grows, loading all tool definitions up front and passing intermediate results through the context window slows down agents and increases **[05:44]** costs. It also makes them way dumber. Weird how you missed that one. In this blog, we'll explore how code execution can enable agents to interact with MCP servers more efficiently, handling more tools while using fewer tokens. Excessive token consumption from tools make agents less efficient and less effective. As MCB usage scales, there are two common patterns that can increase agent cost and latency. The first is tool definition overloading the context window and the second is intermediate tool results consuming additional tokens. So, first is the tool **[06:16]** definition overload. Most MCP clients load all tool definitions upfront directly into context, exposing them to the model using a direct tool calling syntax. I'd say it's more than most, but this does also include all of anthropics builds. So yeah, these tool definitions might look like the following. Here's a tool definition. G Drive.get document. Description retrieves a document from Google Drive. parameters document ID which is a required string the ID of the document to retrieve as well as fields which is an optional string specific **[06:47]** fields it should return this will return the document object with title body content metadata permissions etc or this Salesforce update record you have an object type and a record ID and data that you're adding and it returns the updated record object with confirmation cool tool descriptions occupy more or one thing I do want to call out here with the G drive document one this requires that you already I have a document ID. Where are you going to get that document ID? Is the user going to pass it? No. You probably have a G drive.find document tool that is an **[07:20]** MCP definition that you use to search for the thing that you want to go find. And then once you find it, you have the ID that you then pass to G Drive.get document. And now you've done multiple back and forth runs for no [ __ ] reason and made everything harder and slower and wasted a bunch of tokens because you have too many tools. Tool descriptions occupy more context window space, increasing response times and costs. In cases where agents are connected to thousands of tools, they'll need to process hundreds of thousands of tokens before reading a request. Yep. **[07:51]** And then the second point, which is that intermediate tool results consume additional tokens. Again, like here we're getting the document then updating Salesforce. I want a funnier example for this. Instead of G drive.get document, how about we do G drive.find document content videos taxes. And this will return an array of documents that might have it. Document one, document two, document three, etc. **[08:24]** So then you do a bunch more tool calls because you want to have this content. It's useful to you. So what you then do is you call G drive.get document for each of these and each of these is an additional message being sent to the model that is a whole separate request and each of these adds to the context. So if this one has a context window of let's say 20 tokens and this is an additional 20 then this request will be 40 because you have to include everything from before. This one will be **[08:55]** 60. You have to include everything from before. This one will be 80 etc. To make this very clear every additional tool call is carrying all of the previous context. So every time a tool is being called the entire history is being re hit as input tokens. Insane. It's so much bloat. It uses so much context. It burns through so many tokens and so much money. And if you don't have caching set up properly for your inputs, you're just burning cash. It sucks. It's such a bad implementation. We need parallel tool calls. We need better tool design to **[09:26]** prevent this. Or you can write code because if this was just writing code to go find the documents and then for each of them go do this thing and then return all of the results with a single tool call, that's a lot less [ __ ] In Enthropic's own words, every intermediate result must pass through the model. In this example, the full call transcript flows through twice. For a 2-hour sales meeting, that could mean processing an additional 50,000 tokens. Even larger documents may exceed context window limits, which would break the flow entirely. With large documents or **[09:56]** complex data structures, models may be more likely to make mistakes when copying data between tool calls. Here's their little diagram for it. So, the MC God, this diagram is kind of [ __ ] So, the MCP client as a context window. We have the system prompt, the tool definitions, the user message. The user message goes to the model. The model responds with the assistant message and a tool call. It then goes and makes that tool call, gets a result, and now you have to send it back to the model to do the new message. But this is the part to look at here. This is how much data is **[10:28]** being sent to the LLM. See, it starts with this data and now it has way more. Every additional tool call is stacking additional data that the LLM has to process, thereby slowing it down, making it dumber, and increasing your costs. The MCP client loads tool definitions into the model's context window and orchestrates a message loop where each tool call and result pass through the model between operations. Yep, you do a whole new message gen, a whole new run of the LM every time a tool call responds. It's great. Code execution with MCP improves context efficiency. **[10:59]** With code execution environments becoming more common for agents, a solution is to present MCP servers as code APIs rather than direct tool calls. Wow. Turns out that writing code is more effective than making a [ __ ] generic wrapping layer that doesn't have half the [ __ ] you need. Who would have thought? The agent can then write code to interact with MCP servers. This approach addresses both challenges. Agents can load only the tools they need and process data in the execution environment before passing results back to the model. There are a number of ways to do this. One approach is to generate **[11:31]** a file tree of all available tools from connected MCP servers. Here's an implementation that uses TypeScript. So here again, we have TypeScript files that have the different things we might want to do and have type definitions for all of these things. And the model can search through these the way it does with any code project to find the specific things that it needs to do the task it wants to do. Each tool call corresponds to a file. Like here we have callm MCP tool from client as the interface for getting document input, the interface for the response and then the function the Google drive to **[12:02]** Salesforce example above becomes this code. So again to show that example because I [ __ ] with it a bunch. The first tool call gets this document that has all of this content in it and then they update a record in Salesforce with the data that they got from this. Instead, it writes the code that imports the G drive client and the Salesforce client, defines the transcript as this thing that it awaited from the G drive.get document call, and then puts it in. This might be hard to read because for whatever reason, okay, I **[12:33]** know the reasons. Anthropic's not very good at front-end code, so they don't have syntax highlighting in their blogs. Amusing. Regardless, you get the idea. This is just TypeScript code. I'd go as far as to say that like MCP as a spec is proof that letting Python people define this entire ecosystem is going to destroy the whole thing because it's so bad. MCP is such a Python spec. It's trying so hard to be simple and elegant that they forgot to put the meat in. TypeScript is a much much less **[13:04]** compromised language in these senses. And that's why when Typescript devs tried adopting this, myself included, we wanted to put our head through the wall, and now that we've taken over and shown them that this would be better as code, they're listening. There's a reason why the examples are using TypeScript and not Python. The agent discovers tools by exploring the file system, listing the /servers directory to find all available servers like Google Drive and Salesforce, then reading the specific tool files that it needs like get document.ts and update record.ts PS to **[13:35]** understand each tool's interface. This lets the agent load only the definitions it needs for the current task. This reduced the token usage from 150,000 tokens to 2,000 tokens. A time and cost savings of 98.7%. How the [ __ ] can you pretend that MCP is the right standard when doing a shitty codegen solution instead saves you 99% of the wasted [ __ ] That is so funny to me. The creators of MCP are sitting here and telling us that writing [ __ ] TypeScript code is 99% more effective **[14:07]** than using their spec as they wrote it. This is so amusing to me. Oh, it turns out that they even linked the Cloudflare thing. I guess that's what woke them up to this realization. Cloudflare published similar findings, referring to code execution of MCP as code mode. The core insights are the same. LMS are adept at writing code and developers should take advantage of this strength to build agents that interact with MCP servers more efficiently. So what are the benefits of code execution with MCP? Code execution with MCP enables agents to use context more efficiently by loading tools on demand, filtering data before it reaches the model and **[14:38]** executing complex logic in single steps. There are also security and state management benefits to this approach. For example, you don't have to dump the entire document into the LLM and then send it over to our friends at Anthropic or Google or AWS, whoever is hosting your model because all of that's just happening inside of the sandbox that the code is executing in. That's so much better than loading the entire document. Remember here where we were grabbing this document and then sending it to the Salesforce thing. That means that the entire content of that Google Drive doc **[15:09]** has to be loaded into context and you have to hope that the model doesn't typo anything as it forwards that over to Salesforce. Or you can just write code. You can just literally in like five lines grab the variable, have it in memory in your sandbox instead of in context in the model that could be hosted anywhere and then update whatever you want to update. Now the content of this document never becomes part of the context. It's never seen by the model because it's not touching any of that because the model doesn't need to know what's in the doc. It needs to know what **[15:40]** to do with it. That's the whole [ __ ] point. There are other benefits too like progressive disclosure. Models are great at navigating file systems. Presenting tools as code on a file system allows for models to read tool definitions on demand rather than reading them all up front because crazy MCP had no concept of progressive discovery. There was no way to give more context via MCP when it was necessary. I saw people doing crazy [ __ ] like having a separate model that would pick which different agent to use and different subsets of tools depending **[16:11]** on what task was being completed for those sub agents. entire orchestration layers of [ __ ] in order to try and make the spec usable. Turns out writing code is easier. Crazy. You could add a search tools tool to the server to find relevant definitions. For example, when working with the hypothetical Salesforce server used above, the agent searches for Salesforce and loads only those tools that it needs for the current task. Including a detail level parameter in the search tools tool that allows the agent to select the level of detail required like name only name and description or the full definition of **[16:42]** schemas also helps the agent conserve context and find tools efficiently. I'm going to pick on my friends at Trey really quick here. I think they might have fixed this since I don't know for sure and don't feel like checking. But when I was playing with it and I noticed the quality of outputs not being great, I decided to analyze what tools their agents have access to. They have a top level agent in solo that determines what's going to happen and it calls separate agents for coding in building. There's a solo coding agent and a solo dev builder agent and these have their own sets of tools and the tools they **[17:14]** have access to are interesting. In here we can see some of them. Do you see how many of these there are going to look for all of these dashes. There are 23 tools available for the solo coding environment agent. This includes seven separate tools for doing file management stuff, three for running commands, and my personal favorite, three for Superbase. I don't use Superbase. I don't even have an account. I've never built anything with Superbase, but when I use Trey, every **[17:44]** single request I send has this context included for things I don't even use. Ah, this is awful. How is this where we ended up and we assumed everything was okay? This is when I complain about AI bros not building software or understanding how the software world works. This is what I'm talking about. All of these things are obviously wrong and dumb. You just have to look at it to realize. And thankfully enough engineers are now using AI tools that they're complaining about these things like a Cloudflare. Like what do you think Cloudflare is better at, LLMs or **[18:15]** software development? If you use their dashboard a lot, you might be confused as to which it is because the dashboard's rough. But if you've used Cloudflare's infrastructure, you know they're good at writing code. You know they're good at infrastructure and engineering. They had to make this a very popular thing and idea. And I had to make videos about those things cuz I have strong opinions to get Anthropic to start acknowledging these facts. Now, let's talk about context efficiency with tools. When working with large data sets, agents can filter and transform results in code before returning them. Like if you fetch a 10,000 row **[18:46]** spreadsheet, so give.get sheet returns 10,000 rows. If those were all in context, good luck. Have fun. or you can process them in code before they get to the model. And pending orders will be any row where the status is pending. And now we have all of these. Cool. Can you tell these guys are really good engineers? I can't remember the last time I saw anyone selecting from an object in JavaScript with array syntax. The Python has rotted their brains at anthropic. Anyways, the agent only has **[19:18]** to see five rows with this example instead of the 10,000 it would before. Similar patterns work for aggregations, joins across multiple data sources or extracting specific fields all without bloating the context window. Like imagine you have data in two places in Google Drive and in Salesforce and you want to find all the people that exist in both. If you ask the model to do that with tools, it'll fetch all of the data from Google Drive. It'll fetch all of the data from Salesforce and then put that all in context and a needle in a hay stack its way into an incorrect answer. Or it could write code that does **[19:50]** that. Match the IDs and return everything that matches. Duh, that's so much better. Let found equals false. While not found, const messages equals await. Slack.get channel history. Found equals messages summ.ext.includes deployment complete. If not found, await new promise set timeout R5000. Very good code. That doesn't scare me at all. This approach is more efficient than alternating between MCP tool calls and sleep commands throughout the agent **[20:21]** loop. Additionally, being able to write out a conditional tree that gets executed also saves on time to first token latency. Rather than having to wait for a model to evaluate an if statement, the agent can let the code execution environment do this. Oh yeah, crazy. As slow as JavaScript is, it's actually faster than letting an LLM go through a 100,000 tokens and hopefully guess the right answer. and also crazy. I know that this doesn't mean anything to anyone. Code is deterministic. So when it writes the code, it's not going to 50% of the time hallucinate. It's **[20:51]** just going to write the code and the code will just do the thing. The more tokens you generate, the more tokens you have in context, the more hallucinations you're going to be dealing with. As weird as JavaScript is, and as much hallucination has had to occur for it to be designed in the first place, is a relatively consistent language when it comes to executing things. As long as you're not doing weird string manip stuff. Yeah. And then we have the privacy side. I touched on this a little earlier. When agents use code execution with MCP, intermediate results stay in the execution environment by default. This way, the agent only sees what you explicitly log or return. Meaning data **[21:24]** you don't wish to share with the model can flow through your workflows without ever entering the model's context. For even more sensitive workloads, the agent harness can tokenize sensitive data automatically. For example, imagine you need to import customer contact data from a spreadsheet into Salesforce. The agent writes code like this where we have the Salesforce update record call for all of these. This is very good code that totally isn't blocking and going to be really slow. The quality of the TypeScript in this article is almost as funny as the fact that it's not syntax highlighted. **[21:56]** You know what? Uh quiz for the watcher. Why is this code slower than it needs to be? I'm not going to answer. You should know by now. The MCP client intercepts the data and tokenizes PII before it reaches the model. So here when the data is returned, we will offcate all of the data. We'll just change it to like email one, phone one, name one, email two, phone two, name two. That way we could still identify them and pass things between the two, but none of the data ever has to make it to the company that's hosting the model. Duh. **[22:27]** So much better. When you think about it, if you're using a tool like in Trey here, the get tables tool, that one's not giving you PII because it's data about what tables exist in their definitions. But if there was a get rows tool here that you just gave the model access to all of the data in your database and anything in there could hypothetically be included in context and therefore sent to Anthropic or OpenAI or whoever else you're hosting from. This is the easiest way to not have to do that. When the data is shared **[22:58]** in another MCP tool call, it can be untokenized via a lookup in the MCP client. The real email addresses, phone numbers, and names flow from Google Sheets to Salesforce, but never through the model. That will prevent the agent from accidentally logging or processing sensitive data. You can use this to define deterministic security rules, choosing where data can flow to and from. Great. Also, state persistence. This is another one of those really annoying things with MCP state. LMS have no state. Databases are just state. **[23:29]** Balancing out the gap there requires a lot of [ __ ] With code, the state stays within the code. As long as it's in memory, it hasn't changed. And if you want to stay there for the future, you can write a file and now it's there and you don't have to worry about it being in context. So here we write this CSV data from leads that we got from Salesforce. We write this to a file and now later on we can grab that. Great. Agents can also persist their own code as reusable functions. Once an agent develops working code for a task, it can save the implementation for future use. **[24:01]** So if we want to be able to save a sheet as a CSV, we can write this function, store it, and now have it as a skill we can call whenever. This ties in closely to the concept of skills, folders of reusable instructions, scripts, and resources for models to improve performance on specialized tasks. Adding a skill.mmd file to these save functions creates a structured skill that models can reference and use over time. And this allows your agent to build a toolbox of higher level capabilities evolving the scaffolding that it needs to work most effectively. Is this not reinventing MCP again? Let me get this **[24:31]** straight. So let's say we have this API. We could tell the model about this API, but then we have to do that for every single thing. So we want to standardize this. We need a standard. So we create an MCP tool that includes all of the definitions and all of the other things that are needed to call this endpoint. But then we realize, oh no, we have too many tools. So we do the very obvious thing of changing this into an SDK interface sales course. This **[25:05]** is what we're talking about here, the code stuff. And then now that we've done this, this code is useful. We should save it. And now we have this skill get Salesforce user data. [snorts] And then these should be documented. And we get our skill.md file. How to use **[25:35]** get salesforce user data. And then we end up roughly where we started. And I'm sure this loop won't continue indefinitely as we reinvent the same 15 things over and over and over again in the AI world. That's definitely not going to happen. This is the real agentic loop everybody's talking about. I'm going to go insane. Yeah, I was actually liking this until this point. Note that code execution introduces own complexity. Running agent generated code requires a secure environment for **[26:06]** execution with appropriate sandboxing, resource limits, and monitoring. I don't know if Daytona is a sponsor for this video or not. We determine that later, but Daytona is the only sane way to do this that I know of. These guys have made deploying these things so much easier. You want a cheap way to safely run AI generated code, just use Daytona. They're not even paying me to say this. They might have paid me earlier. They're not for this. I like these guys. They're awesome to work with. They're genuinely really fun and get this side really well. I'd go as far as considering this a solved problem. At least it's a hell of a lot more solved than MCP is. These **[26:36]** infrastructure requirements add operational overhead and security considerations that direct tool calls avoid because direct tool calls at MCP don't have security because there's no off. The benefits of code execution are reduced token cost, lower latency, and improved tool composition. Should be weighed against those implementation costs. No, this is [ __ ] [ __ ] This is absolute [ __ ] [ __ ] Every implementation of MCP have seen that can do anything is way more insecure than a basic [ __ ] sandbox with some environment variables. This is delusion. God, I this article was really good **[27:07]** until this line. From here down, it fell apart. MCP provides a foundational protocol. MCP provides a foundational protocol for agents to connect to many tools and systems. However, once too many servers are connected, tool definitions and results can consume excessive tokens, reducing agent efficiency. Although many of these problems here feel novel, context management, tool composition, and state persistence, they have known solutions from software engineering. Codexian applies these established patterns to agents, letting them use familiar **[27:37]** programming constructs to interact with MCP servers more efficiently. If you implement this approach, we encourage you to share your findings with the MCP community. We need more engineers in high places. This is what happens when we let these LLM people make the things that we have to use as devs. Devs should be defining what devs use. And if you don't let them do that, then you'll end up realizing they were right all along. Whenever somebody tells you AI is going to replace developers, just like them this is all the proof I **[28:08]** need that we are good. This is what happens when you let LLMs and more importantly you let LLM people designer APIs we get something so useless that we reinvent the whole wheel multiple times in the process [groaning] and I'm going to continue to not really use MCP. I hope this helps you understand why. Let me know what you guys think. Let me know how you're executing your MCP tools. And until next time, peace nerds.