브라우저 DevTools MCP: Playwright MCP보다 78% 적은 토큰, 더 빠르고 일관됨

[Sitemap](https://medium.com/sitemap/sitemap.xml) [Open in app](https://play.google.com/store/apps/details?id=com.medium.reader&referrer=utm_source%3DmobileNavBar&source=post_page---top_nav_layout_nav-----------------------------------------) Sign up [Sign in](https://medium.com/m/signin?operation=login&redirect=https%3A%2F%2Fmedium.com%2F%40serkan_ozal%2Fbrowser-devtools-mcp-78-fewer-tokens-vs-playwright-mcp-faster-and-more-consistent-32f314004d30&source=post_page---top_nav_layout_nav-----------------------global_nav------------------) [Medium Logo](https://medium.com/?source=post_page---top_nav_layout_nav-----------------------------------------) Get app [](https://medium.com/m/signin?operation=register&redirect=https%3A%2F%2Fmedium.com%2Fnew-story&source=---top_nav_layout_nav-----------------------new_post_topnav------------------) [Search](https://medium.com/search?source=post_page---top_nav_layout_nav-----------------------------------------) Sign up [Sign in](https://medium.com/m/signin?operation=login&redirect=https%3A%2F%2Fmedium.com%2F%40serkan_ozal%2Fbrowser-devtools-mcp-78-fewer-tokens-vs-playwright-mcp-faster-and-more-consistent-32f314004d30&source=post_page---top_nav_layout_nav-----------------------global_nav------------------)  # **Browser DevTools MCP — 78% Fewer Tokens** vs. Playwright MCP, Faster and More Consistent [](https://medium.com/@serkan_ozal?source=post_page---byline--32f314004d30---------------------------------------) [Serkan Özal](https://medium.com/@serkan_ozal?source=post_page---byline--32f314004d30---------------------------------------) 9 min read · Mar 12, 2026 [](https://medium.com/m/signin?actionUrl=https%3A%2F%2Fmedium.com%2F_%2Fvote%2Fp%2F32f314004d30&operation=register&redirect=https%3A%2F%2Fmedium.com%2F%40serkan_ozal%2Fbrowser-devtools-mcp-78-fewer-tokens-vs-playwright-mcp-faster-and-more-consistent-32f314004d30&user=Serkan+%C3%96zal&userId=e3a90b30bafe&source=---header_actions--32f314004d30---------------------clap_footer------------------) -- 1 [](https://medium.com/m/signin?actionUrl=https%3A%2F%2Fmedium.com%2F_%2Fbookmark%2Fp%2F32f314004d30&operation=register&redirect=https%3A%2F%2Fmedium.com%2F%40serkan_ozal%2Fbrowser-devtools-mcp-78-fewer-tokens-vs-playwright-mcp-faster-and-more-consistent-32f314004d30&source=---header_actions--32f314004d30---------------------bookmark_footer------------------) Listen Share Press enter or click to view image in full size  ## **Introduction: Browser Agents and Agentic Coding** **Browser agents** are AI-driven systems that control a real browser — navigating pages, interacting with UI, reading DOM or accessibility trees, taking screenshots — to accomplish tasks that require seeing and acting on the web. They sit at the intersection of LLMs and the browser, usually exposed as tools (e.g. via the Model Context Protocol, or MCP) so that an AI assistant can “use the browser” to verify flows, debug issues, or automate workflows. For **agentic coding** and QA workflows, browser agents are essential. Developers and AI assistants need to confirm that an app works _in the real browser_ : login, add to cart, checkout, and so on. Doing this without a browser agent means either manual testing or brittle, hand-written scripts. A well-designed browser MCP lets the assistant explore the app, detect visual and functional issues, and report back — all within the same conversation. So getting browser agents right is not just a convenience; it directly affects how efficiently AI can reason about and validate web apps. The catch: **browser agents are easy to design in a way that burns through tokens.** This post explains what goes wrong with typical designs, why common benchmarks mislead us, and how we built Browser DevTools MCP to stay both feature-rich and token-efficient — with benchmarks to back it up. ## What’s Wrong with Existing Browser Agent MCP Solutions ### 1. Context Bloat from Cumulative Tool Results In long sessions, **every tool result stays in context**. The model receives the full conversation history on each turn, including all previous tool outputs. For browser agents, the worst offenders are **screenshots** and **DOM (or accessibility) snapshots** : they are large and repeat every time. A concrete example makes the cost obvious. Assume: * Tool definitions (names, descriptions, input schemas) take **~500 tokens** and are sent every turn. * Each **screenshot** or **snapshot** returned as a tool result is ~**4–5K tokens** (e.g. base64 image or large JSON). Press enter or click to view image in full size  **Step-by-step context growth** By the time the agent has taken three or four screenshots or snapshots, **the first tw