DEV Community: Alex @Bickov

I built an MCP connector for my own app. It found two bugs that had been sitting in production

Alex @Bickov — Fri, 31 Jul 2026 08:10:05 +0000

SlimSnap is a screenshot tool for Mac and Windows. Scroll capture, annotation, and it turns a capture into structured JSON instead of a flat image. Last week I shipped an MCP connector for it, a small local server so Claude Code, Claude Desktop, and Cursor can read a capture directly instead of you pasting an image into the chat.

Building the connector meant actually measuring SlimSnap's own output for the first time in months. That's when I found the two bugs below. Neither came from a bug report. Both were sitting in production since launch.

Bug one: measuring distance to the wrong point

SlimSnap links an annotation arrow to the element it's pointing at, so an agent gets "this arrow points at the Continue button" instead of just a pair of coordinates. The first real capture I ran through the connector had an arrow resting on a "Continue with phone" button. It linked to a heading above the button instead.

The code measured distance from the arrow to each element's center. A short heading close to the arrow can have a center nearer than a wide button's center, even when the arrow tip is sitting right on the button's edge. On a real 1030x1348 capture: center distance gave the heading 192px and the button 251px, heading wins. Edge distance gave the button 74px and the heading 141px, button wins, correctly.

Fix was switching from center distance to distance-to-rectangle. Three lines of logic, months in production before the connector surfaced it because nobody had looked this closely at the linking before.

Bug two: 19 characters to say 5

Coordinates were exported as 64-bit floats when 32-bit was always enough. So a value that should read 0.048 got written as 0.04800000041723251. Same number, one a human would never type and a model has to parse anyway.

It's not just noise. Every element in every capture carries 3-4 coordinates. On a busy page with 100+ elements that's hundreds of these strings, each one about 4x longer than it needs to be, in every JSON export since the format shipped. Fixed in 0.5.1 by exporting at the precision the data actually needs.

Neither bug was found by a user complaining. Both were found by pointing my own tool at my own output and actually reading what came back.

What the connector is for, and what it isn't

The reason JSON instead of an image matters comes down to how vision models handle a screenshot. They cap the long edge at 1568px. A 2540x18410 scrolling capture arrives at the model as 216x1568, about 8.5% of its original size, and 16px body text renders under 2px tall. Unreadable, not just compressed.

For a single screen that isn't hitting that cap, JSON is a real win. One capture of an X login screen came out to 377 tokens as JSON versus 1,813 tokens as an image of the same screen, already under the 1568px limit and not even downscaled. About 4.8x smaller, and the text in it is exact, not OCR guesswork off a compressed image.

For a tall page it's more honest than that. A full 18,410px scroll capture came out to 11,372 tokens as JSON versus 448 tokens for the same page as a downscaled image. The image is cheaper. It's also close to unreadable at that size. So the real trade is token cost against whether the model can actually read what you sent it, not JSON being universally cheaper, because on a tall page it isn't.

The connector has four tools: get the latest capture, list recent captures, get a specific one, and an opt-in image tool that returns the same 1568px-capped PNG if you want it anyway. Works in Claude Code, Claude Desktop, and Cursor. Doesn't work in Codex right now, its tool result cap is 10KB and it drops images entirely once a response has structured output alongside them, that's an open bug upstream, not something I can fix from SlimSnap's side.

Install:

claude mcp add slimsnap -- npx -y @slimsnap/mcp

Or grab the desktop bundle from the GitHub release if you're on Claude Desktop or Cursor. One thing worth knowing before you install: Claude Code gates MCP tools per tool and per directory, so the first few captures trigger a permission prompt each. There's a user-wide allow list in the README if that gets old fast.

Repo and docs: slimsnap.ai/connector

I measured what Claude does to a long screenshot

Alex @Bickov — Mon, 13 Jul 2026 07:38:05 +0000

I captured a full page on a retina display. The file was 3066 x 28800 pixels.

I pasted it into Claude and asked what it received.

276 x 2600.

Not cropped. Squeezed. Same 1:9.4 shape, 11 times smaller on both axes. About 99% of the pixels never reached the model.

