Modern QA2026How Each Approach Works — tiles
Log inJoin
45 / 168 · 01 Agent Skills for Browser Automation · Skills vs MCP: Architectural Comparison← prev⊞ allnext →☰ Read as one page

7.2How Each Approach Works

MCP Server Approach (e.g., Playwright MCP)

┌────────────────┐    stdio/SSE     ┌──────────────────┐    CDP/BiDi   ┌─────────┐
│  Claude Code   │◄────────────────►│  MCP Server      │◄─────────────►│ Browser │
│                │                  │  (playwright-mcp)│               │         │
│  Tools:        │                  │                  │               │         │
│  - browser_    │                  │  Runs:           │               │         │
│    navigate    │                  │  - Browser pool  │               │         │
│  - browser_    │                  │  - A11y snapshots│               │         │
│    click       │                  │  - State mgmt    │               │         │
│  - browser_    │                  │                  │               │         │
│    screenshot  │                  │                  │               │         │
│  (15-25 tools) │                  │                  │               │         │
└────────────────┘                  └──────────────────┘               └─────────┘

What's loaded per API call:

  • 15-25 tool schemas (~5,000-12,500 tokens)
  • Accessibility tree per page (~2,000-10,000 tokens), streamed inline on every action
  • Tool call/response JSON (~200 tokens each)

Skill Approach (Playwright CLI)

┌────────────────┐                   ┌──────────────────┐               ┌─────────┐
│  Claude Code   │                   │  playwright-cli  │◄─────────────►│ Browser │
│                │     Bash tool     │  (Playwright     │               │         │
│  Context:      │────────────────►  │   engine)        │               │         │
│  - SKILL.md    │  "playwright-cli  │                  │               │         │
│    (~1K tokens)│   click e8"       │  Writes to disk: │               │         │
│                │                   │  .playwright-cli/│               │         │
│  Tools:        │◄────────────────  │  - YAML snapshots│               │         │
│  - Bash        │  ref / file path  │  - Screenshots   │               │         │
│  (1 tool)      │                   │  - Session state │               │         │
└────────────────┘                   └──────────────────┘               └─────────┘

What's loaded per API call:

  • SKILL.md content (~1,000 tokens, once — generated by playwright-cli install --skills)
  • Skill description in tool list (~50 tokens)
  • Bash tool schema (~200 tokens, shared with all Bash usage)
  • Command output — often just an element ref or a file path (dozens of tokens)
  • YAML snapshots only when the agent decides to read them from disk

The last line is the architectural pivot: page state lands in .playwright-cli/ as YAML files, and the agent decides what enters the context window. With MCP, the protocol decides — and it decides "everything, always."

Historical note: the disk-first CLI-skill pattern was pioneered by Vibium's vibe-check CLI (Jason Huggins, the creator of Selenium; V1 shipped June 2026, adoption still unproven). Microsoft's Playwright CLI is the same idea productized on top of the world's most-used browser engine — which is why this module teaches the Playwright CLI as the primary tool and covers Vibium as a case study in the Competitive Landscape part.