Forem: Susanna Wong

Supercharge Your Web Dev Game with MCP - Part 3: From Isolated Tools to End-to-End MCP Workflows

Susanna Wong — Wed, 31 Dec 2025 19:08:37 +0000

This is a three-part series based on a talk I gave under the same title.
In the first post, I talked about why MCP exists at all — as a way to standardise how models interact with tools. In the second, I zoomed in on Chrome DevTools MCP and showed how browser-level instrumentation becomes dramatically more powerful when AI can reason over it.

_In this final post, I want to step back and look at the bigger picture: what happens when you don’t just use MCPs, but start extending and composing them to fit your own workflows.

Chrome MCP is powerful on its own, but most developer workflows don’t fail because we lack data — they fail because we lack accumulated understanding. Using a simple performance tracker MCP built on top of Chrome MCP, I’ll use this as an example to show how chaining MCPs adds memory and automation, turning isolated tools into an end-to-end workflow.

The missing piece: memory
Think about a typical performance investigation.
You run a trace. You spot something slow. You apply a fix. You rerun the trace. You move on.

The artefacts are valuable:

traces
metrics
screenshots
network waterfalls

But once the task is done, they usually disappear. Some results live in ad-hoc notes. Some stay buried in folders. Some only exist in a developer’s head. And crucially, there’s no consistent way to compare runs, track trends, or answer questions like:

Has this page actually improved over the last three releases?
Which changes made performance worse - and when?
Are we fixing the same regressions repeatedly?

This is the gap an end-to-end MCP workflow is designed to fill.

Composing MCP servers, not building monoliths
The instinctive reaction might be: “Let’s just make a smarter Chrome MCP.”

But that’s exactly the wrong direction.

Instead of adding more responsibility to one server, MCP encourages composition.

In the workflow I’ll describe here, we deliberately split responsibilities:

- Chrome DevTools MCP
Responsible only for measurement
It observes the browser and returns raw facts.

- A custom Performance Tracker MCP
Responsible for memory and comparison
It stores results, tracks changes, and exposes history.

- The LLM (via the host/client)
Responsible for reasoning
It decides what to run, what to store, what to compare, and how to explain outcomes.

Each piece does one job well. None of them becomes a god object.

A clean separation of concerns
This architecture works because each layer stays honest about its role.

Chrome MCP doesn’t “understand” performance - it just measures it.
The custom MCP doesn’t interpret metrics - it just remembers and exposes them.
The LLM doesn’t collect raw data - it reasons over what it’s given.

This separation makes the system:

easier to evolve
easier to test
easier to reuse across tools and teams

Most importantly, it prevents us from baking intelligence into places where it doesn’t belong.

What the custom MCP actually does
The custom MCP server is intentionally boring - and that’s a good thing.

It doesn’t talk to Chrome.
It doesn’t run traces.
It doesn’t optimise anything.

Instead, it focuses on three kinds of capability, exactly as MCP intends.

Tools: actions with side effects
Tools represent intentful operations:

start an experiment
save a diagnostic run
log a code change
compare two runs

Each tool:

has a strict schema
performs one deterministic action
writes or retrieves data from storage

They’re auditable, composable, and predictable.

Resources: structured memory
Resources expose read-only views of state:

experiment metadata
run history
change timelines

This allows the LLM to ground its reasoning in facts:

“Compare the last three runs.”
“Show me regressions since commit X.”

Prompts: reusable reasoning scaffolds
Prompts capture common analysis patterns:

explain a regression
summarise improvements
identify trends over time

They reduce prompt duplication and keep reasoning consistent across sessions and users.

The overall setup of this MCP is laid out as follows:

The key idea here is subtle but important:
A well-designed MCP server exposes actions, memory, and reasoning scaffolds — not intelligence.

How the end-to-end workflow plays out
Once these pieces are in place, the workflow becomes almost boringly smooth.

1. A developer asks a high-level question:
“Improve performance on the checkout page.”

2. The LLM calls Chrome MCP to:

launch a browser
navigate to the page
run a performance trace

3. Chrome MCP returns raw artefacts:

Core Web Vitals
traces
network data
screenshots

4. The LLM analyses the data and decides:

what’s worth keeping
what changed
what to fix next

5. The LLM calls the custom MCP to:

save the diagnostic run
log associated code changes
compare against previous runs