Why it happens

Claude's vision docs recommend 1568px on the long edge, and 2000 to 2500px for dense text. Images over 8000x8000 are rejected outright.

The resize preserves aspect ratio. That is the part that gets people. On a normal screenshot, shrinking the long edge is harmless. On a very tall one, the long edge is the height, so pulling the height down drags the width with it. My page was 9.4 times taller than it was wide, so the width had nowhere to go.

What that does to text

Body text at 14pt on a retina display is about 28 pixels tall in the file.

After an 11x reduction, it is under 3 pixels.

That is not small text. That is no text. The model gets a gray column with colored stripes and is still expected to answer your question, so it does what anyone would do with no information. It guesses, confidently.

This is also why the answer feels vague and you cannot tell why.

It is not only Claude

The dimension limit shows up as real bugs. There are open issues on claude-code where a single oversized image hard-errors the request instead of auto-resizing, and one where an oversized image in a resumed session poisons every following turn with no way back.

Every tool that takes image input has a budget. Tall screenshots lose their text in all of them.

What to send instead

Two things, and neither is clever.

Cut the capture into frames. Each frame small enough to survive the resize. The model reads each one at real size instead of reading one smear.

Send the text separately, as JSON. Every element, its content, its position. JSON has no height limit. A 28,000 pixel page arrives whole, in order, and costs a few hundred tokens instead of a few thousand.

The image is still there when the model needs to see layout. The text is there when it needs to read. You stop asking one tall PNG to do both jobs.

I build SlimSnap, a free Mac screenshot tool that does both: scroll capture splits into readable frames, and one JSON covers the whole page. The schema is MIT.

Go measure yours

Take a long screenshot. Paste it into whatever you use. Ask it what dimensions it received.

I want to build the table. If you have numbers for Figma, ChatGPT or Cursor, post them below.

AI was supposed to kill WordPress. The trend line disagrees

Alex @Bickov — Tue, 07 Jul 2026 16:43:04 +0000

Google Trends for WordPress, worldwide, 2004 to today. The shape is familiar: peak in 2014, a decade of decline, a flat floor from 2021. Then 2026, and the line climbs back to levels last seen around 2017.

That was not the script. AI site builders, vibe coding tools, agents that generate a whole site from one prompt. WordPress was supposed to be the first casualty. It still runs around 43 percent of the web, and this year more people are searching for it, not fewer.

Two things I think are going on.

First, AI creates users for old tools faster than it replaces them. Millions of people who never called themselves technical are shipping things now. When they need a real site with hosting and a domain and a contact form, they don't reach for the newest tool. They reach for the one with 20 years of tutorials, because that's what the search results and the chatbots both point them to.

Second, and this is the part that should interest tool builders: LLMs are best at whatever they saw most in training. There is more written about WordPress than about any publishing tool in history. Ask an agent to fix your WordPress site and it performs like a senior. Ask it about a tool launched last year and it guesses. The most documented platform gets the biggest AI boost. Incumbents with deep ecosystems may come out of this wave stronger, not weaker.

If that holds, the moat in the AI era is not features. It is how much text about your tool exists for the next model to read.

Curious where this shows up in your stack. Which old tool got better for you since agents arrived?

I gave my agent a skill so it stops asking where my files are

Alex @Bickov — Tue, 07 Jul 2026 07:24:03 +0000

Claude Code skills are easy to write. The hard part nobody documents: how does the skill know where your app's files live on someone else's machine?

I hit this building a skill for my Mac screenshot app. The skill needs to read the latest capture. On my machine that folder is one path. On yours it's wherever you set it in preferences. Hardcode it and the skill breaks for everyone but me.

Here is the pattern that fixed it, in three parts.

What a skill is, in one paragraph

A skill is a small markdown file in ~/.claude/skills/. It tells Claude how to handle a class of requests. When your prompt matches, Claude reads the instructions and follows them, so you stop re-explaining the rules every session. Mine is a single SKILL.md, about 80 lines. You can read the whole thing in a minute: bickov/slimsnap-skill.

The discovery problem

