Let your coding agent fix design feedback: the layernote MCP server

Design feedback has a last-mile problem. The comments live in a review tool. The fixes happen in an editor. Between the two sits a human who reads each comment, finds the element, makes the change, and walks back to mark it done. That ferrying is nobody's favorite work, and since coding agents got good, it is also unnecessary.

layernote ships an MCP server that connects your project's feedback directly to Claude Code, Cursor, or any other agent that speaks the Model Context Protocol. The short version: you type "pull the open feedback from my layernote project and fix it", and the agent does, with real context and a real check afterwards. This post explains how it works, including the parts where we deliberately do not trust the agent.

Setup is one command

In layernote, open your project settings and go to AI access. Mint a token, then:

claude mcp add layernote \
  --env LAYERNOTE_TOKEN=mcp_xxx \
  -- npx -y @layernote/mcp

For Cursor, add the same thing to .cursor/mcp.json:

{
  "mcpServers": {
    "layernote": {
      "command": "npx",
      "args": ["-y", "@layernote/mcp"],
      "env": { "LAYERNOTE_TOKEN": "mcp_xxx" }
    }
  }
}

The server runs locally over stdio and never calls a language model itself. It only supplies data and actions to the agent you already use.

A note on the tokens, because agents with write access deserve some paranoia. Each token is scoped to a single project, shown once, and stored only as a hash on our side. You can mint read-only tokens if you want an agent that can look but not touch, and revoke any token at any time. Everything an agent does is attributed to the person who minted the token, so the audit trail leads to a human.

What the agent sees

The server exposes seven tools. The two readers do the interesting work:

• list_feedback returns every open item in the project: the page URL, CSS selectors and bounding box of the element, the comment thread, and, for items layernote generated by comparing the design against the live page, a structured analysis with expected value, actual value, and a fix recommendation.
• get_feedback returns one item in full, including a screenshot of the affected element, delivered inline so the agent can actually look at what the reviewer saw.

This context is the difference between an agent that guesses and an agent that fixes. "Button color is wrong" plus a selector, a screenshot, and "expected #05131A, found #1A2B36" is a task an agent completes on the first try.

Reporting back, and why we verify

After the fix, the agent has options, and the design here is where we spent the most thought.

The obvious tool is resolve_feedback: mark the item done. It works, but it trusts the agent's own claim that the fix landed, and agents are confident creatures. So for feedback that came out of a design comparison there is a better tool: verify_feedback. When the agent calls it, layernote re-screenshots the live page, re-runs the comparison, and only resolves the item if the difference is actually gone. The agent gets one of four honest answers: resolved, still present, inconclusive, or not verifiable. An agent cannot talk its way past a screenshot.

Two more tools cover the paths teams actually hit. wont_fix_feedback closes an item as intentional, and it refuses to work without a written reason, which gets posted to the thread for the reviewer to see. Silently dropped feedback is how trust between designers and developers dies, so the tool makes silence impossible. And set_feedback_status moves items across your project's kanban columns, including custom ones, for teams that route feedback through a board instead of straight to done.

While an agent works, the annotation shows an "AI is working on this" marker on the canvas, so a designer watching the review does not wonder why items are moving on their own.

Closing the loop on deploy

The flow above still ends with a deployed fix that verification has not seen yet, because the agent ran before the deploy. For that, each project has a deploy webhook. Add it to your pipeline, and after every deployment layernote waits for the CDN to settle, then re-verifies every open comparison-generated item and auto-resolves the ones that are provably fixed. Your project settings show the result: checked, resolved, still open.

Which means the full loop looks like this. A reviewer, or the comparison, files feedback. Your agent pulls it, fixes it, and pushes. The deploy fires the webhook. layernote re-checks the live page and closes what is fixed. The items that survive are the ones that genuinely need a human, and that list is short.

The honest limits

MCP access itself is on every plan; we did not gate the core loop. The automatic verification only applies to feedback layernote generated itself through design comparison, which is a Studio and Team feature. Feedback typed by a human cannot be machine-verified, on any plan, because there is no design difference to re-check; the agent resolves those the normal way and the reviewer confirms. The server is also local-only for now: it runs on your machine next to your agent, not as a hosted endpoint.

If you already work with Claude Code or Cursor, this takes about two minutes to try: start a trial, leave yourself an annotation on your own site, and tell your agent to go fix it. Watching the item resolve itself after the deploy check does not get old.