Back to Blog
Jan 12, 2026·8 min read·By clovis

Improve your dev workflows with Screenshots + MCP

How I use the Capturl MCP Server to boost my productivity.

It’s been a few weeks since the first release of the Capturl MCP Server. If you’ve never heard of MCP, or if you’re interested in exploring how using screenshots can improve your dev workflow, read on!

What is MCP?

The Model Context Protocol (MCP) is an open standard that lets Large Language Models (LLMs) interact with external systems. Ok, that was a bit of a mouthful. Let’s look at how that’s useful with a simple example: how does ChatGPT know today’s date?

Just like this blog post, LLMs are inherently frozen in time. They don’t have access to real-time information unless it’s provided to them. In the early days, most models would either hallucinate an answer (“Today is April 6th 2024”) or just apologize. To solve this, developers started pre-pending dynamic instructions to the model. Perhaps something like:

You are a VERY SMART AI assistant. Today is Monday, January 12, 2026.

This actually works (and most model providers do this!), but it doesn’t scale to every real-time need. So, in the same way you might take out your phone to check the date, we could also tell the model: “Hey, if you need to know today’s date, call this get_date tool”. You don’t always see the internal tool calls, but models are now specifically trained to be good at generating them. Having a consistent format for “function calling” is what allows developers to write code to parse (extract) the tool calls, execute the tool and feed the result back to the model before giving you the final answer.

MCP formalizes this interaction. As a “tool provider” (an MCP server), you’re essentially telling a model “hey, here are a few tools that you can use”, and the AI agent (the MCP client) will know how to use them. Because it’s a standard, a single MCP server can work across many different AI clients like Cursor, Claude Code, or Codex.

Ok, there’s a bit more to the protocol, and maybe I’ve lost you there a little. Let’s shift gears to a concrete productivity booster: screenshots.

Screenshots as inputs to LLMs

We all know the saying “A picture is worth a thousand words”. We also know that a thousand words takes a lot of time to type out. So when’s the last time you used an image to ask an LLM something?

Most of the LLMs we interact with are now multi-modal. This means they natively understand images, just like we do. And nearly every AI application today supports this capability: a simple copy and paste will generally do.

Screenshots, on the other hand, are easier than ever to create and share (now might be a good time to mention Capturl?). So, instead of typing “The padding on the ‘Manage Subscription’ button in the workspace settings page is a bit off on mobile. Can you fix it?” why don’t you just take a screenshot, annotate it with an arrow, and tell the agent “Fix the padding”.

If you don’t do this because you don’t like having screenshots float around on your Desktop, or because you can’t easily annotate them, or because a screenshot without the source feels like dangling pointer, I encourage you to try Yet Another Screenshot Tool.

The Capturl MCP server

Capturls are basically fancy screenshots that you can share with a link. Why “fancy”? Because they contain more than just an image: they link back to a source, have optional TTLs (time-to-live), are protected by Access Control Lists (ACLs), and can be seamlessly annotated even after you’ve shared them. Most importantly, they are super easy to create. And because they can be accessed with a link, they are super easy to share.

But can you share them with an LLM in the same way you share them with a coworker?

If you just give an LLM a capturl url, it’ll naively try to fetch the contents of the web page by navigating to the URL (usually with an internal tool like “fetch_webpage”). If the capturl is public, this will work. But if it’s not (perhaps you prefer to keep all screenshots private to your workspace), it’ll see a page indicating that it needs to login in. And that’s a bit harder for an LLM to do. This is where the Capturl MCP Server comes in.

It provides a specialized tool: fetch_capturl. Unlike a generic tool like “fetch_webpage”, “fetch_capturl” is configured to use your credentials. This allows the model to fetch any capturl that you can see.

By passing the capturl URL, an AI agent can see the screenshot, the source URL the screenshot was taken from, and the arrow which conveniently points at the specific button that needs to be fixed. That’s right, it can actually see that the padding is off on mobile.

Obviously, there’s nothing preventing you from using your favorite screenshotting tool and pasting an image directly into your favorite AI agent. Unless, of course, the agent you’re using doesn’t support pasting images. I encourage you to do this, I think you’ll be amazed at how well it works!

What about image uploads?

I’ve talked a lot about fetching screenshots, but what about uploading them?

While coding IDEs like Antigravity have nice UIs to render images in their walkthroughs, CLI tools like Claude Code or Codex don’t. So, why can’t an agent include a screenshot of what they’ve done in a pull request easily?

This is where the create_capturl tool comes in. Once again, the Capturl MCP server just tells a model: “hey, if you want to upload an image, just use the create_capturl tool and it’ll give you back a URL you can use to reference the image”. Can your current AI agent do that? I didn’t think so.

I’ve found this incredibly useful for pull requests & commit messages, since it allows agents to easily attach visual proof of fixes or include before & after screenshots.

As with all capturls created in a workspace, the uploaded image will also be governed by the same access controls. This means you don’t have to worry about internal screenshots being exposed to the public.

Compounding tools

Tools are more powerful when they can be used together.

Consider the popular Github MCP server. Amongst other things, it allows an AI agent to fetch details about open issues. But it often has a blind spot: attachments. When an LLM reads a ticket with an attached screenshot, it usually just sees a filename or a private URL it can’t access. It knows there is an image, but it can’t see it.

Now, imagine you include a capturl in that ticket instead. When the agent fetches the issue, it sees the text description containing your link: “https://capturl.com/o/…”. Because the agent also has the Capturl MCP tools, it can connect the dots: it’ll fetch the capturl to get more context and fix the issue more easily.

You’ve effectively given your agent the ability to fetch images it deems relevant on demand.

Once it’s done, it can just as easily upload a screenshot of the fix and send you an update with the image attached.

This works every time your agent encounters a capturl, whether in a Github issue, a Jira ticket, a Slack message or an email.

Getting Started

Adventurous enough to try it? Head over to our MCP Documentation to get started.

Ok, this is an early release. There are a few things on the roadmap (like supporting the official MCP server spec for authentication, or having custom TTLs for agent-created capturls), but if you have ideas for new tools or general feedback, I’d love to hear from you! You can reach out at feedback@capturl.com.