Integrations between a desktop app and a terminal agent usually fail one of two ways. You hardcode a path, and it breaks the moment the user moves the folder. Or you push config into the agent side, and every install becomes a manual setup step.

The fix is a config file at a known location that the app owns:

~/.slimsnap/config.json

The app writes its save folder there on every launch. The skill reads it on every invocation. Change the folder in the app's preferences and the skill picks it up on the next capture. Nothing to update on the agent side.

Cursor does the same shape with workspace settings. Raycast extensions do it with preferences. It's rare in the app-plus-agent space mostly because apps don't think about agent integration yet.

What the skill does with it

Three steps on every invocation:

Read ~/.slimsnap/config.json to find the captures folder
Pull the newest capture and parse it. The file is structured JSON, bounding boxes and OCR text and annotations, so Claude reads it directly instead of burning tokens re-interpreting an image
Treat the user's callout text as the intent. If the arrow points at a gray button and the note says "match the brand blue," that text becomes the instruction. No guessing

The capture format is open, MIT licensed: bickov/slimsnap-schema. If you want a skill for Aider or Codex CLI that consumes the same files, nothing is in your way.

Trigger phrasing, the part I got wrong first

[Alex writes this section: 3 or 4 sentences on what description phrasing failed to trigger the skill and what finally worked]

Try the pattern

If you're building any tool that an agent should act on: pick a config path under the user's home folder, have the app own it and write it on launch, have the skill read it fresh every time. That's the whole trick.

The working example end to end: SlimSnap (free Mac app) plus the skill:

git clone https://github.com/bickov/slimsnap-skill ~/.claude/skills/slimsnap

Capture something broken, drag an arrow at it, type what you want changed, then in Claude Code: fix this from my screenshot.

Longer write-up of why the handoff is JSON and what's in the format: on my blog.

Do programmers even feel like programmers anymore?

Alex @Bickov — Thu, 02 Jul 2026 07:19:22 +0000

Saw a post from an 8-year dev this week. He said any junior with an agent now matches his output, and he feels no pride left in it. It got huge, because a lot of people quietly feel the same.

I read it from the other side. I'm a designer, not an engineer. For years "can you build this" meant "find someone technical and pray they stay interested." Usually they didn't. AI took the thing that hurt that dev and handed it to me.

Same shift. Loss from one seat, freedom from another.

I'm shipping a Mac app solo right now, as someone who can't write a backend from scratch. Two years ago that was a joke.

So I'm curious about the makers here. If you build for a living, does it still feel like your craft, or like something else now? Loss or relief?

The longest prompt you'll ever write is a screenshot

Alex @Bickov — Mon, 29 Jun 2026 06:49:14 +0000

I pasted a screenshot into Claude Code last week and it changed the wrong button. Not a crash, not a bad idea. It just picked the wrong element on a busy screen and edited that one.

A screenshot carries a whole screen of intent. To you it is obvious which thing you meant. To the agent it is a flat image it re-reads every turn, and on a dense UI it guesses.

What fixed it for me was marking the one element and handing over a small structured reference instead of the raw image:

{
  "element": "Save button",
  "text": "Save",
  "position": { "x": 0.82, "y": 0.12 },
  "intent": "keep it disabled until the form is valid"
}

That JSON is about 700 tokens. The raw screenshot is around 1,500 on Sonnet and Haiku, up to 4,784 on Opus, and it gets billed again on every turn.

So the screenshot is the longest prompt you will ever write. The same screenshot, marked and structured, is one of the shortest.

I built a small free Mac tool around this idea (SlimSnap). The tool is not the point though. The point is the agent should not have to guess which element you meant. Mark it, and the guessing goes away.

Your AI agent is guessing which element you meant

Alex @Bickov — Thu, 18 Jun 2026 07:48:29 +0000

Coding agents are good at execution and bad at reading a flat image. Give one a screenshot of a busy UI and it has to infer, from pixels alone, which of six similar buttons you were pointing at. Half the time it picks wrong, you re-prompt, and you have burned a round trip plus a few thousand tokens on the image.

