You published a review at /r/<slug> with three cropped screenshots, numbered pins, and typed notes. Now you want your coding agent to read it and start fixing, without you copying markdown into a chat window by hand. That is what the MCP connection does: your agent pulls the review itself and works from the same structured feedback a person would read.
Below is the exact setup for each agent, plus what tools the connection gives it. Everything here assumes a review is already published. If you have not captured one yet, start a new review first, then come back.
What MCP gives your agent
MCP (Model Context Protocol) lets an agent call a running server for data instead of guessing. The Cobalt MCP server exposes the same content that lives at /r/<slug>/markdown: each item, its comment, its pin numbers, and the cropped image. The agent reads that as plain markdown, which is the format it parses cleanly and the reason a captured still beats a video or a screen recording as input.
Concretely, once connected your agent can fetch a review by slug, list its items, and read each comment in order. No screenshot gets described to it in prose; it reads the actual notes you left. The full tool list, arguments, and the plain HTTP API alternative live on the MCP server and API reference for coding agents. Keep that tab open while you set up.
Claude Code
Claude Code registers MCP servers from the command line. Add the Cobalt server once and it stays available across sessions:
claude mcp add cobalt
Then point it at a review by giving Claude the slug: "Read the Cobalt review cobalt-abc123 and turn each item into a task." It calls the server, pulls the items, and builds the list. If you want the pattern for going from a review to an ordered set of tasks, the walkthrough on turning a captured review into a Claude Code task list shows what a good prompt looks like and where people trip up.
One habit worth forming: reference items by their pin numbers. When your comment says "pin 2 on the checkout screenshot," Claude Code knows which element you mean and edits that one, not a similar-looking sibling.
Cursor
Cursor reads MCP servers from a config file in your project or your global settings. Add an entry for Cobalt under the MCP servers block, restart Cursor, and the server shows up in the agent's tool list. The exact JSON keys and the command to run are on the developer reference page above, so copy them from there rather than typing from memory.
Once it is live, ask Cursor to read a review by slug the same way you would in Claude Code. Cursor tends to act fast, which is good until it acts on the wrong element. Feeding it a pinned, cropped still keeps it aimed at the right region. If your feedback keeps landing in the wrong place, the notes on mistakes that make feedback land badly in Cursor cover the usual causes.
Codex
Codex supports MCP servers through its config as well. Add the Cobalt server entry, reload, and confirm it appears among the available tools. The reference page lists the same server command you used for the other two agents, so the setup is identical apart from where the config lives.
After that, the workflow matches the others: give Codex a slug, let it fetch the review, and let it read every item and comment before it writes a single line. The value is that all three agents read the same artifact. You publish once and any of them can consume it.
Why publish first, then connect
The MCP server reads a published review. Publishing is what turns your captured items into the addressable /r/<slug> URL and its markdown twin. You do not need an account to publish, and an anonymous review stays live for 30 days, which is long enough for an agent to work through it. Sign in later to keep it.
Because the review is a URL, the same one feeds a human and an agent. A designer opens the public link and comments; your agent reads the markdown over MCP. Nobody re-enters anything. That single-source setup is the core idea behind an agent feedback loop, and it is why the format matters as much as the connection.
A quick check before you rely on it
Publish a small test review with two items: one screenshot with a pin, one free-floating comment. Ask your connected agent to read it and repeat back both items with their pin numbers. If it returns your exact wording and the right pin, the connection works and it is reading the real notes, not paraphrasing an image.
If the agent comes back confused or says it cannot read the screenshot, that is usually a content problem rather than a connection one. The fix for an agent that can't read your screenshot is almost always tighter cropping and a comment that names the element instead of pointing vaguely.
Set the server up once per agent. From then on the job is capture, publish, hand over the slug, and let the agent read what you actually meant.