DEV Community: Aleksandr Argunov

WebMCP vs MCP: when an agent should go through the browser

Aleksandr Argunov — Fri, 23 Oct 2026 13:47:00 +0000

I've built a few WebMCP integrations, and I'm still not sure about it.

The short version: WebMCP only makes sense to me when the agent is part of the browser, where you can watch and step in. When you work through chat, it feels unnatural. Why keep a browser involved when the agent can call the service directly? For a chat app, a desktop client, code or a job nobody watches, build a direct MCP connection. Shopify draws roughly the same line for its checkout.

WebMCP, browser-control tools and server MCP

WebMCP is a proposed web standard. The page registers tools, and the browser's built-in agent calls them, so the agent doesn't have to guess what a button does. Chrome runs it as an origin trial from Chrome 149, with a flag for local development, and says the API may still change.

Browser-control MCP tools are MCP servers that operate a browser by clicking and typing. The site declares nothing, so the agent reads the page and works out what each element is for. Chrome calls this actuation and describes WebMCP as the more reliable option.

Server MCP means the service exposes its own tools, for example over MCP's Streamable HTTP transport, which streams with SSE. No browser is involved. An MCP client such as ChatGPT Desktop or Claude Code calls the service directly, from a chat or from code.

Chrome's own comparison is clear that WebMCP doesn't replace MCP. WebMCP tools exist only while the page is open. An MCP server is there whenever a client calls it.

What I found building both

The latest WebMCP integration I built let agents work on screenplay projects in a video web service, using the interface and the functions behind it.

It worked. But I ended up replacing it with a direct MCP connection. I could control projects from ChatGPT Desktop or Claude Code without keeping the web interface in the loop. In my workflow, I found it faster, and it used fewer tokens. Without the browser, it was also much easier to build automated agent workflows in code. I haven't gone back to the WebMCP version.

The automation part follows from the design: code can reach WebMCP tools only through a browser that has the page loaded. A server MCP has no page to keep open.

Shopify checkout: two ways in

Shopify added WebMCP support to checkout on 2026-09-28. Browser agents can now read and update eligible checkouts, and submit them once the buyer confirms. Shopify's docs describe this and a server option side by side.

Checkout WebMCP works on the checkout open in the buyer's tab. It registers get_checkout, update_checkout and complete_checkout, plus navigate_to_storefront when the store has an online storefront. Before calling complete_checkout, the agent has to show the buyer the order and total and get their permission. Shop Pay login and payment challenges stay with the buyer, on the page. (Checkout WebMCP reference)

The tools only appear on eligible checkouts. Shopify lists the exceptions: B2B checkouts, embedded and mobile-SDK checkouts, checkouts with another shop's merchandise, draft orders, order edits, payment collection, and the standard three-page checkout unless the buyer uses Shop Pay. update_checkout also leaves line items alone; the buyer changes those on the page. If you build on Shopify, check that list against your store's checkout before planning around WebMCP.

Checkout MCP runs from your agent's server and doesn't depend on the buyer's browser. It's a JSON-RPC endpoint at https://{shop-domain}/api/ucp/mcp, and every request needs authentication or a signed request. When the buyer has to enter something or review the order, the agent hands them a checkout link to finish there. (Checkout MCP reference)

Shopify's docs recommend Checkout MCP unless the agent has to run in the buyer's browser. Either way, the buyer still approves the purchase.

Where this is heading

Long term, I think agent-native will become the standard. The UI, WebMCP and direct MCP should all work with the same underlying logic and state. People and agents can then use whichever interface fits, without rebuilding the workflow for each one.

Looks like Shopify is going this way too. Its WebMCP tools use the same state as the checkout UI, and both MCP options use the same checkout object. That's the direction I'm most interested in.

A shorter version of this first appeared on LinkedIn on 2026-09-30. The maintained version, with the date I last checked Chrome's and Shopify's docs, is on argbe.tech.

SSE vs WebSockets for AI apps: ten web standards and two patterns

Aleksandr Argunov — Thu, 22 Oct 2026 13:21:00 +0000

Out of the box, the official OpenAI and Anthropic Python SDKs talk HTTP/1.1, a protocol from 1997 (RFC 2068). Both build on HTTPX2, which leaves HTTP/2 off unless you turn it on (OpenAI SDK, Anthropic SDK, HTTPX2).

Streaming answers? When they stream over HTTP, both APIs use Server-Sent Events, a W3C standard since 2015 (OpenAI, Anthropic, W3C). Live voice? OpenAI recommends WebRTC for browser and mobile clients (OpenAI). Even MCP’s Streamable HTTP transport, which remote MCP servers use, sends HTTP POST requests, with SSE for streaming. Since the 2026-07-28 revision, each POST gets back either JSON or its own SSE stream, and the old always-open GET stream is gone (MCP).

