How is agentscreenshots different from Browser MCPs (such as Playwright, Claude Chrome, agent-browser)?

Browser MCPs and browser agents are useful. AgentScreenshots is not trying to replace them. It is built for a narrower, more frequent moment in frontend work: the moment after an agent changes the UI and needs to see the rendered result before it claims the job is done.

When people compare AgentScreenshots to Browser MCPs, they usually compare the wrong layer.

A Browser MCP gives the agent a browser control surface. It can open a page, navigate, click, inspect state, and sometimes read console or network data. That is a broad capability.

AgentScreenshots gives the agent a visual checkpoint. It takes a real screenshot under explicit conditions, writes a PNG/JPEG artifact to disk, and lets the agent inspect that image inside the coding loop.

Those sound similar because both touch a browser. Operationally, they solve different jobs.

The workflow difference

Frontend implementation has a repetitive loop:

1. edit a component
2. render the page
3. look at the result
4. notice spacing, overflow, wrapping, missing assets, or state problems
5. patch the code
6. look again

Humans do this automatically. Agents often skip step 3 unless the workflow forces them to produce a visual artifact.

A Browser MCP can help here, but it is shaped around an interactive browser session. The agent may need to create or attach to a session, navigate, wait, perform browser actions, request a screenshot, then reason about whatever comes back.

AgentScreenshots compresses that loop into a command:

agentshot "http://127.0.0.1:5173" ".agents/screenshots/pricing-mobile.png" 
  --selector "section:has-text('Pricing')" 
  --viewport 390x844 
  --padding 24 
  --wait 500

The output is a normal file in the repo. The agent can inspect it, cite the path, compare it to a previous capture, and recapture after the fix.

Control surface vs artifact surface

Question	Browser MCP / browser agent	AgentScreenshots
Primary unit	Browser session	Screenshot artifact
Best for	Exploration, flows, forms, app state	Visual verification, before/after checks, responsive QA
Output	Session state, observations, screenshots	PNG/JPEG file plus JSON metadata
Mental model	“Operate this browser”	“Capture this view”
Setup in agent prompts	Teach browser tool semantics	Teach one CLI and output folder conventions
Context footprint	Can accumulate navigation, DOM, tool logs, screenshots	One scoped image per check
Repeatability	Depends on session and steps	Same command, same URL, same viewport, same selector

Neither side is universally better. The question is what the agent is trying to do.

Browser tools are excellent when the task is interactive: log in, click through a checkout, reproduce a bug, inspect console errors, or validate a multi-step journey.

AgentScreenshots is excellent when the task is visual: inspect the hero, compare a button before and after, capture a pricing table on mobile, hover a dropdown, open an accordion, dismiss a cookie banner, or show the user the artifact that proves a fix was checked.

Why “just use Playwright” is not the same answer

Playwright is a great automation library. AgentScreenshots uses Playwright under the hood because browser rendering should be boring and dependable.

But “the agent can write Playwright code” is not the same as “the agent has a clean visual-check tool.”

When an agent hand-rolls Playwright scripts for routine screenshots, it has to decide:

• where screenshots should be saved
• which viewport to use
• how to capture a selector
• how to crop a vertical slice
• how to dismiss overlays
• how to hover or click before capture
• how long to wait for lazy content
• whether to run full-page or viewport-only
• how to keep artifacts organized
• how to avoid bloating the conversation with ad hoc script output

AgentScreenshots packages those decisions into a stable CLI surface:

agentshot "<url>" ".agents/screenshots/after.png" 
  --selector ".component" 
  --padding 20 
  --viewport 1440x1000 
  --wait-until load 
  --wait 500

That matters because agents are most useful when the surrounding workflow is small and explicit. You do not want the agent to invent a screenshot harness every time it changes CSS.

Why this matters more for agents than for humans

Humans can glance at a browser and instantly notice that a headline wraps badly, a card overflows, or a modal is hidden behind a sticky header. Agents do not get that glance by default.

They can read code and infer what should happen, but frontend quality is full of things that are only obvious after rendering:

• a table that technically fits at desktop but creates horizontal scroll at 390px
• a CTA that wraps into two awkward lines
• a screenshot thumbnail that loads after scroll
• a hover menu that overlaps the nav
• a card shadow clipped by an overflow container
• a text block that is fine in English but fails when the copy changes

For agents, a screenshot is not decoration. It is a sensory input.

Browser MCPs are broad by design

Browser MCPs and browser agents are usually designed for general browser operation. That breadth is useful:

