Token cost of a Drive-to-Salesforce workflow, naive tool loading vs. code execution

36:I[80230,["/_next/static/chunks/40i_du3519sxo.js"],"IconMark"] 30:T28d2, The louder the AI hype gets, the more common the assumption becomes: STEM is essential, humanities are optional. That framing has it backwards. AI systems now write, argue, and code well enough to look like they understand what they are doing. They don't. Filling that gap, deciding what a system's output means, whether it is true, and whether it should be acted on, is the work the humanities have always done. This post walks through four places where humanities skills are load-bearing in AI work, why the "neutral tool" framing keeps breaking, and what that means for how teams should staff and think. > **Key Takeaways** > - LLMs are next-token predictors. They optimize surface form over meaning. The seminal critique, "On the Dangers of Stochastic Parrots" ([Bender, Gebru, McMillan-Major, Shmitchell, FAccT 2021](https://dl.acm.org/doi/10.1145/3442188.3445922)), makes the syntactic-vs-semantic gap explicit and it has not been closed by scale. > - Models inherit the bias of their training data. NIST's AI Risk Management Framework treats bias as a first-class risk category, not an edge case ([NIST AI RMF 1.0, January 2023](https://www.nist.gov/itl/ai-risk-management-framework)). > - Interpretation cannot be automated away. Hallucination rates for the strongest commercial models are still measured in the low single digits on curated benchmarks like [Vectara's HHEM leaderboard](https://github.com/vectara/hallucination-leaderboard), which means a human has to close the loop. > - Prompt engineering is applied rhetoric. Anthropic's own prompting guide is a document about audience, framing, and structure ([Anthropic prompt engineering docs](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview)), the exact vocabulary humanities departments teach. {/* [UNIQUE INSIGHT] The humanities-vs-STEM framing collapses once you notice that every failure mode of a production LLM (hallucination, bias, misuse, misinterpretation) maps onto a humanities discipline. */} --- ## Syntactic fluency is not semantic understanding Large language models are trained to predict the next token. That is not a paraphrase. It is the objective function. Everything else, including apparent reasoning, is emergent behavior on top of that base task. The clearest early statement of what this means was Bender, Gebru, McMillan-Major, and Shmitchell's 2021 paper "On the Dangers of Stochastic Parrots" ([FAccT 2021](https://dl.acm.org/doi/10.1145/3442188.3445922)). Their argument, briefly: - A language model has access to form (sequences of characters and tokens) but not to communicative intent, referent, or grounded experience. - Fluency in form is easy to mistake for understanding of content. - The mistake is not a UX glitch. It is a category error. Five years and several model generations later, the argument still holds. GPT-5 and Claude 4 write more convincingly than GPT-3 did, but the underlying substrate is the same: statistical patterns over text, not lived reference to a world. This is where humanities training earns its keep. Literary study, philosophy of language, and translation studies all revolve around the gap between what a text says and what it means. That gap does not disappear when the author is a model. It gets larger, because the model has no intent to recover. If the only people in the room are trained to ask "does this compile?" and "does it pass the eval?", the room is missing the person who asks "does this mean what we think it means?" --- ## The myth of the neutral model The second failure mode is the one AI companies have spent the most public words on: bias. Every production LLM inherits the statistical shape of its training corpus. That corpus is human writing, which is not evenly distributed across languages, cultures, professions, or points of view. NIST's AI Risk Management Framework, published in [January 2023](https://www.nist.gov/itl/ai-risk-management-framework), lists bias alongside safety, security, and privacy as core categories of AI risk, not as a footnote. Concrete evidence keeps arriving: - OpenAI's own GPT-4 System Card documents disparate performance and refusal patterns across demographic groups ([OpenAI, GPT-4 System Card, March 2023](https://cdn.openai.com/papers/gpt-4-system-card.pdf)). - The Stanford Center for Research on Foundation Models runs the HELM benchmark suite, which measures fairness and bias as first-class metrics alongside accuracy ([HELM, Stanford CRFM](https://crfm.stanford.edu/helm/)). - Anthropic's Constitutional AI work is explicitly an attempt to make normative choices about model behavior legible instead of hidden ([Anthropic, Constitutional AI, December 2022](https://www.anthropic.com/research/constitutional-ai-harmlessness-from-ai-feedback)). Naming a bias, tracing who it hurts, and deciding what a "fair" answer would even look like are not engineering problems in the narrow sense. They are questions of ethics, sociology, and political philosophy. Teams that treat "align the model" as a purely technical task keep discovering, expensively, that the hard part is the value definition, not the RLHF loop. --- ## Interpretation cannot be automated Every AI system that generates language pushes a decision back to the reader: is this true, is this useful, is this the right frame? Two data points on scale: - On Vectara's continuously updated [HHEM hallucination leaderboard](https://github.com/vectara/hallucination-leaderboard), the top-scoring commercial models still hallucinate on summarization tasks at rates measured in the low single digits. That number is small only until you multiply it by the volume of AI output your organization ships. - Stanford HAI's [2024 AI Index Report](https://aiindex.stanford.edu/report/) found that responsible-AI evaluation benchmarks are inconsistent across labs, meaning even the "how bad is this" question is under-standardized. The intellectual tradition that has spent the longest time on the problem of interpreting ambiguous, possibly misleading, possibly context-dependent text is **hermeneutics**, the branch of philosophy that studies interpretation itself. Its central move (assume the text does not carry its meaning on its face; reconstruct meaning through context, purpose, and audience) is the exact skill needed to work with LLM output without getting burned by confident-sounding nonsense. You do not need to have read Gadamer to do this well. You do need to have internalized the habit that a fluent paragraph is a hypothesis, not a fact. --- ## Prompt engineering is rhetoric with a new medium "Prompt engineering" sounds like a new discipline. Read Anthropic's official [prompt engineering guide](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview) or OpenAI's [prompting guide](https://platform.openai.com/docs/guides/prompt-engineering) and the actual advice is old: - Be clear about your audience. - State the task and its constraints explicitly. - Provide examples that anchor the desired form. - Structure your input so the reader (the model) can follow it. - Anticipate misreadings and pre-empt them. Every one of those bullets is standard advice in a first-year composition course, and every one is core to classical rhetoric. Aristotle's *Rhetoric* is a book about how to shape a message for a specific audience to produce a specific response. That is what a good system prompt does. The reason this matters practically: teams that have people trained in writing, editing, and discourse analysis produce measurably better prompts, evals, and product copy than teams that treat prompts as configuration files. The skill transfers directly. What does not transfer is the assumption that "just describe the problem to the model" is a technical rather than a rhetorical act. --- ## What this changes for how teams are built Two concrete implications for people making hiring, curriculum, or team-composition decisions: 1. **Do not staff AI teams exclusively from STEM.** The humanities graduate on the team is not a diversity hire, they are the person who catches the bias, notices the interpretive slippage, and writes the prompt that actually works. Anthropic, OpenAI, and Google DeepMind all now hire policy, ethics, and communications staff at senior levels, and it is not for optics. 2. **Do not treat writing as a soft skill.** For anyone building with LLMs, the ability to write clear, structured, unambiguous prose is now an execution skill on par with knowing the API surface. It shows up in prompts, in evals, in incident reports, and in every user-facing string the model helps you produce. The framing that the humanities are being made obsolete by AI has the direction of the arrow wrong. AI is a language technology. Everything a language technology touches (meaning, interpretation, persuasion, value, harm) sits in territory the humanities have been mapping for two thousand years. The tools got faster. The map did not. --- ## Frequently Asked Questions ### Isn't this just a rebrand of "AI needs guardrails"? Guardrails are a subset. Guardrails ask "how do we stop the model from doing bad things?" The humanities frame is broader: how do we know what "bad" means here, who decides, whose language the model speaks, and what interpretive work the reader still owes. Guardrails are policy. This is the epistemology behind the policy. ### Do I need a philosophy degree to work on AI? No. You need the habits: read carefully, interrogate framing, notice whose voice is missing, treat fluent text as a claim not a fact. A degree is one way to build those habits. Reading widely and working with people who have those habits is another. ### Where does this leave prompt engineering as a career? Exactly where technical writing was in the 1990s: a real skill, undervalued for a while, then absorbed into the standard toolkit of anyone building software. The people doing it well now are already writers, editors, and communicators. That is not a coincidence. ### What should an engineering leader actually do differently? Three small changes with outsized returns: put a writer or editor in the loop for any prompt or system message that ships to users; run adversarial reads of AI output with someone whose training is in interpretation, not just testing; and treat "what does this model actually mean by X" as a legitimate design question, not a pedantic one. 31:T711f, The easiest way to build an MCP server is also one of the easiest ways to build a bad one. Take your existing API, find all the endpoints, turn each endpoint into an MCP tool, and expose them to the model. Done. If you have 100 API endpoints, you now have 100 tools. It feels like the right abstraction because your API already represents everything your system can do. But there is a problem: **An API is designed for applications. An MCP server is designed for agents.** Those are not necessarily the same interface. Since Anthropic open-sourced the Model Context Protocol on November 25, 2024 ([Anthropic, "Introducing the Model Context Protocol"](https://www.anthropic.com/news/model-context-protocol)), the standard has spread fast. OpenAI adopted it across its Agents SDK and ChatGPT desktop in March 2025, Google DeepMind committed Gemini support in April 2025 ([Demis Hassabis on X, April 9, 2025](https://x.com/demishassabis/status/1910107859041271977)), and Microsoft Copilot Studio shipped MCP support to general availability in May 2025 ([Microsoft Copilot Studio blog](https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/model-context-protocol-mcp-is-now-generally-available-in-microsoft-copilot-studio/)). Public directories now list tens of thousands of MCP servers ([PulseMCP directory](https://www.pulsemcp.com/servers)). As agents get better at discovering tools, inspecting schemas, writing code, and composing operations, the role of the MCP server is changing. The question is no longer: > "How do I expose my API through MCP?" It's becoming: > **"What is the best interface for an agent to accomplish real work in my system?"** That shift has consequences. > **Key Takeaways** > - Anthropic-published research shows a naive tool-loading pattern used ~150,000 tokens for a Drive-to-Salesforce workflow; presenting the same MCP servers as code APIs cut that to ~2,000 tokens ([Anthropic Engineering, Nov 2025](https://www.anthropic.com/engineering/code-execution-with-mcp)). > - Real MCP clients enforce hard tool-count limits. Cursor recommends staying under ~40 active MCP tools ([Cursor forum](https://forum.cursor.com/t/tools-limited-to-40-total/67976)), which forces server designers to think about which tools to expose, not just whether they can. > - The official MCP guidance already recommends atomic, single-purpose tools plus **prompts** as workflow primitives, not a 1:1 endpoint dump ([modelcontextprotocol.io tools spec](https://modelcontextprotocol.io/specification/2026-07-28/server/tools); [MCP blog on prompts, July 2025](https://blog.modelcontextprotocol.io/posts/2025-07-29-prompts-for-automation/)). > - The two-layer pattern (primitives + workflow tools) with client-side progressive discovery is emerging as the shape MCP servers are converging on. {/* [UNIQUE INSIGHT]: The two-layer server model (primitives + workflow tools) is the natural convergence of Anthropic's code-execution guidance, real client tool caps, and how agents actually reason about capability selection. */} --- ## The first generation: API endpoint → MCP tool The most natural way to build an MCP server is to map your API directly to tools. Imagine a database platform with an API like this: ```text POST /branches POST /branches/{id}/compute GET /branches/{id}/connection-string DELETE /branches/{id} GET /databases POST /databases DELETE /databases/{id} ``` A straightforward MCP implementation might expose: ```text create_branch attach_compute get_connection_string delete_branch list_databases create_database delete_database ``` Architecturally, it looks like this: ```text REST / GraphQL API │ ▼ MCP Server │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ Tool A Tool B Tool C │ │ │ └─────────────┼─────────────┘ ▼ Agent ``` There is nothing inherently wrong with this. In fact, it has several advantages: - It's easy to implement. - It provides broad API coverage. - Developers don't need to invent new abstractions. - Agents get access to the underlying capabilities. - New API endpoints can be exposed quickly. The problem appears when the number of tools grows. --- ## When API completeness becomes agent complexity Suppose your application has 200 API endpoints. You expose all 200 as MCP tools. Now imagine an agent receiving those tools. The agent isn't just being given capabilities. It's being given a **decision space**. For every task, it needs to determine: ```text Which tool should I use? What arguments does it require? Which other tools are related? Do I need to call another tool first? What order should these operations happen in? Is there a higher-level operation that accomplishes the same thing? ``` The problem isn't simply that 200 tools consume tokens. The deeper problem is that **tool selection itself becomes part of the reasoning problem**. This isn't theoretical. Cursor, one of the most-used MCP clients, tells developers directly: "Cursor currently performs best when the number of active MCP tools is kept around 40" ([Cursor forum](https://forum.cursor.com/t/tools-limited-to-40-total/67976)). Tools past that cap are silently dropped from the model's view. If your server exposes 200 endpoints as 200 tools, most of them may not even reach the agent. Consider a user request: > "Create a staging database that I can connect to." A model might have to reason through: ```text create_database ↓ create_branch ↓ attach_compute ↓ get_connection_string ``` But from the user's perspective, this is one operation. They don't care about the internal sequence. They want: ```text create_staging_database() ``` This distinction is important. **The API models implementation capabilities. The agent needs task-oriented capabilities.** --- ## The context-bloat problem The traditional approach assumes the model should know about all available tools before deciding what to do. Conceptually: ```text MCP Server │ ┌────────────────┼────────────────┐ │ │ │ ▼ ▼ ▼ 50 tools 50 tools 50 tools │ │ │ └────────────────┼────────────────┘ ▼ Agent │ "Which one?" ``` As the number of tools increases, so does the amount of information the model has to reason over. This is what's often described as **context bloat**, and Anthropic's own engineering team has now quantified it. In their November 2025 post on code execution with MCP, they walked through a common cross-server workflow: pull a meeting transcript from Google Drive, then add it as a note in Salesforce. The naive pattern (load every tool definition into context, then shuttle intermediate results back through the model) consumed roughly **150,000 tokens**. Presenting the same MCP servers as code APIs in a sandboxed runtime, so the model could inspect only what it needed and pass data directly, cut that to about **2,000 tokens**, a ~98.7% reduction ([Anthropic Engineering, "Code execution with MCP", November 2025](https://www.anthropic.com/engineering/code-execution-with-mcp)).

Token cost of a cross-server MCP workflow, naive vs. code-execution pattern. Data: Anthropic Engineering, Nov 2025.

That's the mechanical cost. There's also a feedback loop in the reasoning cost: ```text More tools ↓ More schemas/descriptions ↓ More context ↓ More possible choices ↓ Harder tool selection ↓ More opportunities for incorrect calls ``` The obvious solution might be: > "Then let's just expose fewer tools." But that isn't necessarily the right answer either. You don't want to throw away useful capabilities just because the agent shouldn't see all of them at once. This is where MCP architecture starts moving toward a different model. ![Layered software architecture illustration with virtual interfaces suggesting workflow composition over raw APIs.](https://cdn.pixabay.com/photo/2018/09/16/22/08/software-3682509_1280.jpg) *Photo by xresch on Pixabay.* --- ## Discovery moves toward the client Modern agent clients are getting better at discovering and composing tools themselves. Instead of loading everything into the agent's context up front, an agent can progressively discover what it needs. The flow becomes something like: ```text User request │ ▼ Agent │ ▼ Search capabilities │ ▼ Inspect relevant tool │ ▼ Execute │ ▼ Observe result │ ▼ Continue if necessary ``` This is fundamentally different from: ```text Load every tool ↓ Put everything in context ↓ Ask model to choose ``` With progressive discovery, the agent might initially know only enough to search. For example: ```text search_tools("database staging") ``` The result might reveal: ```text create_database create_branch create_with_compute ``` The agent can then inspect the relevant schemas before execution. This changes an important architectural responsibility. The MCP server doesn't have to solve the entire discovery and orchestration problem. **The server defines capabilities. The client increasingly determines how those capabilities are discovered and composed.** --- ## What about code mode? The shift becomes even more interesting when agents can use code to compose operations. Instead of forcing every possible sequence of operations into a separate MCP tool, an agent can: 1. Discover available capabilities. 2. Inspect their interfaces. 3. Write a small program. 4. Execute that program in a controlled environment. 5. Combine the results. Conceptually: ```text MCP Server │ Available capabilities │ ▼ Agent │ writes code │ ▼ Sandbox │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ Tool A Tool B Tool C │ │ │ └─────────────┼─────────────┘ ▼ Result ``` This is exactly the pattern Anthropic recommends in its advanced tool use guidance: let the model call tools inside code rather than through a fresh schema list on every turn ([Anthropic Engineering, "Advanced tool use"](https://www.anthropic.com/engineering/advanced-tool-use)). The 150k-to-2k token result above is what happens when you push all the way in that direction. This makes the idea of exposing every possible workflow as a dedicated tool less compelling. If an agent can safely compose primitives itself, why create hundreds of composite tools? But there is an important counterargument. **Agents being capable of composition doesn't mean they should always have to compose everything themselves.** --- ## Workflow-level tools aren't dead Consider a workflow such as: ```text create branch ↓ attach compute ↓ wait for compute ↓ retrieve connection string ``` An agent *could* perform all of these operations individually. But if this sequence represents a common, well-defined user intent, a workflow-level tool may be significantly better. For example: ```typescript createWithCompute({ branch: "staging", computeSize: "small" }) ``` Internally: ```typescript async function createWithCompute(input) { const branch = await createBranch(input.branch); await attachCompute({ branchId: branch.id, size: input.computeSize }); const connectionString = await getConnectionString(branch.id); return { branchId: branch.id, connectionString }; } ``` From the agent's perspective, the entire operation becomes one meaningful action. ```text createWithCompute() │ ┌────────────┼────────────┐ ▼ ▼ ▼ create branch attach compute get URL ``` This is valuable because it reduces: - number of model decisions - number of tool calls - latency - intermediate state - opportunities for errors - unnecessary context The key idea isn't that workflow tools replace primitive tools. It's that **both can coexist**. The official MCP guidance from July 2025 introduced **prompts** as a separate primitive precisely for this, "a primitive for building workflow automation" that composes underlying tools ([MCP blog, "Prompts for automation"](https://blog.modelcontextprotocol.io/posts/2025-07-29-prompts-for-automation/)). The protocol itself is telling server authors that atomic tools and workflow-level primitives are different things and both belong. --- ## The two-layer MCP server {/* [UNIQUE INSIGHT] */} A useful mental model is to design an MCP server with two layers. ```text MCP Server │ ┌─────────────┴─────────────┐ │ │ ▼ ▼ Primitive capabilities Workflow capabilities │ │ │ │ create_branch create_environment attach_compute deploy_application delete_branch clone_environment get_connection_string rollback_deployment │ │ └─────────────┬─────────────┘ ▼ MCP Client │ ▼ Agent ```

MCP moved from single-vendor release to cross-vendor standard in under a year.

### Primitive capabilities These are close to the underlying system. For example: ```typescript createBranch() deleteBranch() attachCompute() detachCompute() getConnectionString() ``` They provide: - flexibility - composability - API coverage - support for unusual workflows ### Workflow capabilities These represent meaningful operations. For example: ```typescript createPreviewEnvironment() cloneProductionEnvironment() deployApplication() rollbackDeployment() ``` They provide: - fewer tool calls - clearer intent - lower latency - simpler agent reasoning - more predictable execution The MCP server becomes more than an API wrapper. It becomes an **agent-facing interface to your system**. --- ## Don't confuse API completeness with agent usability This is probably the most important design principle. An API might have: ```text POST /branches POST /branches/{id}/compute GET /branches/{id}/connection-string ``` because those are sensible resources and operations for a traditional software client. That doesn't mean an agent needs three separate tools. A better agent-facing interface might expose: ```text create_database_environment ``` while still making lower-level operations available for advanced cases. The goal isn't to minimize the number of tools. The goal is to minimize the **complexity the agent has to manage to accomplish a task**. That distinction changes how we evaluate MCP server design. --- ## A practical framework for designing MCP tools {/* [UNIQUE INSIGHT]: Five-question framework for deciding whether an API operation should become an MCP tool. */} When deciding whether an API operation should become an MCP tool, I ask five questions. ### 1. Is this capability useful to an agent? Don't automatically expose every endpoint. An endpoint that exists because of internal application architecture may not be meaningful as an agent capability. ### 2. Can an agent discover it? Tool names and descriptions become part of the interface. Compare: ```text executeOperationV2() ``` with: ```text create_database_branch() ``` The second communicates intent. For agents, good naming isn't cosmetic. The official MCP tool specification puts this in writing: tools should be "focused and atomic, one tool doing one thing well," with descriptions verbose enough for the model to select correctly ([modelcontextprotocol.io tools spec](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)). It's part of the API contract. ### 3. Is this operation atomic? If a capability represents a useful standalone operation, exposing it as a primitive tool makes sense. For example: ```text delete_branch ``` is naturally atomic. ### 4. Is there a common workflow around it? If agents repeatedly need to perform: ```text A → B → C → D ``` consider exposing: ```text workflow_X() ``` instead. But don't create a workflow tool for every imaginable sequence. Only promote **meaningful, repeated workflows** into first-class capabilities. ### 5. Can the client safely compose it? If an operation is naturally composable and agents can discover it easily, primitives may be enough. If composition introduces unnecessary latency, complexity, or failure modes, a workflow tool may be better. The decision can be summarized as: ```text Is it useful alone? │ ┌────┴────┐ No Yes │ │ ▼ ▼ Don't expose Is it part of a common workflow? │ ┌────┴────┐ No Yes │ │ ▼ ▼ Primitive Consider tool workflow ``` --- ## The MCP server as an agent interface This leads to a broader way of thinking about MCP. We often draw the architecture like this: ```text Application │ ▼ API │ ▼ MCP Server │ ▼ Agent ``` But a better mental model is: ```text Your System │ ┌───────┴───────┐ │ │ API capabilities Workflows │ │ └───────┬───────┘ ▼ MCP Server │ Agent-facing API │ ▼ MCP Client │ ▼ Agent ``` The MCP layer becomes an opportunity to **reshape your application's capabilities around how an agent actually works**. That's a subtle but important architectural shift. --- ## What I think the future looks like I don't think the future is: > "Every MCP server should expose five tools." Nor do I think it's: > "Expose every API endpoint and let the model figure it out." The more interesting architecture sits somewhere in between. MCP servers can expose a combination of: ```text Agent Interface │ ┌────────────┴────────────┐ ▼ ▼ Discoverable primitives High-value workflows │ │ ▼ ▼ Flexible composition Fast execution │ │ └────────────┬────────────┘ ▼ Agent ``` Meanwhile, increasingly capable MCP clients take responsibility for: - progressive discovery - tool inspection - composition - execution strategies - code-based orchestration This means MCP server developers don't need to build increasingly complicated orchestration layers into the server itself. Instead, they should focus on something more fundamental: **Expose the right capabilities with the right semantics.** --- ## The real abstraction isn't the API endpoint This is where MCP server design becomes interesting. When APIs were primarily consumed by applications, we optimized interfaces around resources: ```text /users /projects /deployments /databases ``` When APIs are consumed by agents, we can start thinking in terms of **intent and outcomes**: ```text create_customer deploy_application create_preview_environment rollback_deployment generate_report ``` The latter aren't necessarily direct API endpoints. They're **capabilities expressed in the language of work**. And that's what makes an MCP server interesting. It gives us an opportunity to build an interface specifically for AI consumers rather than wrapping the interface we already had. --- ## Frequently Asked Questions ### Do I have to redesign my whole API to build a good MCP server? No. The two-layer pattern in this post assumes you keep your existing API. The MCP server sits above it and exposes a curated set of primitives plus a smaller set of workflow-level tools that internally call those primitives. Your API stays as it is. ### How many MCP tools is too many? There's no universal number, but real client caps are the first place to look. Cursor performs best with roughly 40 or fewer active MCP tools and silently drops the rest ([Cursor forum](https://forum.cursor.com/t/tools-limited-to-40-total/67976)). Other clients have their own limits. Design for the lower end of the range your users care about, not for the theoretical maximum. ### What's the difference between an MCP tool and an MCP prompt? Tools are atomic capabilities the model calls with structured arguments. Prompts, introduced as a first-class MCP primitive in July 2025, are workflow templates the server exposes for repeatable multi-step operations ([MCP blog on prompts](https://blog.modelcontextprotocol.io/posts/2025-07-29-prompts-for-automation/)). Prompts are one of the ways the protocol formalizes the primitive-vs-workflow split. ### What is "code mode" and when should I use it? Code mode is a pattern where the agent writes and executes code in a sandbox that calls MCP tools directly, rather than having the model select tools through a schema list on every turn. Anthropic's data on a Google Drive-to-Salesforce workflow showed a drop from ~150,000 tokens to ~2,000 tokens using this pattern ([Anthropic Engineering, Nov 2025](https://www.anthropic.com/engineering/code-execution-with-mcp)). Use it when workflows span many tool calls or shuttle large intermediate results between them. ### Should I still expose primitive tools if I have workflow tools? Usually yes. Workflow tools optimize for common intents; primitives cover the long tail of unusual workflows the agent may still need to compose. The two-layer server exists precisely so you don't have to choose.