# Expanding context engineering to the tooling layer Frank Wittkampf, Databook | Agents in Production 2025 | 26:18 Source: https://www.youtube.com/watch?v=55YwbrTrruU Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks. Page: https://mlopstalks.com/talks/expanding-context-engineering-to-the-tooling-layer Published: 2026-01-16 Tags: context-engineering, mcp, structured-outputs, tool-use ## TL;DR - MCP makes it easier to connect agents to services, but exposing a service's full API can pollute context and reduce reliability. - Tool masks give each agent a smaller, context-specific interface over the same underlying tool, with selected inputs, outputs, defaults, and validation. - Enterprise agents need versioned tool surfaces and controlled variability because small changes in a multi-step process can break automation at scale. ## Summary Frank Wittkampf argues that prompt engineering must include the tools an agent can see and the way those tools are described. MCP standardizes connections to services, but it can expose large input and output schemas that add tokens, choices, latency, and opportunities for mistakes. His approach places a configurable mask between the agent and the raw tool handler. A mask can reduce a broad API to a focused operation, fix default values, select the output fields, add system-provided arguments, and return errors that help the agent correct its call. Different agents can use different masks over the same API. Frank also discusses capability gates, authorization-specific tool surfaces, and versioning. He is direct about the trade-off between exploratory work and enterprise automation. Exploratory agents may need flexibility, while production processes need a stable, controlled interface that behaves consistently across many executions. ## Key ideas ### MCP connects services, but the full tool surface can damage agent reliability [01:21](https://www.youtube.com/watch?v=55YwbrTrruU&t=81s) Frank supports MCP because it makes it easier to connect agents to many services and standardize those connections. The problem is that a connected service can expose its whole API to the language model. That may include fields, descriptions, and options the agent does not need. The extra material pollutes execution context, adds tokens, and gives the model more ways to choose incorrectly. Frank calls this added decision space "choice entropy." He says the effect becomes more serious when a production agent has many tools and must run at volume while maintaining quality, speed, and cost. ### A tool mask gives the agent a smaller interface over the raw handler [07:23](https://www.youtube.com/watch?v=55YwbrTrruU&t=443s) Frank places a mask between the agent and the underlying tool handler. The handler keeps the raw service surface, including its full input and output objects. The mask defines the interface that the agent sees and translates that interface into the handler's requirements. This makes the tool itself part of context engineering. An agent builder can edit the mask alongside the agent prompt. The same API can have several masks for different agents or contexts, while the underlying API remains unchanged. Frank says this lets teams shape the tool around the agent's actual task instead of exposing every capability. ### A narrow Yahoo Finance tool can return only the fields an agent needs [11:23](https://www.youtube.com/watch?v=55YwbrTrruU&t=683s) Frank uses Yahoo Finance as a concrete example. Instead of exposing a stock API with many possible fields and input variations, a mask can create a focused tool named "stock price." The agent supplies only a symbol. The output always contains the symbol, market price, and currency in a fixed structure. Other masks could return revenue, a short stock history, or a margin profile. Fixed outputs make it easier to place results in a prompt or process them as a predictable object. Defaults can also provide values the agent would otherwise have to choose, which removes unnecessary decisions from the call. ### Validation errors can teach an agent to correct a tool call [12:45](https://www.youtube.com/watch?v=55YwbrTrruU&t=765s) Frank describes adding validation templates to the masked tool. If an input such as a stock symbol has the wrong format, the mask can return a custom error before calling the underlying API. The message can explain what needs to change, allowing the agent to correct the input and call the tool again. This avoids relying on generic 404 or 500 responses and gives the team more control over self-correction. He treats error wording as part of prompt engineering because the error response becomes part of the agent's working context and can influence whether the process recovers. ### Tool names and descriptions must fit the rest of the agent context [14:31](https://www.youtube.com/watch?v=55YwbrTrruU&t=871s) Frank says tools are prompts because their names, descriptions, inputs, outputs, and errors all add language and choices to the model's context. In one example, the word "notes" had several meanings across tools: agent memory, footnotes, and another tool's concept. Those meanings became a source of conflict when the tools appeared together. A mask allowed the team to change the wording for one agent without redeploying the entire tool infrastructure. He also refers to Anthropic's advice to put instructions about using a tool in the tool description, while allowing those descriptions to vary when different agent contexts require different sequencing or behavior. ### Schema reduction and capability gates limit the ways an agent can misfire [19:06](https://www.youtube.com/watch?v=55YwbrTrruU&t=1146s) Frank gives several design patterns for masks. Teams can shrink schemas by limiting parameters, types, arrays, and enums to what the task needs. They can use different masks for exploratory agents and agents that must follow a more constrained path. Capability gates can split a broad API into single-purpose tools that become available at particular stages. For example, a tool requiring user authorization can be separated from a similar public operation. The two masks can expose different arguments or hard-code authorization-related values, which prevents an agent from accidentally reaching an operation before it is allowed. ### System-provided values remove context the language model does not need to supply [21:26](https://www.youtube.com/watch?v=55YwbrTrruU&t=1286s) A production agent already has session information around it, such as the tenant, region, user, and information gathered earlier in the process. Frank recommends passing those values from the system into the underlying API or MCP input object rather than asking the language model to provide them. This is another form of schema reduction. The agent sees fewer arguments and has fewer opportunities to fill in the wrong tenant, region, or user. Defaults work in the same way for other non-essential values. The mask keeps the raw service available while presenting the model with a smaller and more dependable call. ### Versioned masks are needed when agents depend on stable multi-step behavior [22:59](https://www.youtube.com/watch?v=55YwbrTrruU&t=1379s) In the question period, Frank says his team versions its tool masks. He considers versioning necessary whenever an agent's behavior depends on an exposed surface, especially when that surface comes from another service that may change through MCP. A long process can fail if a tool call in step seven changes unexpectedly. For enterprise automation, he wants the underlying behavior locked down as far as possible. He distinguishes this from exploratory work, where dynamic behavior may be useful. Across thousands of executions, however, variability makes it harder to produce the expected result and recover when something changes. ## Notable quotes - "What it doesn't do is filtering the tool surface that gets to your agent." (03:10) - "So tools are prompts, and we're generally overlooking the engineering of tools quite a lot." (14:11) - "The less choice the better your agent performs." (19:33) - "If the LLM does not have to provide that, it will make less mistakes." (22:20) - "For enterprise automation, variability is in general your enemy and you try to make sure that you stay on top of what happened." (25:21) ## Tools & references mentioned - Databook - Microsoft - Salesforce - AWS - MCP - Model Context Protocol - Yahoo Finance - Anthropic ## Who should watch - You are building production agents with many tools and see prompt size, tool selection, or inconsistent outputs becoming recurring problems. - Your team owns APIs that agents use, but changing the underlying service for every agent-specific requirement is too slow or risky. - You need enterprise agents to run repeatably across long workflows and want practical guidance on validation, authorization, defaults, and versioning. ## Related talks - [Tool Calling](https://mlopstalks.com/talks/tool-calling) (Alex Salazar, Arcade.dev & Nishikant Dhanuka, Prosus Group & Luciana Ledesma, MeaningStack, 40:22) - [Advanced Context Engineering](https://mlopstalks.com/talks/advanced-context-engineering) (, 28:42) - [Building Agentic Tools for Production](https://mlopstalks.com/talks/building-agentic-tools-for-production) (Sam Partee, Arcade AI, 23:55) - [Enterprise-ready MCP](https://mlopstalks.com/talks/enterprise-ready-mcp) (Jiquan Ngiam, MintMCP, 28:36) - [Context Engineering 2.0](https://mlopstalks.com/talks/context-engineering-2-0) (Simba Khadder, Redis, 45:34)