MCP Servers Can Make QR Codes Now, But Most Are Permanent

Ask an AI assistant for a QR code today and you will get one in seconds. That is new. For most of 2025 you would have been handed a link to a web tool; now the assistant makes the code itself, inside the conversation, and gives you a file ready to print.

What almost nobody mentions is that the code you just received is, in the overwhelming majority of cases, permanent. Its destination is not stored anywhere you can edit. It is encoded in the pattern of black and white squares itself. Print it, and where it points is settled forever.

For plenty of uses that is completely fine. For anything that goes to a printer, it is a liability that tends to surface at the worst possible moment.

Why this suddenly matters more than it used to

The reason is the Model Context Protocol. Through 2025 and into 2026, MCP became the common way assistants reach outside their own text: instead of describing what a tool does, you connect the tool, and the assistant calls it. QR generation turned out to be one of the first things people wired up, because it is small, self-contained and immediately useful.

The result is a real shift in volume. Generating a QR code used to be a deliberate act: open a site, paste a URL, pick a size, download. Now it happens mid-sentence, often several at a time, often for things that will be printed in quantity — table cards for a restaurant, labels for a product run, posters for an event, a batch of business cards.

Speed is the point, and it is welcome. But speed removes the pause in which someone used to ask whether the destination was final.

Static and dynamic, in plain terms

A static QR code contains the destination. Scan it and the phone reads a URL, or a plain string of Wi-Fi credentials, straight out of the pattern. Nothing is fetched from a server first, which is exactly why it works offline and why it cannot be changed. The code is the address.

A dynamic QR code contains a short link instead. Scan it and the phone opens that short link, which then forwards to wherever it currently points. The pattern never changes. The destination behind it can change as often as you like, and every scan can be counted on the way through.

The distinction has nothing to do with image quality or with how the code looks, and it is invisible once printed. Two codes on the same sheet of paper can be one of each and you could not tell them apart.

Where a permanent code costs real money

The failure mode is always the same and always mundane. Something behind the code moves, and the code does not.

• A menu on a PDF. Prices change, a dish comes off, the file is replaced at a new address. Every table card in the room now points at a document that no longer exists.
• A campaign landing page. The campaign ends and the page is retired. The flyers keep circulating for months, sending people to a 404.
• A product label. The support page moves during a site migration. The labels are already on ten thousand boxes.
• A business card. You change role, company or number. The cards in other people’s wallets do not change with you.
• An event poster. The venue changes a week before. Reprinting is possible; recalling what is already on walls is not.

None of these are exotic. They are the ordinary lifecycle of anything printed, which routinely outlives the URL printed on it.

When static is the right answer

It would be dishonest to argue that dynamic codes are always better. Static codes have real advantages, and for a good share of cases they are the correct choice.

They depend on nobody’s server staying online, which matters for a code meant to last years. They involve no redirect, so nothing is logged and nothing about the scan reaches a third party — occasionally the deciding factor. And for content that has no destination at all, such as Wi-Fi credentials or a plain text note, static is the only sensible option: there is nothing to re-point.

A reasonable rule: if the code is disposable, digital, or contains the information itself, static is fine. If it is going to a printer and points at a URL, assume the URL will change before the paper does.

What to ask for instead

The practical fix is to decide which kind you want before the print run, not after. When an assistant offers you a QR code, the useful question is whether the destination is fixed in the pattern or behind a link you control.

This is why the ShareCut QR generator makes the difference explicit rather than burying it, and why our MCP server exposes two separate tools instead of one. create_qr produces a static code and says so — free, with no API key and no account. shorten_url produces a code backed by a ShareCut short link, so the destination stays editable after printing and the scans are counted.

Connecting it takes one line, and the free tool works immediately:

claude mcp add --transport http sharecut https://sharecut.site/mcp

It works with any MCP client — Claude Code, Claude Desktop, Cursor. We deliberately left QR generation outside the paywall, because a static QR code is a commodity and several good free servers already produce them. What is worth paying for is the code that still works after the thing behind it has moved, and that is the part a library running on your laptop cannot give you: it needs a link that keeps resolving.

The wider point

Assistants are getting very good at producing artifacts that leave the screen — codes, labels, documents, files that end up on paper and in the physical world. Paper does not get patched. The useful habit, as this becomes routine, is to notice which outputs are reversible and which are not, and to spend the extra thirty seconds on the ones that are not.

A QR code is a small thing. It is also a decision that lasts as long as the surface it is printed on.

Printing something soon? Create a QR code free on ShareCut, or read how editing a QR code after printing actually works. Re-pointable codes and scan analytics are part of the paid plans.