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, Codex, 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 reports back what it changed. This post explains how it works, including the parts where we deliberately do not trust the agent.

Setup is one command

In layernote, open Settings, AI access and create 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" }
    }
  }
}

With a token the server runs locally over stdio; connected by URL it runs on layernote's side. Either way it never calls a language model itself. It only supplies data and actions to the agent you already use.

Working in Claude itself rather than a coding agent? Since October 2026 Claude connects by URL, with no token at all: see Connect Claude in the docs.

A note on the tokens, because agents with write access deserve some paranoia. A token belongs to one person and one workspace: it reaches only the projects that person reaches, it is shown once, and it is stored only as a hash on our side. You can revoke any token at any time, and workspace owners and admins can revoke their team's. Everything an agent does is attributed to the person who created the token, so the audit trail leads to a human.

What the agent sees

Two readers do most of the work:

• list_feedback returns every open item in the project: the page URL, CSS selectors and bounding box of the element, and the comment thread.
• 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 and a screenshot of that button is a task an agent completes on the first try.

Reporting back

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

The everyday tool is resolve_feedback: mark the item done. With add_feedback_comment, the agent also posts what it changed to the thread. That keeps the reviewer in charge: they read the note, check the page, and reopen the item if it is not right.

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 on a comment, it carries an "AI active" badge in the comments list, so a designer watching the review does not wonder why items are moving on their own.

The loop, today

A reviewer files feedback. Your agent pulls it, fixes it, pushes, and resolves each item with a note on what changed. The reviewer reads the note and checks the page.

The honest limits

MCP access itself is on every plan; we did not gate the core loop. layernote does not check a fix by itself: the agent resolves the item with a note on what changed, and the reviewer confirms.

If you already work with Claude Code, Cursor, or Codex, this takes about two minutes to try: start a trial, leave yourself an annotation on your own site, tell your agent to go fix it, and watch the item close with a note on what changed.