Here are ten web standards and two patterns, with what each is good for in AI and where it falls short. Years mark standardization, not adoption. They don’t all compete: some are HTTP versions, others are transports, browser APIs or an authentication scheme, and several stack. HTTP/3 runs on QUIC (RFC 9114), and SSE works over any HTTP version.

SSE or WebSockets?

If only the server talks while an answer streams, SSE is often enough. Reach for WebSockets when both sides talk at once.

Feature	SSE	WebSocket
Direction	Server to client	Both ways
Data	UTF-8 text	Text and binary frames
Runs over	An ordinary HTTP response	Its own protocol, after an HTTP upgrade
Use it for	Streamed answers, progress, notifications	Live sessions where both sides talk
Standardized	WHATWG HTML, W3C since 2015	RFC 6455, in 2011

With SSE, the client still talks back, just with separate HTTP requests. Binary data has to be encoded as text first.

Pick by job

You need to	Start with	Spec
Make one API or tool call at a time	HTTP/1.1 is fine	RFC 9112
Stream a model’s answer, progress or notifications	SSE	WHATWG HTML
Run a live session where both sides talk	WebSocket	RFC 6455
Add live voice or camera from a browser or phone	WebRTC	W3C
Make several API or tool calls at once to one origin	HTTP/2, or HTTP/3 on lossy networks	RFC 9113, RFC 9114
Run a complex read-only search with a body	HTTP QUERY, once every hop supports it	RFC 10008
Mix must-arrive results with droppable live updates	WebTransport	W3C CR
Show a site which agent is calling	Web Bot Auth	IETF draft
Follow a long job	Polling, or a webhook to your server	MCP Tasks, OpenAI

Established

HTTP/1.1

1997 · Simple requests and responses, first specified in RFC 2068. RFC 9112 is the current version.

Good for: single API calls and tool calls.
Falls short: no multiplexing. Parallel requests usually need several connections, and pipelined responses still come back in order.

WebSocket

2011 · A two-way connection kept open, carrying text or binary frames (RFC 6455).

Good for: live sessions where both sides talk, like server-side voice agents.
Falls short: for one-way text streaming, SSE is often enough.

SSE

2015 · Text pushed from server to client over HTTP (WHATWG HTML).

Good for: streamed answers, progress updates and notifications.
Falls short: no binary messages, and no two-way traffic on the same stream.

HTTP/2

2015, updated 2022 · Many streams over one TCP connection. RFC 9113 replaced the original RFC 7540.

Good for: an agent making several API or tool calls at once to the same origin. Native gRPC uses it (gRPC).
Falls short: one lost TCP packet can delay every stream on that connection.

QUIC

2021 · Encrypted transport over UDP with independent streams (RFC 9000).

Good for: a connection can survive a device changing networks, if the server allows it (§9). A lost packet holds up only the streams with data in it, which can be several, while the rest keep going (§13).
Falls short: some networks block UDP. Fallback is up to the app (RFC 9114).

WebRTC

2021 · Real-time audio, video and data. It first became a W3C Recommendation in January 2021.

Good for: live voice and camera with a model, from a browser or phone.
Falls short: often unnecessary for text. It needs connection setup, and maybe a relay server.

HTTP/3

2022 · HTTP over QUIC instead of TCP (RFC 9114).

Good for: it can cut setup time and cross-stream delays on lossy networks.
Falls short: making the model faster.

New standard

HTTP QUERY

June 2026 · Like GET, but with a request body. It’s safe and idempotent (RFC 10008).

Good for: complex read-only searches like AI retrieval, with safe retries and caching where supported.
Falls short: relying on it before your whole stack supports it: client, CDN, proxies and server.

Still developing

WebTransport

W3C Candidate Recommendation · Reliable streams plus droppable datagrams. Major browsers have shipped it since March 2026; older ones and embedded webviews need a check (MDN).

Good for: results that must arrive next to live updates that can go stale.
Falls short: code that can’t absorb changes. The IETF protocol is still a draft (IETF).

Web Bot Auth

IETF draft · Signed requests that show a site which agent is calling.

Good for: telling real agents from bots posing as them. Cloudflare already checks these signatures (Cloudflare).
Falls short: deciding what an agent may do. It proves identity, not permission.

Patterns, not protocols

Polling

Asking the server again and again whether something changed.

Good for: long AI jobs where checking every few seconds is fine, like MCP tasks. Where client and server support the Tasks extension, each job gets a handle to poll, and a client can pick it up again after reconnecting.
Falls short: live updates. You either waste requests or lag behind.

Webhooks

An HTTP request a service sends you when something happens.