6. Fixes are applied.

7. The exact same measurements are rerun.

8. The LLM compares before and after:

explains improvements
highlights regressions
summarises trends over time

At no point does any single component need to know the whole system.

Why this feels different from “AI tools”
What’s interesting about this setup is that nothing here is particularly magical.

There’s no new model capability.
No clever prompt trick.
No opaque automation.

The leverage comes from structure:

consistent measurement
persistent memory
explicit composition
clear responsibility boundaries

This is why MCP feels less like an AI feature and more like an architectural shift.

From one-off assistance to continuous workflows
Most AI dev tools today are optimised for moments:
“Generate this code.”
“Explain this error.”
“Summarise this diff.”

MCP workflows are optimised for continuity:

across runs
across changes
across time
across people

That’s the real shift. Not smarter models - but systems that can remember, compare, and evolve alongside the codebase.

Final thoughts
Across these three posts, I’ve tried to make one argument:
AI becomes genuinely useful in developer workflows not when it gets better at guessing, but when it’s embedded into the same systems we already trust - browsers, filesystems, version control, and now, structured protocols like MCP.

Chrome MCP shows what’s possible when AI can see the browser.
Custom MCPs show what’s possible when AI can remember.

Together, they point toward workflows that are faster, more reliable, and easier to reason about.

That’s not a future vision. It’s already buildable - one focused MCP server at a time.

This is the first time I’ve turned a talk into a blog post series, so I’d genuinely love any feedback — especially on what resonated, what didn’t, or what you’d like me to expand on next, as I’ll be continuing to develop this material for more conference talks throughout the year. Looking forward to hear from you, and see you at my next post!

Supercharge Your Web Dev Game with MCP - Part 2: Chrome DevTools MCP + AI-Driven Web Performance

Susanna Wong — Tue, 30 Dec 2025 02:35:32 +0000

In part 1 of this blog post series, I talked about why MCP exists at all - how it creates a clean contract between language models and the tools developers rely on every day. In this post, I want to zoom in on one MCP server that, in my experience, changes the game for web developers more than most: the Chrome DevTools MCP.

Chrome MCP was released recently, and there’s already plenty of content showing how to install it or wire it up. I want to focus on something slightly different: how it works under the hood, why its architecture matters, and what becomes possible when browser-level performance data is no longer something you manually collect and interpret, but something an AI agent can reason about directly. In case you are interested, here are some of the great materials to get you started on the actual steps of hooking Chrome MCP to your workflow:

Why the browser matters more than ever
For web engineers, the browser is the truth.

No matter how elegant your code looks in an editor, what users experience is defined by:

how fast the page renders
what blocks rendering
which scripts monopolise the main thread
how layout shifts during load
how interactions feel under real CPU and network constraints

We already have excellent tools to inspect all of this - Chrome DevTools, Lighthouse, performance traces - but they’re still deeply manual. Running audits, capturing traces, correlating metrics, and explaining why something is slow is work that lives almost entirely in the developer’s head.

Chrome MCP changes that dynamic by making the browser a programmable, inspectable system that AI can work with directly.

Chrome MCP is CDP, but usable by AI
At its core, Chrome MCP is built on top of the Chrome DevTools Protocol (CDP) - the same low-level protocol that powers Chrome DevTools, Puppeteer, and most browser automation tools.

CDP exposes almost everything happening inside the browser:

DOM structure and computed styles
network requests and timing breakdowns
JavaScript execution and long tasks
performance traces and Core Web Vitals
rendering, layout shifts, and paint events
device, CPU, and network emulation

The problem has never been capability. CDP is extremely powerful.
The problem is that it’s low-level, verbose, and not AI-friendly.
Chrome MCP solves this by wrapping CDP in high-level, strongly-typed MCP tools - things like:

- navigate_page
- performance_start_trace
- performance_stop_trace
- performance_analyze_insight

Instead of emitting thousands of raw CDP events, the MCP server gathers, structures, and returns the data in a way an LLM can actually reason over.

In short:
CDP gives superpowers. Chrome MCP makes those powers usable by AI.

How to think about Chrome MCP as a developer
From an architectural point of view, I find it helpful to think of Chrome MCP as:

A local microservice that exposes DevTools capabilities as strongly-typed MCP tools, backed by Puppeteer/CDP, with Chrome lifecycle and isolation handled for you.*