Those are real jobs. AgentScreenshots is not the right tool for all of them.

If the agent needs console logs, network traces, DOM inspection, login state, or multi-step navigation, use a Browser MCP or browser automation tool. The browser is the workspace.

If the agent needs to see the thing it just built, AgentScreenshots is usually the smaller tool. The screenshot is the workspace artifact.

AgentScreenshots is narrow by design

AgentScreenshots is intentionally opinionated around one workflow: capture rendered UI for agent review.

That is why the CLI has flags like:

--selector "section:has-text('Pricing')"
--nth 1
--padding 24
--viewport 390x844
--from 1600 --to 2400
--click-if-present "button:has-text('Reject all')"
--hover ".nav-item"
--scroll
--wait-for "#ready"
--device-scale-factor 2

These are not random screenshot options. They map to frontend review situations:

Situation	AgentScreenshots command shape
“Check only the section I edited.”	--selector with --padding
“The bug only happens on mobile.”	--viewport 390x844
“The page is huge; I only need this vertical band.”	--from and --to
“Lazy images do not load until scroll.”	--scroll --wait 1000
“The cookie banner covers the UI.”	--click-if-present
“The dropdown only exists on hover.”	--hover
“The content appears after client-side hydration.”	--wait-for
“The agent needs a sharper image to inspect.”	--device-scale-factor 2

The product is the workflow discipline around those options: capture, inspect, fix, capture again.

Artifacts change the conversation

The biggest practical difference is not technical. It is conversational.

Without a screenshot artifact, an agent’s final answer often sounds like this:

I updated the responsive layout and fixed the spacing.

With a screenshot artifact, the answer can be grounded:

I captured .agents/screenshots/pricing-mobile-after.png at 390x844 after the change. The pricing cards now stack vertically, the CTA text fits, and the table no longer overflows.

That is a different level of accountability.

The user can open the file. The agent can compare before/after. A future agent can review the artifact. The screenshot becomes part of the local work product instead of a transient browser observation.

Where AgentScreenshots fits with Browser MCPs

The most realistic setup uses both.

Use a Browser MCP for exploration and complex browser control. Use AgentScreenshots as the default visual checkpoint after frontend edits.

Example workflow:

1. Browser MCP reproduces a bug in a logged-in dashboard.
2. Agent edits the component.
3. AgentScreenshots captures the edited dashboard section at desktop and mobile widths.
4. Agent inspects the PNGs.
5. Agent fixes layout regressions.
6. AgentScreenshots captures the final before/after proof.

That combination is stronger than either tool alone.

The install prompt should be small

Another difference is how you teach agents to use the tool.

Browser environments often need more setup explanation: which server, which browser session, how to connect, what interaction tool is available, what the tool returns, and when to use it.

AgentScreenshots is easier to ignite:

The durable guidance is not a long prompt pasted everywhere. It is the agentshot instructions command. Agents can reload the current instructions when the conversation compacts or when they enter a new repo.

The decision rule

Use this rule:

There is overlap, but the default should be clear.

Browser MCPs are for browser work.

AgentScreenshots is for visual proof.

What good usage looks like

Good AgentScreenshots usage is not “take one giant full-page screenshot at the end.”

It looks like this:

mkdir -p .agents/screenshots/homepage-refresh

agentshot "http://127.0.0.1:5173" 
  ".agents/screenshots/homepage-refresh/hero-before.png" 
  --selector "section:has-text('Your agent can')" 
  --padding 24 
  --viewport 1440x1000

# edit the component

agentshot "http://127.0.0.1:5173" 
  ".agents/screenshots/homepage-refresh/hero-after.png" 
  --selector "section:has-text('Your agent can')" 
  --padding 24 
  --viewport 1440x1000

agentshot "http://127.0.0.1:5173" 
  ".agents/screenshots/homepage-refresh/mobile-after.png" 
  --viewport 390x844 
  --scroll 
  --wait 1000

The agent should inspect those images before it speaks confidently. If the image shows a problem, fix it and capture again.

Final position

AgentScreenshots is not a browser agent. It is not an MCP server. It is not a replacement for Playwright. It is a small, agent-friendly visual verification layer on top of real browser rendering.

That narrowness is the point.

When agents build interfaces, they need a cheap habit of seeing their work. Browser MCPs can help them operate the browser. AgentScreenshots helps them keep visual proof close to the code.

The best frontend agents will use both. But they should not finish visual work blind.