Good for: telling your system that a batch run or agent task has finished. OpenAI, for one, sends them for batch and background jobs (OpenAI).
Falls short: they can’t reach a browser tab directly. Receiving them is a small integration of its own: a server that verifies signatures, handles duplicate deliveries and passes the event on.

I first shared this list on LinkedIn on 20 October 2026. The maintained version, with the animated diagram, every source and the date I last checked them, is on argbe.tech.

AI-generated unit tests: two patterns that pass with the bug, and a red-green fix

Aleksandr Argunov — Thu, 22 Oct 2026 08:49:54 +0000

Two tests can pass while applyDiscount(100) returns 100 instead of the ticket's 90. One replaces the function with a mock. The other copies its boundary bug into the expected value.

Agents love to create a thousand unit tests. All green. Then review smashes the whole thing.

The agent already implemented a trash solution, and only then wrote generalized unit tests for it. Those tests describe the code it just wrote. So they all pass, bugs included.

When an agent writes both the code and its tests, don't count the green checks. Look at where each expected value comes from. If it comes from the agent's code, the test can repeat the agent's mistake instead of catching it. If it comes from the ticket, the spec or a real example, and the test runs the real code and failed because the behavior was missing, it checks something.

Two patterns that pass with the bug

Here are both in TypeScript with Vitest. Suppose an agent writes this for a discount ticket:

// pricing.ts. The ticket: orders of 100 or more get 10% off.
export function applyDiscount(total: number): number {
    return total > 100 ? total * 0.9 : total // bug: should be >=
}

A test that mocks the function it's supposed to test:

// mocked.test.ts
import { expect, it, vi } from 'vitest'
import { applyDiscount } from './pricing'

vi.mock('./pricing', () => ({ applyDiscount: () => 90 }))

it('gives 10% off at 100', () => {
    expect(applyDiscount(100)).toBe(90) // checks the mock, not the code
})

A test that calculates the expected value with the code's formula:

// same-formula.test.ts
import { expect, it } from 'vitest'
import { applyDiscount } from './pricing'

it('applies the discount', () => {
    const total = 100
    // the code's own formula, bug included
    const expected = total > 100 ? total * 0.9 : total
    expect(applyDiscount(total)).toBe(expected)
})

Both pass, and the code still charges 100 for an order of exactly 100. With the mock, the real applyDiscount never runs. Mocking a dependency, like a payment service, is a different and legitimate use (Software Engineering at Google). Copying the formula copies the bug. Google's testing blog shows the same trap in Don't Put Logic in Tests.

Researchers have measured a version of this. In a July 2026 study, 11 models in 13 model and mode setups wrote tests for 318 Java methods behind 233 real bugs. Averaged across those setups, 3.84% of the tests written from the buggy code passed on the bug and failed on the fix. Written from the fixed code, 0.46% did (Zhao, Zhou and Cohen).

More tests don't fix it

In a study first posted in February 2026 on 500 SWE-bench Verified tasks, pushing agents to write more tests barely changed how many they solved (Chen et al.). GPT-5.2 solved 359 tasks either way, and Gemini 3 Pro Preview went from 371 to 366. Telling Kimi K2 Thinking and DeepSeek v3.2 Reasoner not to write tests moved them from 317 to 304 and from 300 to 291. None of these changes was statistically significant.

The cost depended on the model: GPT-5.2 made more API calls and used more tokens without solving more, and the two models told to skip tests used fewer (results). It's one benchmark and one agent scaffold, mini-SWE-agent, and the study didn't test TDD or the workflow below.

Red and green slices, then review

In my experience, TDD with small red and green slices, and reviewers after, works much better:

Define what done means, in a way that can fail.
Take the expected values from something the agent didn't write: the ticket, the spec, a real example.
Write one failing test (red). It has to fail because the behavior is missing.
Write only enough code to pass it (green).
Next slice. Reviewers come in after green.

For the discount, the test takes its expected value straight from the ticket:

// spec.test.ts
import { expect, it } from 'vitest'
import { applyDiscount } from './pricing'

// From the ticket: an order of exactly 100 pays 90.
it('gives 10% off an order of exactly 100', () => {
    expect(applyDiscount(100)).toBe(90)
})

Run against the agent's code, it fails red with expected 100 to be 90. Change > to >= and it goes green. The mock test still passes, because it never ran the code. The formula test now fails: it was guarding the bug. Checked with Vitest 4.1.12: save the four blocks under their file names and run npx vitest run.

Matt Pocock's /tdd skill is his version of this workflow. One slice at a time, and writing all the tests up front is an anti-pattern there. Refactoring belongs to review. That part is a choice: Kent Beck's Canon TDD lets you refactor inside each cycle, after green.

