Responsively: MCP clicks are trusted input events

The agent integration is described as shipped and released as a beta

The release list is the first place to look, and it changes how the rest of the README should be read.

The newest release is a version two beta from September 2026, and its title describes it as the version two rewrite with a canvas mode and the protocol integration. The release before it is a version one point eighteen from February 2026, and the one before that a version one point seventeen point one from October 2025.

So the stable line is the one point series, and its most recent cut is about seven months older than the beta. The protocol server, the canvas mode and the rewrite are all in the beta.

The README does not draw that line. The section introducing the protocol server says the application ships with a built-in server, describes eight tools, gives two configuration routes and a table of environment variables, and says nothing about which release any of it arrived in. Read on its own, the page describes a shipped feature.

That matters more than a documentation gap, because the protocol server is the part with a capability worth understanding before you install it. The rest of the application mirrors your own clicks, which is what a responsive testing tool is for. The protocol server removes the requirement that you be the one clicking, and that is a different security posture from a screenshot tool even though both are developer utilities.

So the practical instruction is to check the version you are about to install. If you want the stable line, you want one point eighteen, and the agent integration is not in it.

The click tool sends trusted input events, which is not the same as scripting a click

The tool list is eight entries long and two of them deserve to be read closely.

One reads a preview's page text and interactive elements using CSS selectors. So an agent can enumerate the interactive elements of your development page and address them by selector, which is a reasonable capability for a tool whose whole job is exercising a page.

The other is a click tool, and its description says it sends a trusted mouse event and mirrors across the previews. The typing tool is described the same way, with real keystrokes and an option to press Enter.

Trusted is the operative word. In the browser automation world it distinguishes an event the page believes came from a real user from one synthesised by script. A page that rejects untrusted events, or that does extra verification on trusted ones, behaves differently. So an agent connected to this application produces interaction with your local page that is indistinguishable from a person at the keyboard, across every device preview at once.

Combined with the navigation tool, which loads a URL into all previews and waits for the page to load, an agent can be pointed at a development server, walk a flow, and check the result. That is a genuinely useful capability for verifying a responsive layout, and it is also a capability worth scoping deliberately.

The four remaining tools are two state getters (current URL, page title, layout, zoom and active devices; and the device catalogue), one to change which devices are previewed and one to capture them.

Screenshots are JPEG at most 1000 pixels wide, which limits what an agent can verify

The screenshot tool has a stated limitation that tells you exactly how much of your layout an agent can actually see.

Screenshots capture the visible viewport and are downscaled to at most one thousand pixels wide, and the format is JPEG. Both choices are reasonable for a person glancing at three phone previews side by side, and both are lossy in ways that matter for automated checks.

Downscaling and JPEG compression can lose fine detail such as thin borders and subtle colour differences. So an agent asked to verify that a heading wraps correctly will do better than an agent asked to verify that a divider line is present, and an agent asked to compare two screenshots pixel for pixel is being handed lossy data on lossy data.

There is a positive side, which is that the limit makes the tool cheap. A screenshot of every device in the catalogue, on demand, inside an agent loop, at a bounded size, is a reasonable thing to do repeatedly. A full-resolution capture of thirty previews at every step would not be.

The design decision underneath is that the tool serves human review, where a glance is the point, and agent use inherits that compromise. If your verification needs exact rendering, this is the wrong instrument, and no configuration flag in the documentation changes the format or the width.

Two ways to connect the agent, and one of them downloads a package on first use

The protocol integration has a documented fast path and a documented fallback, and they have meaningfully different properties.

The fast path is one command that registers the server with a coding agent by naming a package to run through the on-demand runner:

claude mcp add responsively -- npx -y @responsively/mcp

The equivalent for an editor that reads a configuration file is the same package with the same auto-accept flag:

{
  "mcpServers": {
    "responsively": {"command": "npx", "args": ["-y", "@responsively/mcp"]}
  }
}

That auto-accept flag is the thing to notice. The bridge between your agent and the application is fetched at the moment the agent runs it, with prompts for permission suppressed, and it is not a version pinned in either of those snippets. Whatever that package resolves to is what sits between the agent and your browser. Pinning a version in your own agent configuration is the difference between a known bridge and a fresh one.

The fallback avoids the package entirely by speaking to the application directly. The application listens on a loopback address, on a fixed port, whenever it is running, and the documentation gives the command to register that endpoint as a plain HTTP transport. The trade is that the application must already be running, because the bridge is what normally starts it.