I started handing the agent a structured capture instead. Same screenshot, but the element I care about and what I want done with it are explicit:

json{
  "target": { "label": "Save draft", "region": [820, 140, 96, 32] },
  "intent": "disable until the form is valid",
  "note": "this is the secondary button, not the primary Save"
}

The agent no longer guesses. It acts on the element I named. And the payload is roughly 700 tokens versus the several thousand a raw screenshot costs, so longer sessions stay inside context.

Structure beats pixels when the next reader is a machine. The picture carries everything at once and signals nothing. A few fields carry the one thing that matters.

Curious whether anyone here has hit the same wall feeding screenshots to agents, and what you did about it.

Flag for voice pass

"good at execution and bad at reading a flat image" is a balanced parallel, the exact anti-AI pattern. Rephrase in your voice.
"The picture carries everything at once and signals nothing" reads clever/templated. Keep only if it is genuinely how you'd say it.
The closing question is a soft generic CTA. Replace with a sharper, real question if you have one.
Tags suggestion: #claude #ai #productivity #webdev (same as last republish).
The JSON is illustrative. Match it to SlimSnap's real schema field names before posting so it is accurate.

Why I feed my coding agent JSON instead of screenshots

Alex @Bickov — Tue, 16 Jun 2026 13:00:00 +0000

Claude Code can read images. So can Cursor. So can ChatGPT. I built SlimSnap anyway, and the reason is boring: the image is the wrong shape for the job.

Here is the boring version. The job is "show the agent what is on my screen and have it act." For that job a retina screenshot pasted into a coding session is somewhere between expensive and lossy, depending on how much you care about your token budget, your context window, and the agent acting on the right thing.

The token math

A screenshot pasted to Claude as a vision input is downscaled and billed at the API's per-image cap: about 1,568 tokens on Sonnet and Haiku (the models Claude Code uses by default), up to 4,784 tokens on Opus 4.7 and 4.8. Pasted to Codex CLI (which runs on OpenAI's GPT-4o), a typical 1440x900 screenshot in high detail mode runs about 1,105 tokens. Pasted to Gemini CLI on Gemini 2.5, the same image is about 1,548 tokens. The same screen, turned into a SlimSnap JSON document, runs about 700 tokens. That JSON contains the elements, their normalized bounding boxes, their extracted colors, and the OCR text for each.

About 55 percent fewer than Sonnet or Gemini, 37 percent fewer than Codex, up to 85 percent fewer than Opus, per turn. And the only representation with structured intent the agent can act on.

Representation	Per-turn tokens
Screenshot on Opus 4.7 / 4.8 (max billed)	~4,784
Screenshot on Sonnet / Haiku (max billed)	~1,568
Screenshot on Gemini 2.5	~1,548
Screenshot on Codex CLI / GPT-4o	~1,105
Same screen as SlimSnap JSON	~700

For a one-shot question that is a curiosity. For the way I actually use a terminal coding agent, which is a long iterative session where I show it the page state every few prompts, it stops being a curiosity. Twenty turns of screenshots on Sonnet burns about 31k tokens of vision before you've said anything. Twenty turns on Codex CLI is about 22k. On Opus 4.7+ it is about 96k. Twenty turns of SlimSnap JSON is 14k. On a 200k context window, that is the difference between finishing the refactor and getting compacted out mid-session.

If you are running an agent all day, the bill matters. If you are running it on a tough refactor, the context matters more.

Structure beats pixels

The token math is the part that wins HN comments. The part that actually matters to whether the agent is helpful is structure.

