You spotted a layout bug on your dev build. The button overlaps the price on the pricing card at 1024px wide. Instead of writing a paragraph describing it to Cursor and hoping the agent pictures the right element, you can hand Cursor the actual screenshot, the pin on the button, and your comment, all in one read. No screenshot dragged into chat, no retyping. The review lives at a URL, Cursor pulls it over MCP, and the context is on screen before you write your first prompt.
Here is the full path, step by step.
Step 1: Capture the screen where the bug is
Open a new review in a browser tab. Click Capture screen. The browser asks which window or screen to share, and the current frame draws to a canvas. Pick the tab with your build in it. There is nothing to install and no extension to add, so this works the same on a locked-down work laptop as on your own machine.
Drag a rectangle around the pricing card so the crop shows the overlap and nothing else. Cropping the still is the only edit; you are not drawing arrows on it. A tight crop does more for the agent than any markup would, because it removes everything the agent does not need to look at.
Step 2: Pin the exact spot and add a comment
Drop a numbered pin on the button that overlaps the price. Then add a comment to the item. Type it, or dictate it with the browser's built-in speech recognition if you are in Chrome or Edge. Say what is wrong and what you want: "Pin 1: the Buy button sits on top of the $29 at 1024px. It should wrap below the price, not overlap it."
If you have three or four separate issues on the same screen, capture each as its own item with its own pin. Numbered pins keep the reader moving through your points in order, which matters when the agent works the list top to bottom.
Step 3: Publish and get the link
Click Publish. The review saves and gets a short public URL of the form /r/<slug>. You do not need an account to do this. An anonymous review is kept for 30 days, and if you sign in later with Google or a magic link, it becomes yours permanently.
The same review is also available as plain-text markdown at /r/<slug>/markdown. That markdown is the format Cursor reads: your crop, your pin, and your comment as structured text an agent can parse without guessing.
Step 4: Connect Cursor to Cobalt over MCP
Cursor reads the review through an MCP server rather than you pasting anything. If you have not set this up yet, the guide to connecting your coding agent over MCP walks through the config, and the MCP server and API reference has the exact endpoints. The setup for getting a review into Cursor is a one-time step; after that, every published review is reachable by its slug.
Once the server is registered, Cursor can fetch a review by its URL or slug and get back the markdown, the cropped image, and every pin and comment in order. The context for the fix is in the editor before you write a prompt.
Step 5: Ask Cursor to work the review
Now the prompt is short. You are not describing the bug, because Cursor already has it. Tell the agent to read the review and act:
Read the review at /r/pricing-card-overlap and fix each pinned item. Start with pin 1.
Because the agent has the cropped still and the pin, it edits the right element instead of hunting through your CSS for something that matches a vague description. If Cursor still struggles to see what you mean, the usual cause is a crop that includes too much or a comment that names the wrong region. The common mistakes that make feedback land badly in Cursor covers how to fix that.
Step 6: Confirm the fix against the same review
After Cursor makes its edits, capture the fixed screen the same way and publish a second review, or reopen the build and check each pin against what changed. If someone else opened the review link and left a comment on an item, you can mark it resolved from the owner view. That gives you a record of what was raised and what got handled, without a bug tracker in the middle.
Why this beats pasting a screenshot into chat
A screenshot dropped into a chat box loses the pin, loses your comment structure, and often gets compressed. When Cursor reads the review over MCP, it gets the crop plus the text that says which element you mean and what should change. That is the difference between an agent editing the right button and an agent guessing. The same review link also opens for a human teammate as a page, and exports to PDF or a Word doc, so one capture serves both the person reviewing and the agent fixing.
If your work is more design-to-implementation than one-off bug reports, the workflow that turns a design review into Cursor-ready tasks shows how to structure a whole pass so the agent gets a clean list. Either way, the capture happens in a browser tab, and it is free to use.
Set up the MCP connection once, and your next bug goes from spotted to fixed without leaving the two tabs you already have open.