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.
2
MCP tools can be adapted by removing unnecessary tools, replacing generic descriptions, and adding guidance that changes which tools the agent prefers.
3
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.
Generic third-party tools can degrade an agent workflow
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
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
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
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
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
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
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
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
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.
"Once we have logged in, we take the reins and give it to the agent."36:28
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.
