Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pickfix-mcp check if any PickFix batches are queued and claim the next one"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The local half of Pickfix. The Pickfix browser extension lets developers, QA and PMs pick an element on a running web app, say what is wrong (or rewrite the text in place, comment on the page, record the steps to a bug) and press Send to Claude. pickfix-mcp receives that feedback on your machine and hands it to the coding agent working on the repository, which fixes it and reports back to the extension.
Chrome: Pickfix extension ──WebSocket, 127.0.0.1──▶ pickfix-mcp ──MCP──▶ Claude Code
pick · comment · send (extension origin only) queue fixes the code
◀──────────────── Queued → Claude is fixing → Done, with a summary ─────────────────Install the extension: Pickfix on the Chrome Web Store (in review; the link works once it is published).
Install the plugin in Claude Code, in your project:
/plugin marketplace add ledutu-studio/pickfix-mcp
/plugin install pickfix@pickfixRestart Claude Code. The plugin starts one pickfix-mcp server per session.
Open the Pickfix panel on a local page in Chrome. It finds every running session by itself; there is nothing to pair. If it does not, use Connect manually.
Then pick an element, write what should change and press Send to Claude. Requires Node.js 20 or newer.
Channels are a Claude Code research preview. To have a batch pushed straight into the session, start Claude with:
claude --dangerously-load-development-channels plugin:pickfix@pickfixClaude Code shows a warning first; choose I am using this for local development. A shell alias helps: alias claudefix='claude --dangerously-load-development-channels plugin:pickfix@pickfix'.
Without the flag everything still works: run /pickfix:fix when the extension shows Queued. A hook also reminds Claude of waiting feedback when you send a prompt.
Related MCP server: web-picker
The extension looks for sessions on ports 47400–47409. When a session is not found there (all ten are taken, another program owns the range, or you started the server on a port of your own), connect to it by port:
Ask the agent for the port: run the pickfix_status tool (in Claude Code, ask "what is the Pickfix status?"). It prints Extension link: listening on ws://127.0.0.1:<port>/pickfix.
In the Pickfix panel choose Connect manually (on the No Claude Code session card, under the session list, or after Change), enter the port and press Connect. Pasting the whole ws://127.0.0.1:<port>/pickfix address works too.
The session becomes the one this site sends to, and the extension remembers the port (the last five) and looks there again on every scan, so it reconnects after the session restarts on the same port. If the connection fails, the panel says why: nothing answered on that port, the server refused the handshake, or its version does not match the extension.
PICKFIX_PORTSet PICKFIX_PORT to make the server listen on that port only, from 1024 to 65535, instead of the first free one of 47400–47409. A fixed port is handy when the default range is blocked or when you want the extension to reach a session at a port you know in advance.
PICKFIX_PORT=51234 claudeFor clients with an mcpServers JSON file, put it in env:
{
"mcpServers": {
"pickfix": { "command": "npx", "args": ["-y", "pickfix-mcp"], "env": { "PICKFIX_PORT": "51234" } }
}
}With PICKFIX_PORT the server does not fall back to another port: if the port is in use, or the value is not a valid port, pickfix_status says so and the extension link stays off until you restart the session with a free port. Give each session its own port; two sessions cannot share one. A port outside 47400–47409 is only found through Connect manually (once entered, the extension keeps scanning it).
Run the server with npx -y pickfix-mcp as a stdio MCP server. For clients that use an mcpServers JSON file (Cursor's .cursor/mcp.json, Claude Desktop):
{
"mcpServers": {
"pickfix": { "command": "npx", "args": ["-y", "pickfix-mcp"] }
}
}Codex (~/.codex/config.toml):
[mcp_servers.pickfix]
command = "npx"
args = ["-y", "pickfix-mcp"]Start the client from your project folder: the server queues feedback per repository. These clients have no channel push: ask the agent to use the fix prompt, or to call pickfix_list_batches and follow the tool descriptions.
Tool | Purpose |
| Session, repository, port (for Connect manually), batch counts |
| Queued and working batches (or by status) |
| Claims a batch and returns its items as markdown plus screenshots and reference images |
| Reports |
| Queues a JSON file exported from the extension |
A batch can be claimed by one session only, so two Claude windows on the same repository never fix the same feedback twice.
The server listens on 127.0.0.1 only, on the first free port of 47400–47409 (or on PICKFIX_PORT when set), path /pickfix. Connecting manually to a port changes nothing below: the same checks apply on every port.
Plain HTTP requests get an empty 404 with no CORS headers. The extension sends HEAD / to each port it scans and opens a WebSocket only where something answers: Chrome slows every new WebSocket down for seconds once a few dozen have failed, so the scan must not fail with sockets. Keep this answer if you change the server.
A connection must come from the Pickfix extension (Origin: chrome-extension://<Pickfix id>) to a loopback Host; web pages, other extensions and DNS-rebinding hosts are refused at the handshake. Browsers do not let a page set Origin, so this is the gate; there is no pairing step. Programs already running under your account can still connect, as they can to any local port.
Everything captured from a web page is passed to the agent as fenced, untrusted data with an instruction never to follow it.
The server has no tool that runs commands or writes files in your repository; code changes go through your agent's normal permissions.
Full privacy policy (English and Vietnamese): PRIVACY.md.
~/.pickfix/ 0700
queue/<repo-key>/<batch>/ batch.json, state.json, screenshots, reference imagesFinished batches are deleted after 7 days. Set PICKFIX_HOME to use another directory.
The extension and server speak protocol 3 over WebSocket; the batch format is pickfix.batch/2. The original contract is section 5 of docs/specs/2026-10-02-pickfix-mcp-design.md; protocol 3's additions (regions, reference images, per-item viewport) are in the extension repo's docs/specs/2026-10-06-capture-upgrades-design.md. Types and schemas ship as @pickfix/protocol (packages/protocol).
Direction | Messages |
Server → extension |
|
Extension → server |
|
pnpm install
pnpm test # unit tests
pnpm test:e2e # builds, then drives plugin/dist/server.mjs end to end
pnpm build # rebuild plugin/dist (commit the result; a test checks it is fresh)
pnpm compile # type-check
pnpm --filter @pickfix/protocol build # build the protocol package the extension links toPICKFIX_EXTENSION_IDS=<id>[,<id>] allows extra extension ids, for unpacked builds made without the Pickfix key.
Environment variable | Effect |
| Listen on this port only (1024–65535) instead of the first free one of 47400–47409; see Connect manually |
| Where the queue lives (default |
| Extra extension ids allowed to connect, comma-separated |
The extension's id is its Chrome Web Store item id, eehanlcaccamfaalnfcikkdneffjkife. EXTENSION_PUBLIC_KEY in @pickfix/protocol is that item's public key (Developer Dashboard → Package → View public key); Google holds the private key, so nothing secret lives on a developer machine.
From your machine, once main is pushed and CI passed:
pnpm release --dry-run # checks, starts nothing
pnpm release minor # patch (default) | minor | major; asks, then starts publish.yml and follows itpnpm release refuses a main whose CI did not pass (it skips [skip ci] release commits when looking), local commits that are not pushed, a release already running, a main with nothing new since the last tag, and a version npm already has. It never changes the version itself; the workflow below does. To ship this and the extension together, in the right order (this server first), run pnpm release in the pickfix repository (ledutu-studio/pickfix, the folder that holds both checkouts); its docs/release.md has the whole flow.
.github/workflows/ci.yml runs on every push to main and every pull request: type-check, unit tests (which also check that plugin/dist is fresh) and the end-to-end tests.
.github/workflows/publish.yml runs only when started by hand (pnpm release, or Actions → publish → Run workflow) from main. It bumps the version (patch by default, or minor/major) in package.json, plugin/.claude-plugin/plugin.json and src/version.ts, runs the checks, rebuilds plugin/dist, publishes to npm, then commits chore(release): <version> and tags v<version>. Do not change the version by hand.
npm accepts the upload through trusted publishing, so no npm token is stored. One-time setup on npmjs.com: pickfix-mcp → Settings → Trusted publisher → GitHub Actions, repository ledutu-studio/pickfix-mcp, workflow publish.yml.
Optional secret DISCORD_WEBHOOK_URL posts the result to Discord.
Claude Code plugin users do not wait for npm: the marketplace reads plugin/ from main.
Pickfix giúp dev frontend, QA và PM chỉ vào chỗ sai trên giao diện đang chạy, ghi cần sửa gì, rồi gửi thẳng cho Claude Code sửa trong source. pickfix-mcp là phần chạy trên máy bạn: nhận feedback từ extension qua 127.0.0.1 và chuyển cho Claude.
Cài extension: Pickfix trên Chrome Web Store (đang chờ duyệt).
Cài plugin trong Claude Code, ngay trong project của bạn:
/plugin marketplace add ledutu-studio/pickfix-mcp
/plugin install pickfix@pickfixKhởi động lại Claude Code.
Mở panel Pickfix trên trang localhost. Panel tự tìm các session đang chạy, không cần ghép nối.
Kết nối thủ công bằng port: nếu panel không tự tìm thấy phiên (extension chỉ dò các port 47400–47409), chạy tool pickfix_status trong Claude Code để xem port (dòng ws://127.0.0.1:<port>/pickfix), rồi trong panel chọn Kết nối thủ công, nhập port và bấm Kết nối. Extension nhớ port này (tối đa 5 port gần nhất) và tự kết nối lại khi phiên khởi động lại. Muốn server chạy trên một port cố định, đặt biến môi trường PICKFIX_PORT (1024–65535), ví dụ PICKFIX_PORT=51234 claude; với file cấu hình mcpServers thì thêm "env": { "PICKFIX_PORT": "51234" }. Nếu port đó đang bị dùng, server không tự chọn port khác: pickfix_status sẽ báo lỗi để bạn đổi port.
Muốn Claude tự sửa ngay khi nhận feedback, mở Claude bằng claude --dangerously-load-development-channels plugin:pickfix@pickfix. Không dùng cờ này thì gõ /pickfix:fix khi panel hiện Đang chờ. Giao diện extension có tiếng Việt và tiếng Anh, đổi trong phần cài đặt của extension.
Phát hành phiên bản mới: sau khi push lên main và CI xanh, chạy pnpm release minor (hoặc patch, major; thêm --dry-run để chỉ kiểm tra). Script kiểm tra CI, commit chưa push, rồi chạy workflow publish.yml (bump version, đẩy lên npm, tag) và theo dõi tới khi xong. Không sửa version bằng tay. Muốn phát hành cả extension, chạy pnpm release trong repo pickfix (thư mục chứa cả hai repo; MCP trước, extension sau).
Cursor, Codex và các agent khác: thêm MCP server chạy npx -y pickfix-mcp (xem cấu hình ở trên). Chính sách quyền riêng tư: PRIVACY.md.
MIT. See LICENSE.
Claim a feedback batch before changing any code for it, and receive its items: the reviewer's requests, where each element or region lives in the code, screenshots of the current state and any reference images showing the desired look. Without batchId, claims the oldest queued batch. A batch can be claimed only once across all sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| batchId | No | The batch id from the channel event or pickfix_list_batches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the exclusivity constraint ('claimed only once across all sessions') and enumerates the returned payload (reviewer requests, code locations, screenshots, reference images) despite there being no output schema. It omits auth/permission requirements and what happens if a claim fails, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose and timing, returned payload, default behavior, and the once-only constraint. The action and its precondition are front-loaded before the payload detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single optional-parameter tool with no annotations and no output schema, the description compensates well by describing the return contents and the exclusivity rule. The remaining gap is failure behavior (e.g., a batch already claimed by someone else) and any permission requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single batchId parameter, so the baseline would be 3, but the description adds real semantics beyond the schema by explaining the omitted-parameter default (claims the oldest queued batch). It does not clarify format or where ids come from beyond the schema's own note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Claim a feedback batch') plus the scope of what follows (before changing code) and what the caller receives. It does not explicitly distinguish itself from siblings like pickfix_list_batches or pickfix_status, though the 'oldest queued batch' default implies the queue semantics that separate it from listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Claim a feedback batch before changing any code for it' gives an explicit precondition for use, and 'Without batchId, claims the oldest queued batch' documents the no-argument path. It stops short of naming an alternative tool or stating when not to claim, so routing between pickfix_claim_batch and pickfix_list_batches remains partly inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a batch exported from the Pickfix extension as a JSON file to this repository's queue, then claim it with pickfix_claim_batch.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the exported .json file, absolute or relative to the repository root. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose one non-obvious behavioral trait: the import only enqueues and does not claim, so a separate claim call is required. It says nothing about permissions, duplicate/overwrite behavior, rate limits, or what happens on malformed JSON, leaving gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero waste, front-loading the mutation and then the required follow-up action. Nothing is padded or repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter import tool with no output schema, the description covers purpose and the critical two-step workflow. It omits error/edge-case behavior (invalid file, duplicate imports), which keeps it just short of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter ('path') and schema description coverage is 100%, so the schema already documents the path format (absolute or relative to repository root). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Add'), resource ('a batch exported from the Pickfix extension as a JSON file'), and destination ('this repository's queue'). It distinguishes itself from siblings by naming pickfix_claim_batch as the required follow-up, so an agent can tell import apart from claim/list/status without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the trigger (a batch exported from the Pickfix extension) and explicitly names the next step, 'claim it with pickfix_claim_batch.' It does not state when NOT to use it (e.g., re-importing an already-queued file) or any prerequisites, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the feedback batches the Pickfix extension sent for this repository. By default shows queued and working batches.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Only list batches in this state. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, so the description only needs incremental context. It delivers that by disclosing the default filter scope (queued + working), which the schema does not state and which materially affects what the agent receives.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with what is listed, then the default scope. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description ideally would describe what a returned batch looks like and whether results are paginated. It covers scope but stops short of return-shape detail; for a simple one-parameter list tool this is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single optional parameter and 100% schema description coverage, the schema already carries the meaning. The description's mention of "queued and working" usefully links to two of the enum values, but adds no syntax or edge-case detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (feedback batches sent by the Pickfix extension) scoped to this repository, which is unambiguous. It does not differentiate itself from siblings like pickfix_status or pickfix_claim_batch, which could also surface batch information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"By default shows queued and working batches" implies the common usage and hints that the status parameter narrows it, but there is no explicit when-to-use or when-not-to-use guidance relative to pickfix_status or pickfix_claim_batch. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the outcome of a batch you claimed. Always call this when you finish, including when you could only partly fix it or not at all; the reviewer sees the summary in the extension.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | Per-item outcome with a short note (at most 300 characters each). | |
| batchId | Yes | The claimed batch. | |
| outcome | Yes | done: every item handled; partial: some items; failed: none. | |
| summary | Yes | One or two sentences for the reviewer: what changed and where, or why not. At most 600 characters. | |
| changedFiles | No | Repository-relative paths of the files you changed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that reporting is mandatory on completion and that the reviewer consumes the summary in the extension, but it omits the mutation semantics (finalizing/closing the batch), whether repeated calls overwrite prior reports, and any auth or idempotency behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the action and its completion trigger front-loaded; nothing is redundant with the schema and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter reporting tool with no output schema and no annotations, the description supplies the key missing piece: when to invoke it and that the summary is user-visible. It stops short of explaining batch-state effects or how changedFiles relates to per-item outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the enum meanings for outcome, the 300-char item notes, and the 600-char summary are already documented. The description adds nothing about parameter formats or how items/changedFiles should be populated, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Report the outcome of a batch you claimed'), which is clearly distinct from the sibling read/claim tools. It does not name a sibling directly, but the purpose is unambiguous enough that an agent can select it without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Always call this when you finish, including when you could only partly fix it or not at all' gives an explicit, even mandatory, trigger condition covering the partial and failure cases. It lacks an explicit 'do not call before claiming' exclusion, but the phrase 'a batch you claimed' implies the prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show this session's Pickfix link: repository, WebSocket port (or why there is none), and how many feedback batches are in each state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes that this is a safe, non-mutating read. Beyond that, the description discloses the actual contents of the response — repository, WebSocket port (including the case where there is none), and per-state batch counts — which is meaningful behavioral detail given no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and then lists the returned fields. No filler, no restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description carries the return-value burden and largely discharges it by enumerating the fields returned. Minor gap: the set of possible batch 'states' and what a 'Pickfix link' represents are not defined, but that is not required to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies. Nothing in the description is needed to explain inputs, and it correctly implies the call is argument-free and scoped to 'this session'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Show') and resource ('this session's Pickfix link') and enumerates exactly what is surfaced: repository, WebSocket port, and feedback batch counts. It is clearly a session-summary tool, though it never names the sibling pickfix_list_batches, which reports batch data at a different granularity, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is the tool to call to inspect the current session's connection/link state. There is no explicit when-to-use guidance and no mention of when pickfix_list_batches or pickfix_report would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.0pickfix_claim_batchpickfix_importpickfix_list_batchespickfix_reportpickfix_statusScored across 5 tools
Each tool maps to a distinct step in the feedback-batch lifecycle: status (session overview), list_batches (enumerate), claim_batch (acquire), report (close out), and import (ingest external). Status and list_batches both surface batch info, but one is session/connection health while the other enumerates batches, so boundaries stay clear.
All five tools use the same pickfix_ prefix followed by a clear verb or verb_noun (status, list_batches, claim_batch, report, import). The pattern is predictable and readable throughout.
Five tools is well-scoped for a focused claim/work/report workflow, with each tool earning its place. No redundancy or filler.
The surface covers the core lifecycle: inspect session, list batches, claim, receive items, report outcome, plus importing external batches. A release/unclaim path (returning a claimed batch to the queue) is missing, which could be a dead end if a claim is abandoned, but agents can otherwise work around it.
MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
Visual feedback from your website's visitors as tasks for your coding agent.
Comment on AI-generated webpages; feedback flows back to your coding agent. Free, MIT, local-first.
Agent-ready feedback for AI-built apps — read and close UI feedback reports over MCP.