That last point is handled explicitly and elegantly. Connecting an agent session does not launch the application; the first tool call does, and the application then stays open and gets reused. The README also lists RESPONSIVELY_MCP_BRIDGE, a direct path to a bridge cli.js, marked as a development override.

On Linux the agent has to find the app by watching you launch it

There is a small note about Linux in the advanced configuration section, and it describes an implementation detail with real consequences.

On Linux the application ships as an AppImage. The note says to launch it once before the first agent use, and gives the reason: that is how the command line tool learns where it lives.

So the path discovery depends on you launching the AppImage once. The environment variable table confirms the shape of this: there is a variable for a custom install path, explicitly documented as the fallback when the path is auto-detected, plus one for the port and one for the bridge location.

The AppImage route is the only documented install for Linux distributions that package with the Debian tools, since the package manager list covers a macOS cask, a Windows package manager and the Windows community repository, and an RPM for RPM-based systems. So an Ubuntu user is told to download an AppImage from the releases page, which means the usual friction: mark it executable before it will run, and deal with the FUSE mount that AppImages depend on.

The RPM command is also worth a look before you copy it, because it contains square-bracket placeholders where the version number goes, in both the path and the filename. It is a template rather than a runnable line, so you substitute the version yourself or use the releases page.

None of this is difficult. All of it is the shape of a project that ships a desktop application to four package ecosystems and one file format, and the Linux path is where the seams show.

Copyleft, a loopback server, and input events are an unusual combination

Three properties of this project sit next to each other in a way worth naming, and none of them is a criticism.

The licence is the Affero copyleft, which is the strongest of the common open source licences. For an application most people download and run, that is a normal and generous choice. It becomes relevant in a specific case, which is a hosted or redistributed version of the application, and this repository also contains the browser extension and the agent bridge, so the whole product is under one licence rather than the pieces being split.

The second property is the server. The application listens on a loopback address on a fixed port whenever it is running, and it exposes a protocol interface on it. The documentation says localhost only, and the port is fixed rather than ephemeral, so it is not a port that changes under you between runs.

The third is the input capability described earlier, where clicks and keystrokes reach your page as trusted events across every preview simultaneously.

Taken together, a copyleft application that runs a local server and can be driven by another program to send trusted input to the pages you have open is a different risk profile from a screenshot utility, and the documentation is candid about all three components without drawing the connection. Whether any of it matters for your situation is a question for whoever handles licence and device policy where you work, and the honest thing to say is that the answer is not in this repository.

Three packages in one repository, and a five-times-faster claim with no evidence

Two closing observations about how the project is put together and how it is described.

The tree has three top-level packages: the desktop application, the browser extension, and the protocol bridge. They are separate build units with separate distribution channels, since the extension goes to three browser stores while the application goes to four package ecosystems, and they share one licence file and one repository. A contributor building the application also gets the extension source and the bridge, which is convenient and also means the build is larger than one product.

The toolchain around it is mixed in a way that matches that. There is a Lefthook configuration for git hooks, which is the Go-flavoured alternative to the JavaScript hook runners the extension might use, and an editor configuration directory committed at the root, which is normally excluded. There is a workspace file for a code editor, a tool version pin, and a contributors configuration for the README's contributor list. None of that is wrong. It is the residue of a project that has been maintained by individuals using different tools, which is what most real repositories look like.

The description, though. The README calls itself a must-have developer tool and then states that you will be five times faster by using it, as a heading, with nothing behind the number. The repository's own description field makes a similar claim without a figure.

It is a small thing, and the tool is one where the time saving is plausible: checking a layout across three viewport sizes by resizing one window beats doing it in three. But five times is a measurement, and the project publishes none, so the only honest reading of the heading is as an intention. Judge the tool on whether the mirrored previews and the one-click screenshots save you time, which is testable in an afternoon.

Editorial conclusion

Responsively fits a frontend developer who checks layouts across device sizes constantly and wants one window instead of a device toolbar, and the protocol server fits teams already driving a coding agent. It may not fit a reviewer who needs an audit trail of what an agent did to a page; check that before relying on it. Verify first which line you have installed, since the agent integration is in a beta and the stable release predates it by seven months, and check the MCP configuration before pointing an agent at anything that is not your own development server.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes