The two MCP servers I use daily

MCP (Model Context Protocol) is the open standard for connecting AI applications to external tools; the official documentation describes it as the “USB-C port for AI applications”. A server advertises a set of tools, each with a typed schema; the agent loads those schemas into its context window at the start of a session; the model then calls the tools by name as it works. The schemas are loaded whether or not the tools ever get called, so an idle server consumes context on every request. The ecosystem has grown quickly, and it is easy to accumulate a dozen servers that an agent never touches.

After months of daily agentic coding across a production monorepo (a FastAPI backend, a React frontend, and two native mobile apps), exactly two MCP servers remain in my configuration. In this note, I describe the two servers and the selection rule they suggest.

Playwright MCP for browser verification

Playwright MCP is Microsoft’s browser-automation server. It drives the browser through Playwright’s accessibility tree rather than through pixel positions: the agent receives structured element data instead of screenshots, which not only removes the need for a vision model in the loop but also makes each interaction deterministic, targeting a named element rather than a coordinate near one. The same choice shows up in the tool inventory. Counting the current README, the default and opt-in sets contain 23 and 45 tools, respectively, and all six coordinate-based tools sit in the opt-in group behind a vision capability flag; the default configuration operates on structure only.

My daily use is verification rather than test authoring. When an agent changes frontend code, a passing build does not establish a working page. Having the agent open the staging URL, snapshot the accessibility tree, and confirm that the element it just shipped is present in the render closes a loop that file-level tools cannot close.

mobile-mcp for on-device verification

mobile-mcp applies the same technique to native applications: iOS and Android, on real devices, simulators, and emulators, through one platform-agnostic interface. It prefers the native accessibility tree for most interactions and falls back to screenshot-based coordinates only where accessibility data is not available. For Android work this replaced the ad-hoc adb (Android Debug Bridge) scripts I had accumulated; the agent now launches the app, walks the UI (user interface), and reports what the device rendered. The distance between code that compiles and code that works is larger on a phone than anywhere else in my stack, and this is the only technique I have that lets the agent observe that difference directly.

The selection rule

In contrast, everything else I tried lost to plain file and shell tools: a database server was beaten by the agent writing psql one-liners directly, and an API (application programming interface) testing server by curl. MCP earns its place where the shell cannot reach, a rendered browser or a physical device. Where a mature CLI (command-line interface) already exists, however, a server loses on both speed and context cost. The filter rule for my configuration is therefore short: (1) a server stays only when it provides a surface no CLI covers; (2) an idle server is never free, because its tool schemas occupy context on every request.

It should be noted that the tool counts above are my own tally of the Playwright MCP README as of 2026-07-05; the inventory changes between releases. TODO (2026-07): measure the token cost of the 23 default schemas in a live session. The filter rule currently rests on the direction of that cost, not on its size.