This framing matters because it changes how you integrate it:

You don’t treat it like a pile of scripts
You treat it like a backend service
The tool schemas are your API surface
Behaviour is tuned via configuration, not code changes

Under the hood, Chrome MCP is essentially a Node.js MCP server that:

launches or attaches to a Chrome instance
controls it via Puppeteer and CDP
exposes a curated set of browser tools via MCP
returns structured data back to the client

Because it’s packaged and distributed as an npm-based MCP server, it behaves like any other dependency in your workflow: versioned, upgradable, and composable.

A layered architecture, not a pile of hacks
One thing I appreciate about the Chrome MCP implementation is that it’s clearly designed as a system to seamlessly integrate into the web development workflow.

At a high level, it follows a layered architecture:

MCP server layer:
Handles protocol, tool registration, permissions, and transport.

Tool adapter layer:
Each MCP tool is a small, well-defined function with validated inputs and structured outputs.

Chrome runtime layer:
A real Chrome or Chromium instance — headless or headful — executing browser actions.

Data collection layer:
Aggregates traces, metrics, screenshots, network data, and serialises them into MCP responses.

Conceptually, every request flows the same way:
LLM / IDE → MCP client → Chrome MCP server → Puppeteer / CDP → Chrome → structured data back

That consistency is what makes the system predictable and automatable.

Web performance: from manual ritual to closed loop
This is where Chrome MCP really shines.

Traditionally, performance work looks like this:

Run Lighthouse
Capture a trace
Stare at flame charts
Guess which optimisations matter
Apply fixes
Re-run everything
Hope results are comparable

Chrome MCP turns this into a closed-loop, repeatable workflow.

What Chrome MCP does
Chrome MCP is responsible for measurement and instrumentation, not interpretation.

It can:

launch a controlled browser session
navigate to a page or run scripted flows
start and stop performance tracing
collect:
- Core Web Vitals (LCP, CLS, INP)
- performance timelines
- network waterfalls
- screenshots and filmstrips
- DOM attribution (e.g. which element caused LCP)

All of this is gathered programmatically and reproducibly.

What the LLM does
The LLM - running in your IDE or host - reads that structured data and answers higher-level questions:

Why is LCP slow?
Which requests are render-blocking?
Is CLS caused by images, fonts, or late hydration?
Which scripts dominate main-thread time?

This separation is important. Chrome MCP provides evidence.
The LLM provides reasoning.

Performance tools that matter in practice
The Chrome MCP performance toolset is intentionally small but powerful:

performance_start_trace
performance_stop_trace
performance_analyze_insight

These tools abstract away a lot of fragile timing logic:

when to start tracing
when to stop
how to correlate events
how to extract meaningful metrics

The result is something that feels closer to a performance RPC than a browser script.

Once you have that, new workflows become trivial:

run a baseline performance trace
apply a change (code splitting, lazy loading, image optimisation)
re-run the same trace
compare before/after metrics
explain the difference in human terms

Performance stops being a one-off audit and becomes an iterative feedback loop.

Why this changes how teams work
What excites me most isn’t that Chrome MCP can collect performance data - we’ve been able to do that for years. It’s that the data becomes:

automated
repeatable
explainable
shareable

Instead of screenshots and gut feelings, you get:

concrete metrics
attributed causes
reproducible runs
clear before/after comparisons

That makes performance conversations easier not just with engineers, but with product and leadership too.

A concrete example: turning performance into a feedback loop
To make this less abstract, let me walk through a real kind of scenario where Chrome MCP fundamentally changes how performance work feels.

Imagine a product page that looks fine in local development, but users are reporting that it feels slow on mobile. Historically, this is where performance work gets fuzzy. You might run Lighthouse once or twice, glance at a flame chart, and come away with a vague sense that “JavaScript is heavy” or “images are probably too large”.

With Chrome MCP in the loop, the workflow becomes much more explicit.

Baseline: measure, don’t guess
The first step is to establish a baseline. Using Chrome MCP, the agent launches a headless Chrome session, navigates to the page, and runs a performance trace under controlled conditions - mobile emulation, throttled CPU, and a constrained network.

What comes back isn’t a score, but structured data:

