Skills vs MCP: Architectural Comparison

Updated Aug 2026

The Fundamental Difference

MCP connects Claude to external capabilities (tools, data, APIs). Skills teach Claude how to use those capabilities for specific domains.

If MCP provides the "kitchen and ingredients," Skills provide the "recipes."

They are not competing alternatives — they are complementary layers. But for browser automation specifically, choosing one over the other (or using both) has significant implications. And as of July 2026, this is no longer a theoretical debate: Microsoft — the vendor of the most popular browser MCP server in the world — recommends the Playwright CLI over Playwright MCP for coding agents, citing roughly 4x fewer tokens per task (~27k vs ~114k).

How 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.

Detailed Comparison

Token Economics

The mechanism (schemas every turn, accessibility trees inline) can produce much larger per-step ratios on paper — but the honest, measured number for full tasks is ~4x, because the CLI agent still reads snapshots when it needs them and still spends tokens on reasoning. The next chapter walks through the math.

State Management

Note what changed versus the 2025-generation CLI tools: the Playwright CLI did not give up semantic page understanding to get cheap. Snapshots are the same accessibility-tree data MCP streams — they just live on disk with stable element refs (e8, e21) instead of being force-fed into context.

Error Handling

Setup & Maintenance

Decision Matrix: When to Use What

Use Skills (CLI) When:

1. Your agent has filesystem access — Claude Code, Cursor, CI runners. The disk is the context-overflow valve; this is the whole trick.

2. Your agent juggles many tasks — writing code, running tests, AND driving a browser. Token budget must be shared. This is Microsoft's explicit positioning for the CLI.

3. You're in CI/CD — token costs compound across hundreds of test runs. CLI commands are cheap.

4. You want composability — CLI commands chain with other tools (grep, jq, awk) via pipes, and snapshots are greppable YAML files.

5. Your tests are procedural — "navigate here, click that, type this, verify that" flows.

# Skills shine here: scripted, ref-driven, fast
playwright-cli open https://app.example.com/login
playwright-cli snapshot          # → YAML on disk: textbox "Email" [ref=e3], ...
playwright-cli fill e3 "test@example.com"
playwright-cli fill e4 "secret"
playwright-cli click e5
playwright-cli snapshot          # → verify: heading "Dashboard" present

Use MCP When:

1. The agent is sandboxed without filesystem access — hosted chat surfaces, some web agents. If there's no disk to write snapshots to, inline state is the only option. This is the clearest MCP win, and it's Microsoft's own guidance.

2. IDE integrations that speak MCP natively — tooling that already plumbs MCP end to end.

3. Long autonomous sessions with continuous introspection — when the loop genuinely needs page state on every single step, streaming it may be simpler than reading files each time.

4. Non-developer users — MCP-based assistants allow "click the big blue button" without any tooling setup on the user's machine.

# MCP shines here: no filesystem available
Hosted agent: "Go to our app and check if all form fields have proper labels"
Agent: *receives accessibility tree inline — no disk to read from*
Agent: *reasons about ARIA attributes*
Agent: *reports accessibility violations*

Use Both When:

1. Mixed environments — CLI in Claude Code and CI; MCP for the same flows when run from a sandboxed surface.
2. Different test types — functional execution via CLI, MCP kept for environments and integrations that require it.
3. Development vs CI — either transport during development, CLI in CI (cost optimization).

Microsoft's Own Assessment

This used to be the part of the course where we argued the token math from first principles. As of 2026, we can simply cite the vendor: Microsoft recommends the Playwright CLI over Playwright MCP for coding agents, benchmarking a typical browser task at ~27,000 tokens via CLI versus ~114,000 via MCP — about 4x, with larger savings on long sessions. At the same time, Playwright MCP remains fully supported and is published to the official MCP Registry with every release, because sandboxed agents without a filesystem still need it.

This is not a third-party opinion — it's the team that builds the world's most popular browser MCP server steering coding agents to the CLI. When the vendor of the protocol integration tells you the skill path is cheaper, the debate is settled; what remains is knowing when each applies.

Architecture Diagram: Hybrid Approach

                        ┌──────────────────────────┐
                        │      Claude Code Agent    │
                        │                           │
                        │  ┌────────┐ ┌──────────┐ │
                        │  │ Skills │ │ MCP Tools│ │
                        │  │(SKILL. │ │(browser_ │ │
                        │  │ md)    │ │ *)       │ │
                        │  └───┬────┘ └────┬─────┘ │
                        └──────┼───────────┼───────┘
                               │           │
                    Bash tool  │           │ MCP protocol
                               │           │
                        ┌──────▼──────┐  ┌─▼────────────┐
                        │ playwright- │  │ Playwright   │
                        │ cli         │  │ MCP Server   │
                        └────┬────────┘  └──────┬───────┘
                             │                  │
                             └───────┬──────────┘
                                     │  (same Playwright engine;
                                     │   browser.bind() can even
                                     │   share one browser)
                        ┌────────────▼─────────────┐
                        │  Chromium/Firefox/WebKit │
                        └──────────────────────────┘

In this hybrid model:

• playwright-cli handles interaction commands (open, goto, click, fill, snapshot, screenshot) — cheap, disk-first
• Playwright MCP serves sandboxed surfaces and MCP-native integrations — inline but expensive
• Since Playwright 1.59, browser.bind() lets both attach to the same browser instance — the transports are interchangeable views onto one session

Interview Talking Point

"We evaluated both MCP and CLI-skill approaches for browser automation. The key trade-off is where page state goes. MCP streams tool schemas and accessibility trees into the model context on every action; the Playwright CLI writes the same accessibility snapshots to disk as YAML, and the agent reads them only when it needs to — interacting via stable element refs. Microsoft's own benchmark puts a typical task at about 27k tokens via CLI versus 114k via MCP, roughly a 4x saving, and they now recommend the CLI for coding agents. We use the CLI as the primary interface wherever the agent has filesystem access, and keep Playwright MCP for sandboxed environments that don't. It's the same Playwright engine either way — since browser.bind() they can even share one browser."