When you paste a screenshot, the agent has to look at pixels and infer everything: what is a button, what is text, what color is what, what label belongs to what input, where the user is pointing. It does this every turn, because raw pixels are not persistent reasoning state. If you ask a follow-up six prompts later, the agent goes back to the pixels. (Why it sees rather than reads: Claude doesn't OCR your screenshot, it interprets it.)

When you paste structured JSON, the agent reads facts. Element e4 is a button, bbox [0.34, 0.60, 0.32, 0.07] normalized, color #3B82F6, OCR text "Sign up". The next turn it does not re-interpret pixels, it references e4. The reasoning is grounded in the same primitives the next turn will use.

json{
  "schema_version": "1.0",
  "captured_at": "2026-05-19T18:17:46Z",
  "screen": { "title": "Create your account", "app": "Safari" },
  "image": { "width_px": 1440, "height_px": 900, "file": "signup.png" },
  "elements": [
    { "id": "e1", "type": "label", "value": "Create your account",
      "bbox": [0.34, 0.18, 0.32, 0.06] },
    { "id": "e2", "type": "input", "value": "Email",
      "bbox": [0.34, 0.34, 0.32, 0.07] },
    { "id": "e3", "type": "input", "value": "Password",
      "bbox": [0.34, 0.46, 0.32, 0.07] },
    { "id": "e4", "type": "button", "value": "Sign up",
      "bbox": [0.34, 0.60, 0.32, 0.07], "color": "#3B82F6" }
  ],
  "estimated_tokens": 712
}

Annotations carry the same property. A red rectangle in a PNG is a red rectangle. A red rectangle in SlimSnap JSON has an intent field, a target_ref pointing at the element it overlaps, and an optional callout string. The agent does not have to guess which input I am pointing at. The schema says: this arrow targets e4, intent is highlight, callout is "this one is misaligned."

Pasting the image and saying "fix the misaligned input" makes the agent guess which input. Pasting the JSON makes the agent act, because the guess is already collapsed.

Why I built a skill instead of a slash command

Once the capture is structured JSON, the rest is easy. SlimSnap writes a tiny config file at ~/.slimsnap/config.json on every startup and settings change. It contains the default save folder and the filename pattern. Nothing else.

json{
  "schema_version": "1.0",
  "default_save_folder": "/Users/alex/Documents/SlimSnap",
  "filename_pattern": "{title}-{timestamp}"
}

The Claude Code skill (free, MIT, separate repo at github.com/bickov/slimsnap-skill) reads that config, lists the save folder, loads the latest JSON file, and parses it into the agent's working context. There is no upload step. There is no slash command to remember. There is no "here is a screenshot." I press the global shortcut, annotate, hit Save, type "fix this" in Claude Code, and the agent already has the structured capture loaded.

I went with a skill instead of a CLI tool or a Claude Code plugin because skills auto-trigger. The user does not invoke them, the agent does, when the prompt looks like the skill's purpose. "What's in my latest SlimSnap capture?" triggers it. So does "fix the misaligned input from my last screenshot." The skill is invisible until it is useful.

This is the part I want to be obvious to anyone building on top of Claude Code: the contract between the desktop app and the agent is the config file, not a hardcoded path. The skill discovers the save folder. If you move your captures, the skill follows. If you build a different consumer (a CLI, a VS Code extension, a different agent), it reads the same config and works.

The open schema is the actual product

SlimSnap is a Mac app and it is free at launch. The thing that will outlast the app is the schema. It is published as a separate MIT repo at github.com/bickov/slimsnap-schema. JSON Schema 2020-12, two examples, a README that explains every field.

The reason this matters: the most common reaction to a new desktop tool from a one-person shop is "what if you disappear." If the schema is open and the consumer is a skill anyone can fork, the answer is "your captures still work, your skill still works, build a different annotator if you want." The data is not locked to the app.

I am not pretending this makes SlimSnap an open-source project. The desktop app is closed. The schema and the skill are open. That is the smallest set of things I can give away and still let people invest in the workflow without trusting me forever.

What this is not

It is not a Claude Code replacement. Claude Code still reads images fine. If you paste a screenshot once for a one-off question, do that. The case for converting to JSON is the case for a workflow: you do this many times a day, you want the agent to be cheap and precise, and you want a clean handoff between the capture and the agent.

It is also not for backend-only work. If you are refactoring a Go service you do not need to show Claude Code your screen. SlimSnap is sharpest for frontend, design-to-code, and bug-reproduction work, where you constantly need to point at something visual and have the agent reason about it.

If that is your loop, the tool, the skill, and the schema are at slimsnap.ai.