LCP at ~4.1s, attributed to a large hero image
INP degraded by long main-thread tasks during hydration
Several render-blocking JavaScript bundles
A noticeable gap between first paint and meaningful interactivity

This already changes the conversation. Instead of “the page feels slow”, you now have concrete signals and clear suspects.

Intervention: small, targeted fixes
Based on the trace data, the LLM proposes a short list of changes:

Preload the hero image and serve a smaller responsive variant
Lazy-load below-the-fold components
Split a large JavaScript bundle so non-critical code doesn’t block initial render

These aren’t generic best practices - they’re directly tied to the observed metrics and trace events. The fixes are applied, committed, and ready for validation.

After: rerun the exact same measurement
Here’s where Chrome MCP really earns its place.
The agent reruns the same performance trace, with the same throttling and navigation flow. No manual setup. No “did I click the same thing?”. The comparison is apples-to-apples.

This time, the results look very different:

LCP drops to ~2.3s
Main-thread blocking during hydration is significantly reduced
Network waterfall shows fewer render-blocking resources
Visual stability improves, with no unexpected layout shifts

Because both runs are machine-driven, the before/after comparison is clean. The LLM can now explain why things improved, not just that they did.

Why this matters
None of this is impossible without Chrome MCP. But without it, performance work tends to be:

manual
inconsistent
hard to reproduce
difficult to explain to others

With Chrome MCP, performance becomes a closed loop:

Measure with evidence
Apply targeted fixes
Re-measure under identical conditions
Explain the impact clearly

That loop is what turns performance from a one-off audit into something you can iterate on confidently - and something AI can genuinely help with, rather than hand-waving about.

Chrome MCP turns the browser into a first-class execution and measurement engine for AI-driven workflows. It doesn’t replace DevTools; it operationalises them. It takes everything we already trust about browser instrumentation and makes it programmable, composable, and AI-native.

In the next post, I’ll tie everything together and look at what happens when you combine Chrome MCP with other MCP servers — filesystem, Git, design data, and automation — to create end-to-end developer workflows that go far beyond code generation.

That’s where MCP stops being interesting infrastructure and starts becoming leverage.

Stay tuned, and see you at the next post!

Supercharge Your Web Dev game with Chrome MCP - Part 1: All about the MCP

Susanna Wong — Sun, 28 Dec 2025 01:18:34 +0000

Hi everyone! I’m a product engineer who’s worked across very different kinds of organisations, from tight-knit tech teams in large corporates, to startups, to the largest consultancy in the world. Across all of them, I’ve seen how products get built at very different speeds, and how much those speeds shape the way teams work.

For the past six months, I’ve been working at an AI startup, where speed and iteration aren’t occasional crunch modes - they’re the everyday game. In that environment, developers don’t really have the option to ignore AI tooling. If you want to keep up, you have to embrace it, not just to write code faster, but to iterate, debug, validate, and ship better.

This post is the first in a three-part series based on a talk I gave under the same title. The talk compressed a lot of ideas into slides; this series is my attempt to slow down and properly elaborate on the core concepts behind it.

In this first part, I’ll focus on the foundations: what the Model Context Protocol (MCP) is, why it exists, and how different types of MCP servers enable more reliable AI-powered developer workflows. The next posts will go deeper into concrete examples and hands-on use cases.

How MCP changes the way we build with AI
When people talk about AI in developer workflows, the conversation often jumps straight to code generation. Faster scaffolding. Better autocomplete. Smarter refactors. All useful, but also a little narrow.

The real friction in day-to-day web development isn’t usually writing code. It’s everything that happens around it: checking layouts, cross-referencing designs, running tests, inspecting network requests, reproducing bugs, validating performance. None of this is hard in isolation. It’s just fragmented.

If I’m debugging a UI issue, my mental loop looks something like this: open DevTools, inspect the DOM, check the network panel, jump to Figma to confirm spacing or colors, maybe spin up Puppeteer to reproduce the issue, then go back to the editor to apply a fix. Each step is logical. Together, they form a slow, manual choreography that only exists in my head.
This is the gap MCP fills.

MCP - the missing connective tissue
I like to think of MCP as the love language between you, the LLM, and your tools. That phrase sounds playful, but it’s surprisingly accurate.

Before MCP, LLMs were isolated. They could reason, but they couldn’t see or do much without bespoke integrations. Every tool required custom glue code. Every AI application hard-coded how it talked to Git, the filesystem, a browser, or a design tool. As the number of tools grew, the complexity didn’t scale linearly - it exploded.
This became a real problem once LLMs started moving beyond chatbots into agents, IDEs, and production developer workflows. The model wasn’t the bottleneck anymore. Integration was.

MCP emerged in late 2023 as a response to this. Its core idea is simple but powerful: standardise how models receive context and use tools. In the same way HTTP decouples browsers from servers, MCP decouples models from the systems they interact with.
That decoupling turns out to be the key to everything that follows.

A cleaner separation of responsibilities
MCP introduces a clear Host–Client–Server architecture.

As a developer, I appreciate this not because it’s novel, but because it’s familiar. It follows the same separation-of-concerns principles we already trust in software design.

The host is where I work - my IDE, editor, or chat interface. It owns the UI and the interaction flow. The host doesn’t need to know how tools work internally.

The client lives inside the host. It speaks MCP. Its job is to manage context, discover available tools, and orchestrate requests. I think of it as the MCP-aware brain.

The server is where real capabilities live. An MCP server exposes tools, data, and prompts, and handles the messy details of talking to external systems - APIs, databases, files, browsers, or design tools.

What I find elegant here is that each piece stays honest about its role. Hosts don’t become integration nightmares. Servers don’t need to care about UI or prompt phrasing. The protocol does the connecting.

Source: “Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions”

MCP servers aren’t just APIs
One subtle but important shift MCP introduces is how we think about “tools”.

An MCP server doesn’t merely expose endpoints. It exposes capabilities in a model-friendly way, grouped into three concepts: tools, data, and prompts.

Tools are actions - things the model can do. Run a database query. Call an API. Edit a file. Execute a shell command. These are explicit, structured, and side-effecting.

Data (or resources) are context: things the model can read. Documentation, logs, code repositories, configuration files. They don’t execute anything, but they ground the model in reality.

Prompts are reusable ways of thinking. Instead of rewriting the same instructions over and over, prompts encode best practices: how to review a PR, how to analyse logs, how to summarise changes.
What matters isn’t any single piece, but how they work together.

Prompts guide reasoning. Data provides truth. Tools enable action. This combination is what makes MCP workflows feel reliable instead of fragile.

Three kinds of MCP servers - and why the distinction matters
Over time, I’ve found it useful to group MCP servers into three broad categories. This isn’t just taxonomy for its own sake; it helps clarify what role a server plays in a system.

Tool MCPs give the model hands. They let it act. Browser automation, filesystem access, Git operations, CLI wrappers - these are what turn an LLM from a passive assistant into something that can actually execute work. Debugging a UI bug becomes a closed loop: reproduce, inspect, fix, verify.

Data MCPs give the model eyes. Without access to real designs, APIs, or schemas, an LLM is forced to guess. With Data MCPs - like Figma, Fetch/HTTP, database queries, or documentation servers - the model can reason with accuracy. Design-to-code stops being aspirational and starts being dependable.

Automation MCPs are where things get interesting. They don’t just expose a single action or dataset; they orchestrate multi-step workflows. CI pipelines, QA routines, design consistency checks - all become repeatable processes instead of manual rituals. If Tool MCPs are hands and Data MCPs are eyes, Automation MCPs are the coordinator that connects everything.

The real power is in composition
Individually, each MCP category is useful. Together, they’re transformative.

A design change in Figma can be detected via a Data MCP, implemented through Tool MCPs, validated in the browser, committed to Git, and wrapped into a pull request - all orchestrated by an Automation MCP. That entire flow is impossible if any one piece is missing.

This is the moment where the LLM stops feeling like a chat interface and starts feeling like a teammate. Not because it’s “smarter”, but because it’s finally embedded into the same systems developers already rely on.

MCP - the standard contract for your bespoke needs
MCP isn’t exciting because it’s flashy. It’s exciting because it’s boring in the best possible way. It introduces structure where there was none. It replaces bespoke glue with standard contracts. And it lets us design AI-powered workflows using the same architectural instincts we already trust.

In the next post, I’ll zoom in on one specific MCP server - Chrome DevTools MCP - and show what this looks like in a real web development workflow.

That’s where things get practical.

Stay tuned - See you at my next post!