In your stack
Ask Claude Code what the client wants changed, in the repo where you would fix it
Run claude mcp add --transport http writhink https://mcp.writhink.com/mcp, approve the browser prompt once, and Claude Code can read the comments your client pinned on the live page. The element, the page URL, the viewport and a screenshot come with each one. This page is the Claude Code half: the command, one full loop as it reads in the terminal, and the guardrails to set before the first reply goes out.
No credit card. Your client doesn’t need an account.
01
From nothing to connected
- Step 1
Run the command
claude mcp add --transport http writhink https://mcp.writhink.com/mcp is the whole install. Without a scope flag it applies to the project you are in, which is usually what you want: one client's feedback stays out of unrelated sessions. Add --scope user if you would rather have it everywhere.
- Step 2
Authorize once, in the browser
The first tool call opens a browser tab. Sign in with your Writhink account and approve. There is no API key to paste and nothing secret in a config file. Type /mcp in Claude Code to see the connection state or to re-authenticate later, and claude mcp remove writhink to disconnect. What the authorization actually grants is written out on /visual-feedback-for-ai-agents.
- Step 3
Confirm it is live
Ask: which Writhink projects have open feedback? You should get project names and open counts back from list_projects. If that works, every other tool works.
02
One loop, as it reads in the terminal
Shortened, but this is the shape. Nothing in it involves copying text between two windows.
- Step 1
You: what's new on the Acme review?
Claude Code calls get_feedback and comes back with the count and the grouping: six open items, four on /pricing, two on the homepage. Each one arrives with its page URL, the element the client pinned, the viewport, the device class and a screenshot URL.
- Step 2
Claude Code: the first one is on the pricing table
"The client wrote: the middle plan card looks squashed. Pinned on the featured plan card at /pricing, viewport 390 wide, device mobile, screenshot attached. Two replies on the thread, both from you, last week." You typed none of that context. The client pointed, and it was recorded then.
- Step 3
You: fix it, show me the diff
It searches the repo for the component the anchor points at, reads it, and proposes the change. This part is an ordinary Claude Code session — the MCP server never sees your code and takes no part in the edit.
- Step 4
You approve the edit
Exactly as you always do. Connecting Writhink changes what the agent knows, not how you approve what it writes.
- Step 5
You: tell them it's done and move it to in review
Two calls, reply_to_feedback and set_feedback_status, and Claude Code asks before each one because you left approval on for anything the client can see. The reply appears in the thread your client is already watching on the review link — no account, no email chain, no status update to write by hand.
- Step 6
Tomorrow: what's still open on Acme?
The same first sentence, and only the genuinely open items come back, because status is a field the agent both reads and writes. Nobody re-reads a Slack thread to work out what got done.
03
Say this, and this is what happens
Each sentence is one you would actually type, and the tool it lands on.
| What you type | Tool it calls | What comes back |
|---|---|---|
| Which projects have open feedback? | list_projects | Your projects, with how many items are still open on each. |
| What did the client ask for on the pricing page? | get_feedback | Every item with its page URL, pinned element, device, viewport, screenshot URL and thread. |
| Fix the first three, then tell them it is done. | reply_to_feedback | A public reply in the client's thread, visible on the review link. |
| Move those to in review. | set_feedback_status | The item moves between open, in progress, in review and resolved. |
| Give me the link to send the client. | get_share_link | The review link for that project. |
| Start a project for staging.acme.com. | create_project | A new project, ready to share. |
| Set up the widget on that site. | setup_widget | The embeddable feedback widget configured for the site. |
None of these read your repository, open a pull request, or touch anything outside Writhink. The complete tool reference and the authorization model are on /visual-feedback-for-ai-agents.
04
Guardrails worth setting on day one
Two of the tools talk directly to your client. Decide how you want that handled now, not after the first surprise.
- Keep approval on for anything that posts a reply. Your client reads that message and it goes out under your name.
- Keep approval on status changes too. Resolved means the client stops expecting a fix, which is a promise rather than a label.
- Let the read-only calls run unattended. Listing projects, pulling a round and fetching a share link only surface what your account can already see, and stopping to approve each one turns a two-minute triage into a clicking exercise.
- Ask for the client's exact words when a rewritten item feels off. Writhink cleans up vague comments without inventing requests, and the original text is still on the item to check.
- Scope the server per repo unless you have a reason not to. A session working on one client's site has no business reading another client's review.
- Be careful with "work through all of them". A batch pass is where six replies go out before you have read any of them, and approval prompts are the only thing standing between you and that.
05
The other route: the generated prompt
You do not have to use MCP. Writhink can read every comment on a review and produce one prompt you paste anywhere: into Claude Code, into a chat box, into a ticket. It rewrites the vague ones clearly without inventing requests, merges duplicates, groups items by page and by element, keeps the pin metadata and the screenshot URL attached to each one, and sets priorities. There is a walkthrough at /feedback-to-prompt.
Items that stay genuinely ambiguous are marked "unclear — ask the client" instead of being guessed at, and the prompt ends by asking the assistant to draft the questions you should send back. That is the part that saves the round trip, because a guessed requirement costs you a whole second review.
06
Where this does not help
If the people finding the problems are the engineers on your own team, use your issue tracker. Writhink is for the moment a non-technical person is the one looking at the page.
There is no native integration with Jira, Linear, GitHub, Slack or anything else, and nothing is created in them automatically. None of those connectors exist. You can export the feedback, or ask Claude Code to write the issue text and file it with whatever tooling it already has access to.
The proxy-based review link needs a public URL, so a dev server on localhost or a page behind your app's login is out of reach. Use the Chrome extension for those — Chrome only, no Firefox, Safari or Edge build. It runs in the browser you are already signed into, the feedback lands in the same project, and Claude Code reads it through the same tools.
Before you count on it
Writhink is in open beta: everything described here is available and free, no credit card. Paid plans are announced but not purchasable yet. The one limit that applies today is five AI prompt generations a month per organization.
FAQ
Questions people actually ask
- Does the server read my repository?
- No. It is remote and exchanges feedback data only. Claude Code reads your code on your machine as it always does. Nothing from your repo is sent to Writhink by the connection itself.
- Claude Code says it is not authenticated. What do I do?
- Type /mcp, which shows the connection state and lets you run the authorization again. Tokens expire; this is routine rather than a sign something broke. If the browser tab does not open on its own, Claude Code prints the URL for you to open. If you suspect the server instead, mcp.writhink.com/status checks its dependencies and answers in one request.
- What if the client's comment makes no sense?
- Ask for the raw text through get_feedback, then reply with a question through reply_to_feedback. Your client sees it in the same thread on the review link and answers there, with no account and no email chain. When you generate a prompt instead, ambiguous items come back flagged rather than guessed.
- Can it work through several items in one go?
- Yes, and this is where the guardrails earn their keep. It can read all the open items and work down the list, but keep approval on for replies and status changes so a batch does not send five messages to your client before you have read one of them.
- Can I use it on a site running on my machine?
- The review link needs a public URL, so localhost is not reachable through it. Use the Chrome extension on the page in your own browser. That also covers pages behind a login and staging environments, and the feedback appears in the same project for the same tools to read.
- Which other clients can connect to the same server?
- Any client that speaks remote HTTP MCP. It has been used with Claude Code, Cursor and Claude Desktop. The server does not special-case any client, so others with custom MCP connector support should behave the same way. Cursor's setup is on /for/cursor.
Start
Send one link. Get feedback you can build from.
Your clients comment right on the page — no account, no screenshots, no voice notes. Writhink sorts the comments and writes the prompt for your AI.