# Bending a Public MCP Server Without Breaking It Nimrod Hauser, Baz | AI Engineer Europe 2026 | 40:50 Source: https://www.youtube.com/watch?v=U00AOI1eJUE Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/bending-a-public-mcp-server-without-breaking-it Published: 2026-04-08 Tags: context-engineering, guardrails, mcp, tool-use ## TL;DR - Third-party agentic tools can produce poor results or security problems because their descriptions and behavior are generic, while the consuming application has its own workflow and architecture. - MCP tools can be adapted by removing unnecessary tools, replacing generic descriptions, and adding guidance that changes which tools the agent prefers. - Sensitive actions such as file-path validation and login should use deterministic code around the agent, with clear error messages that let the agent retry safely. ## Summary Nimrod Hauser uses a toy version of Baz's spec reviewer to show how a public Playwright MCP server can fail and then be adapted. The reviewer reads a ticket and design, logs into an application, uses Playwright to inspect the implementation, and saves screenshot evidence. With the default MCP tools, the agent has 21 generic browser tools and hallucinates a URL, producing a failed review. Hauser then presents five ways to change the integration: curate the tool set, wrap tools with use-case-specific descriptions, add deterministic guardrails, compose new tools from existing ones, and call some tool functions outside the agent loop. The examples include preferring accessibility snapshots, restricting screenshot paths, creating a dedicated evidence screenshot tool, and logging in by injecting JWT tokens before the agent starts. The final run passes the review. Hauser is clear that the right balance depends on the workflow, since some changes reduce context while others add useful detail. ## Key ideas ### Generic third-party tools can degrade an agent workflow [01:22](https://www.youtube.com/watch?v=U00AOI1eJUE&t=82s) Hauser treats MCP tools as callable functions paired with descriptions that tell an agent when and how to use them. The underlying code may be useful, but a third-party team cannot know every application's workflow. In the example, Playwright's MCP server exposes browser operations for many possible users. Hauser warns that adding such tools can make an already unpredictable agent less reliable. The effects range from wrong or inefficient actions to security problems. In a multi-tenant system, an agent that does not understand the application's folder, database, or schema boundaries could expose one client's data to another. ### The spec reviewer needs browser automation to compare implementation with requirements [04:29](https://www.youtube.com/watch?v=U00AOI1eJUE&t=269s) Baz's spec reviewer first collects requirements from systems such as Jira, Linear, or Figma. In the toy example, the requirement is represented by a ticket image and a design for a configuration drawer in the agents tab. The reviewer then starts Playwright's MCP server, opens a browser, logs into the system, checks the implementation, and produces a pass or fail verdict with a screenshot as evidence. This gives the tool integration a concrete purpose: the browser agent must find the right page and verify whether the implementation matches the stated requirement. ### The vanilla Playwright integration fails in a concrete way [10:25](https://www.youtube.com/watch?v=U00AOI1eJUE&t=625s) The baseline uses LangChain's load MCP tools method without changing the returned tools. Playwright supplies 21 browser tools, including operations for resizing, dialogs, file uploads, key presses, and screenshots. Their descriptions are short, such as "Press a key on the keyboard" and "Resize the browser window." During the first run, the agent cannot find the relevant page. It instead tries a seemingly invented buzz.co/spec-reviewer URL, reaches a 404 page, and produces a failed verdict with poor screenshot evidence. Hauser uses this failure as the starting point for the adaptations. ### Curating the tool set reduces choices that the workflow does not need [16:04](https://www.youtube.com/watch?v=U00AOI1eJUE&t=964s) The first adaptation filters the tools returned by Playwright before giving them to the agent. Hauser removes operations such as browser resizing, dragging, and running code in the browser because the spec reviewer does not need them. The example goes from 21 tools to 16. Fewer tools mean less material in the context window and fewer possible choices for the agent. Hauser also says this is specific to the use case. Another application might need the tools that Baz removes, so curation is an application decision rather than a universal MCP configuration. ### Tool wrappers can encode local experience in descriptions [18:18](https://www.youtube.com/watch?v=U00AOI1eJUE&t=1098s) The second adaptation keeps the original tool implementation but creates replacement tools with descriptions written for the spec reviewer. Hauser gives the agent explicit guidance about tool order. Before using browser hover or click, it should call Playwright's accessibility snapshot tool. That snapshot exposes buttons and menu items as text, which Hauser says gives the agent a better understanding of the page than an actual visual snapshot. The wrapper invokes the original tool unchanged, so the main change is the description and the behavior it encourages. The resulting tool set is smaller and has longer, more targeted instructions. ### Deterministic validation should block unsafe tool calls before execution [22:53](https://www.youtube.com/watch?v=U00AOI1eJUE&t=1373s) Hauser adds a path-validation layer around the visual screenshot tool. The application defines a screenshots root, but an agent might try to save an image elsewhere. Before the original tool is invoked, the wrapper extracts the requested path and checks whether it is inside the allowed folder. An invalid path raises an error and prevents the call. The error is formatted for the agent rather than failing the entire run: it explains that access is denied and asks for a valid path and file name. The agent can then retry with a permitted location. ### A new specialized tool can make an existing action easier to select [28:58](https://www.youtube.com/watch?v=U00AOI1eJUE&t=1738s) The fourth technique composes a new evidence tool from the existing screenshot capability. A normal screenshot may be useful during exploration, while a screenshot at the end of the review has a different purpose. The new tool's description says it is for evidence and tells the agent to include the relevant ticket number in the saved file name. Because the review prompt ends by asking for evidence, the agent can choose this specialized tool in that part of the workflow. The new tool can also carry its own deterministic actions or guardrails while reusing the existing screenshot implementation. ### Some MCP functions should run outside the agent loop [33:02](https://www.youtube.com/watch?v=U00AOI1eJUE&t=1982s) The fifth technique treats selected MCP functions as ordinary callable code. In the example, login always happens before the spec-reviewer agent starts, so Hauser removes it from the agent's decision-making. The toy implementation injects JWT tokens into browser local storage and clicks the login button. Real client systems may have different login mechanisms and secrets, which is one reason this step can be complicated. Once the deterministic login completes, the agent receives an already authenticated browser and focuses on navigating and reviewing the implementation. ### The final design balances context, flexibility, and enforcement [38:55](https://www.youtube.com/watch?v=U00AOI1eJUE&t=2335s) With the adaptations in place, the reviewer finds the configuration drawer, reports a pass, and saves evidence with the ticket in the file name. Hauser notes that the toy example does not prove pixel-perfect matching, although Baz works on that in its real product for padding, margins, and styling. His closing point is that the five techniques involve trade-offs. Filtering reduces context, while detailed descriptions add context. Some actions should remain flexible for the agent, while others need deterministic handling. The integration has to be shaped around the application's actual workflow. ## Notable quotes - "You give them tools, and you get unpredictability at scale." (03:05) - "A tool is just a callable function with some description." (26:00) - "We don't want the whole agentic process to fail." (27:49) - "Once we have logged in, we take the reins and give it to the agent." (36:28) ## Tools & references mentioned - Baz - Playwright - Playwright MCP server - LangChain - Jira - Linear - Figma - Salesforce Einstein - BlueVoyant - Solidus Labs ## Who should watch - You are integrating a public MCP server into an agent and the default tools lead to hallucinated navigation, poor results, or too many irrelevant choices. - Your agent can perform sensitive actions such as writing files, accessing tenant data, or authenticating into customer systems. - You want concrete patterns for deciding which tool behavior belongs in prompts and descriptions, and which behavior should be enforced in application code. ## Related talks - [Your MCP Server is Bad (and you should feel bad)](https://aietalks.com/talks/your-mcp-server-is-bad-and-you-should-feel-bad) (Jeremiah Lowin, Prefect, 54:33) - [MCP Is Not Good Yet](https://aietalks.com/talks/mcp-is-not-good-yet) (David Cramer, Sentry, 16:41) - [Exposing Agents as MCP Servers with mcp-agent](https://aietalks.com/talks/exposing-agents-as-mcp-servers-with-mcp-agent) (Sarmad Qadri, Last Mile AI, 18:05) - [Just do it. (let your tools think for themselves)](https://aietalks.com/talks/just-do-it-let-your-tools-think-for-themselves) (Robert Chandler, Wordware, 06:50) - [Building Agent Interfaces: Lessons from Chrome DevTools (MCP) for Agents](https://aietalks.com/talks/building-agent-interfaces-lessons-from-chrome-devtools-mcp-for-agents) (Michael Hablich, Google, 22:38)