Lauren Tan (poteto), the author of pstack, builds step 1 into it. Its /figure-it-out skill asks the agent to state what done means, in a way that can fail, before it starts the run.

TDD and /figure-it-out can work magic when you understand what you are doing.

What each check covers

Even good unit tests are one row of this chart. Here's what every row covers. The When column is my rough rhythm, not a rule.

Check	When	What it covers	Source
Unit	Every edit	A small unit of behavior, run fast. The unit can be one function or a few that work together.	Fowler
Mocks	In unit tests and narrow integration tests	Stand-ins for real collaborators, like a payment service. A mock also checks how it was called.	Fowler
Smoke	Every build	Does it start, and do the critical basics work, before deeper testing?	ISTQB
Integration	Every PR	Do separately built parts work together once connected?	Fowler
Regression	Every PR	Did the change break something that used to work? Unit, integration and end-to-end tests can all do this job.	ISTQB
Review	After green	Someone other than the author reads the change: a person or a review model.	Google, GitHub
End-to-end	Before release	A whole user flow, start to finish, in production-like conditions.	ISTQB
Security	Throughout development	Whether the security controls hold. "Can someone get what isn't theirs?" is one question of many.	OWASP, framework
Mutation	Rarely	Change the code on purpose and see whether any test fails. A surviving change isn't always a real bug.	Stryker
Manual	By a human	A person uses the product and checks that it behaves as expected.	Atlassian

The maintained article, with the animated chart, source links and the last-checked date, is on argbe.tech.

AI coding security: the tunnel my agent opened without asking

Aleksandr Argunov — Wed, 21 Oct 2026 12:45:02 +0000

In October 2026, Claude Code opened a Cloudflare tunnel on my machine. The Google Slides connector couldn't import my media files, so the agent put them on a public URL and let Google fetch them from there.

It was a smart workaround, and it didn't ask for approval or warn me. The command just went by in its output, and I only caught it because I was reading along. While it ran, anyone with that link could reach those files on my machine.

That was one session, with my settings. But most people won't be reading along.

Why the agent wanted a public URL

Google's Slides API inserts an image from a URL only if the URL is publicly accessible. It fetches the image once, at insertion, and keeps its own copy. So the files only had to be public while Google fetched them.

A tunnel is a quick way to get a public URL. Cloudflare's quick tunnels give a local service a temporary address, and by default anyone with that address can reach the service until the cloudflared process stops.

The workaround wasn't the problem. Doing it without asking was. Files only my machine could read became reachable from the internet, and the only notice was a line in the output.

What to check before an agent can expose anything

Make the agent ask before anything that opens your machine. Tunnels, port forwarding, public share links and public buckets all turn something private into something reachable.
Keep exposure as short as the job. If a service needs to fetch a file once, the tunnel can close right after; stopping cloudflared ends access for everyone.
Before an agent connects your email, files or calendar to an MCP server, check who wrote the server and what it can reach. MCP's security best practices describe the authorization risks to look for.

Agents in a business workflow need the same rule: a person approves anything that matters.

Software isn't only prototyping

Prototyping slop is solved. Pieter Levels calls it "software is dead."

He's right that prototyping got cheap. But software isn't only prototyping. It takes time, effort, money and users before one approach is good enough for many people to reuse.

One developer has been publishing the Craft apps, an early-alpha suite for image editing, documents, slides and more, each written from scratch in Rust. Even one of them, PhotoCraft, stands on hundreds of open source libraries: its lockfile on 20 October listed 839 packages, counting its own crates and everything they pull in, and 803 of them came from crates.io. I don't think what a chatbot builds for you usually gets that far.

I think most people will just ask for something and let the agent in the chat handle it. Chat apps can already connect to files, email and calendars. For a lot of people the chat will be the only UI they use. They're about to own software and not know it.

Whose responsibility it is

Now picture your agent wiring your email to an MCP server some stranger wrote. A June 2026 TrendAI study found confirmed security issues in 2,259 of 9,695 MCP servers, even after setting aside the ones flagged only for missing authentication. The servers came from public MCP directories crawled between November 2025 and March 2026.

If that server leaks your inbox, that's on you. You connected it, even if the agent did it for you and you never noticed. It's the same thing as my tunnel, just with nobody reading the output.

By "on you" I mean responsibility, not legal liability: someone has to know what's connected and what it can reach. Who is liable after a leak is a legal question. It depends on contracts, jurisdiction and the facts, and I'm not answering it here.

Software isn't dying. More of it is moving to where people can't see it. And so is the responsibility for it.

A shorter version of this first appeared on LinkedIn on 2026-10-13. The maintained version, with every source and the date I last checked them, is on argbe.tech.