DEV Community: QRflows

Google Translate was crashing our React app — here's how we fixed "removeChild" for good

QRflows — Thu, 29 Oct 2026 15:14:40 +0000

I build QRflows, a dynamic QR code platform. Last week I was going through session recordings and found our most engaged user of the month: someone in Hong Kong who spent 11 minutes in the dashboard, clicked 82 times, tried half a dozen QR types, added a logo, built a landing page.

At minute three, the page crashed and reloaded.

The error in the console:

NotFoundError: Failed to execute 'removeChild' on 'Node':
The node to be removed is not a child of this node.

The recording made the cause obvious once I noticed it: the whole dashboard was in Chinese. Our site only exists in English. The user had Chrome's built-in Google Translate turned on.

This is one of those bugs that never shows up in your own testing, because you never translate your own app. Here's what's going on, how to reproduce it without Google Translate, and the three-layer fix we shipped.

Why Google Translate breaks React

React keeps references to the DOM nodes it created, including plain text nodes. When state changes, it updates or removes those exact nodes.

Google Translate doesn't know about React. When it translates a page, it walks the DOM and replaces text nodes with its own  elements containing the translated text:

<!-- What React rendered -->
<button>Save</button>

<!-- What the DOM looks like after Google Translate -->
<button><font><font>保存</font></font></button>

The original "Save" text node is gone from the DOM, but React still holds a reference to it. The next time React needs to remove or replace that text, it calls parent.removeChild(textNode) — and the browser throws, because that node is no longer a child of anything.

The same thing happens with insertBefore when React tries to insert something next to a node that Translate has swapped out.

It's a long-standing issue — facebook/react#11538 has been open since 2017 — and it isn't specific to React: anything that holds references to text nodes is vulnerable. If you want the deep dive, Martijn Hols' write-up is excellent.

Which code is vulnerable

The crash needs two things: a bare text node and something conditional next to it. Patterns like these:

// Text sitting next to a conditional element
<button>
  {isSaving && <Spinner />}
  Save
</button>

// Conditional text
{error && error.message}

// Ternary returning strings
<span>{isSaving ? "Saving…" : "Saved"}</span>

// Text mixed with an expression
<p>Uploaded {count} files</p>

Every QR builder has dozens of these: status labels, counters, "Uploading… / Done", plan badges. Which is why the crash hit our most active user and nobody else.

Reproducing it without Google Translate

Waiting for a translated session to show up in your logs is not a test plan. You can simulate what Translate does to the DOM in the browser console:

function fakeTranslate(root = document.body) {
  const walker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT, {
    acceptNode: (node) =>
      node.nodeValue.trim() &&
      node.parentElement &&
      !node.parentElement.closest('script, style, [translate="no"], font')
        ? NodeFilter.FILTER_ACCEPT
        : NodeFilter.FILTER_REJECT,
  });

  const nodes = [];
  while (walker.nextNode()) nodes.push(walker.currentNode);

  for (const textNode of nodes) {
    const outer = document.createElement('font');
    const inner = document.createElement('font');
    inner.textContent = '译' + textNode.nodeValue; // mark it as "translated"
    outer.appendChild(inner);
    textNode.parentNode.replaceChild(outer, textNode);
  }
  return nodes.length;
}

window.addEventListener('error', (e) => console.log('CRASH:', e.message));
fakeTranslate();

Paste it, run fakeTranslate(), then use the app: switch tabs, toggle options, type into inputs, navigate between routes. Run fakeTranslate() again after each step, because real Translate keeps re-translating new content as it appears.

On our dashboard, switching QR types after this reproduced the exact crash from the recording within a few clicks.

The fix: three layers

There's no single clean fix. What worked for us is three layers, from "never crash" to "fewer weird states".

Layer 1: a DOM guard so the crash can't happen

This is the workaround from the React issue thread: patch removeChild and insertBefore so that, instead of throwing, they skip the operation when the node relationship is no longer what React expects.

// src/lib/domTranslateGuard.ts
export function installDomTranslateGuard(): void {
  if (typeof window === 'undefined' || typeof Node !== 'function') return;

  const proto = Node.prototype as any;
  if (proto.__translateGuardInstalled) return;
  proto.__translateGuardInstalled = true;

  const originalRemoveChild = proto.removeChild;
  proto.removeChild = function (child: Node) {
    if (child.parentNode !== this) {
      console.warn('[dom-guard] removeChild skipped', child, this);
      (window as any).clarity?.('event', 'dom_guard_removeChild');
      return child;
    }
    return originalRemoveChild.call(this, child);
  };

  const originalInsertBefore = proto.insertBefore;
  proto.insertBefore = function (newNode: Node, referenceNode: Node | null) {
    if (referenceNode && referenceNode.parentNode !== this) {
      console.warn('[dom-guard] insertBefore skipped', referenceNode, this);
      (window as any).clarity?.('event', 'dom_guard_insertBefore');
      return newNode;
    }
    return originalInsertBefore.call(this, newNode, referenceNode);
  };
}

Two details that matter:

Install it before React touches the DOM. We call it as the very first thing in the client entry, before hydrateRoot:

// entry-client.tsx
import { installDomTranslateGuard } from './lib/domTranslateGuard';
installDomTranslateGuard();

// ...then hydrateRoot(...)

Keep it out of SSR. It only lives in the client entry, and the typeof window check is a second line of defence. The server never touches Node.prototype.

The trade-off is honest: this hides the error instead of fixing the cause. A skipped insertBefore can occasionally leave a piece of UI missing until the next render. That's why we log it and send a custom event to our session analytics — so we can see how often the guard actually fires, and on which pages.

Layer 2: stop giving Translate bare text nodes

The guard prevents crashes. Wrapping text in elements prevents most of the situations where it would have to step in. If text lives inside its own , Translate replaces the text inside the span, and React only ever adds or removes the span itself — which is still there.

// Before
<button>
  {isSaving && <Spinner />}
  Save
</button>

// After
<button>
  {isSaving && <Spinner />}
  <span>Save</span>
</button>

// Before
{error && error.message}

// After
{error && <span>{error.message}</span>}

// Before
<p>Uploaded {count} files</p>

// After
<p><span>Uploaded {count} files</span></p>

No visual change, no new classes. We went through every component in the QR builder, the file upload flow, the editor and the download modals, and wrapped anything that changes at runtime: status labels, counters, button text next to spinners.

Layer 3: `translate="no"` — but only where it makes sense

The tempting shortcut is <html translate="no">. Don't. Your users turned on translation because they need it — breaking the crash by breaking the translation just moves the problem.

We only opt out content that shouldn't be translated anyway:

URL, email, phone and password inputs
short links and destination URLs
the QR preview and technical labels (sizes, PNG/SVG)
the brand name in the header and footer

<input type="url" translate="no" />
<span translate="no">{shortUrl}</span>

Everything else — headings, buttons, help text — still gets translated.

How we verified it

After deploying, I ran the fake-translate script on the live site: the public PDF QR generator, then the logged-in dashboard. I switched QR types back and forth, toggled the logo option, typed into inputs, and navigated from the builder to the landing page editor and back — re-running fakeTranslate() after each step.

Result: zero uncaught errors, no reloads, and the UI kept updating live with the "translated" text in place. The brand name and URL fields stayed untouched, as intended.

We'll keep watching the dom_guard_* events in session analytics. If they show up a lot on a specific page, that page still has bare text nodes to wrap.

TL;DR

Google Translate replaces text nodes with  elements. React still holds the old nodes and crashes on removeChild / insertBefore.
You can reproduce it without Translate by wrapping text nodes in  from the console.
Layer 1: patch removeChild / insertBefore before hydration, client-only, and log when it fires.
Layer 2: wrap conditional and dynamic text in .
Layer 3: translate="no" only on inputs, URLs and brand names — never on the whole app.

The part that stuck with me: this bug hit the single most engaged user we had that month. International users who translate your app are often exactly the people working hardest to use it.

I'm building QRflows in public — dynamic QR codes with Smart Rules, real-time analytics and a Claude MCP integration. If you've hit this bug with a different framework, I'd like to hear how you handled it.

Why I added llms.txt to my SaaS — and what happened when Claude actually read it

QRflows — Tue, 18 Aug 2026 08:22:17 +0000

I build QRflows — a dynamic QR code platform. A few months ago I did two things back to back: added an MCP server so Claude can create QR codes from chat, and added an llms.txt file to the root of the site.

The MCP server got all the attention. The llms.txt file got none. But in some ways it was the more interesting decision — and the reasoning behind it taught me something about how AI systems actually navigate websites.

What llms.txt actually is

llms.txt is a plain Markdown file at the root of your domain. It tells AI systems what your site is, which pages matter, and where to find more information.

Think of it as the difference between a stranger walking into your office and reading random papers off a desk versus you handing them a one-page brief first.

Here's what ours looks like (simplified):

# QRflows

> Dynamic QR code platform with Smart Rules, real-time analytics, and Claude MCP integration.

QRflows lets you create QR codes that can be edited after printing, tracked in real time,
and routed conditionally by country, device language, or time of day.

## Core features

- [Dynamic QR codes](https://qrflows.app/dynamic-qr-codes): Edit destination URL after printing
- [Smart Rules](https://qrflows.app/qr-code-for-smart-rules): Route by country, device, language, time
- [Analytics](https://qrflows.app/qr-code-analytics): Real-time scan tracking
- [Landing pages](https://qrflows.app/qr-code-landing-pages): Branded pages without a website
- [Product QR](https://qrflows.app/product-qr): Micro-sites for physical packaging

## QR code types

- URL, WiFi, vCard, PDF, Menu, Email, WhatsApp, Telegram, Google Review, and more

## Plans

- Starter €9/mo — 2 QR codes, 20,000 scans
- Growth €19/mo — 50 QR codes, unlimited scans, landing pages, bulk creation
- Pro €39/mo — 250 QR codes, A/B testing, Smart Rules, API, Product QR

## MCP integration

Claude can create, update, and track QR codes directly from chat.
Server: https://mcp.qrflows.app/mcp
Docs: https://qrflows.app/mcp

## Optional

- [Blog](https://qrflows.app/blog): Guides and use cases
- [Developer API](https://qrflows.app/developer-api): REST API docs
- [Free QR generator](https://qrflows.app/qr-code-generator): No signup required

Note: This is our actual file — feel free to use it as a template.

Why most explanations miss the point

The standard explanation of llms.txt goes like this: AI models scrape your website, but HTML is full of noise — navigation, ads, scripts, footers. llms.txt gives them clean content.

That's true. But it's not the most interesting part.

The more interesting part is intent and priority.

When an AI model lands on your website without a guide, it has no idea which pages are canonical. Is your /features page the source of truth, or /pricing? Is your blog authoritative, or is it marketing content? Is that /docs/v1 page still current, or has it been superseded?

Without guidance, the model guesses. It often guesses wrong. It might pull your pricing from a blog post that mentions old numbers, or describe your features based on a landing page written for a different audience.

llms.txt solves this by explicitly saying: here is what this product is, here are the pages that matter, here is the hierarchy of information.

The specific reason I added it alongside MCP

Here's where it gets relevant for anyone building AI-facing tools.

We have an MCP server. When someone uses Claude to create a QR code, Claude calls our tools. But before it does, Claude forms a mental model of what QRflows is — from whatever it learned during training, or from whatever it can fetch in context.

If that mental model is wrong, the interaction goes sideways. Claude might not know that Smart Rules exist. It might not know that Product QR is Pro-only. It might describe our free generator as if it's our main product.

llms.txt is the fastest way to correct that model before any tool call happens. It's context front-loading.

The sequence we want:

User asks Claude to help with QR codes
Claude reads llms.txt → accurate understanding of the product
Claude calls MCP tools with the right context
Output is actually useful

Without step 2, step 4 is unreliable.

Who actually reads llms.txt right now

Honest answer: it's uneven.

As of mid-2026, Perplexity has confirmed support. Some versions of Claude and ChatGPT will fetch it when explicitly pointed at a domain. Cursor fetches it for library documentation. AI agents built on top of these models increasingly look for it.

But most crawlers don't proactively fetch it yet. If you publish a perfect llms.txt today, plenty of AI systems will still walk past it.

So why bother?

Two reasons.

First, adoption is accelerating. The file costs you almost nothing to publish — maybe an hour to write well. The upside is asymmetric: as more AI systems adopt the standard, every one of them gets an accurate picture of your product without you doing anything extra.

Second, it disciplines your own thinking. Writing llms.txt forced me to answer: what is QRflows, in one sentence? Which features are core versus secondary? What's the pricing in plain language? What pages actually matter?

I've written landing pages, blog posts, and product docs for QRflows. None of them forced me to answer those questions as concisely as writing 40 lines of Markdown did.

What I'd do differently

Write llms.txt before your landing page, not after.

The exercise of writing it — what is this, who is it for, what are the key pages, what's the pricing — is the same exercise as product positioning. Doing it first makes everything else easier to write.

Keep it honest about limitations.

I included the plan limits (Starter: 2 QR codes, Growth: 50) because if an AI recommends QRflows to someone who needs 100 QR codes on a €9 budget, that's a bad outcome for everyone. Accurate information beats optimistic information.

Add an llms-full.txt if you have documentation.

llms-full.txt is an optional companion — a single file that dumps all your documentation in one place. For a SaaS with deep docs, it's worth doing. For a simple product site, llms.txt alone is enough.

The file itself

Ours is live at qrflows.app/llms.txt.

If you're building a SaaS and want to add one, the format is:

# Product Name

> One sentence description.

Brief paragraph: what it is, who it's for.

## Section heading

- [Page title](url): One-line description
- [Page title](url): One-line description

## Optional (lower priority content)

- [Blog](url): ...

The > blockquote at the top is the canonical one-sentence description that AI systems extract first. Keep it sharp.

How to Submit Your MCP Server to Anthropic's Connector Directory (From Someone Who Did It)

QRflows — Wed, 03 Jun 2026 17:14:21 +0000

A practical guide based on real submission experience — what the form asks, what reviewers check, and what I got wrong the first time.

I built an MCP server for QRflows — a dynamic QR code platform. After the server was live and working, I submitted it to Anthropic's official Connector Directory. The review is ongoing, but the process taught me things I couldn't find documented anywhere in one place.

This post covers the full submission process as it stands in mid-2026: what the form actually asks, the technical requirements that can silently kill your review, and how to prepare so you don't spend a week backtracking.

Why bother with the directory at all?

When your MCP server is not in the directory, users have to:

Go to Claude Settings → Connectors
Click "Add custom connector"
Paste your server URL manually
Authenticate

That's four steps with a copy-paste. Most non-developer users won't do it.

Once your server is in the directory, users just find you in the list, click Connect, and authorize. Same OAuth flow — but the friction disappears. The directory is also how Anthropic surfaces integrations to Claude Pro and Team users who never look at developer docs.

For a SaaS product, that's a significant distribution channel.

What you can submit

The directory accepts three types:

Remote MCP server — an internet-hosted server with tools, resources, prompts
Desktop extension — local MCP server packaged as an .mcpb bundle for Claude Desktop
MCP App — an MCP server that renders interactive UI inside the chat (needs extra screenshots)

QRflows is a remote MCP server. The form and required assets differ by type, so confirm which one you're submitting before you start.

The submission form — what it actually asks

The form is at claude.com/docs/connectors/building/submission. It's not short.

Here's what each section covers so you can prepare everything before you open it:

1. Server basics — name, tagline, server URL, connector type (remote / desktop / MCP App), primary use cases in 2–3 sentences.

2. Connection details — transport protocol (must be Streamable HTTP, SSE is no longer accepted), auth type, read/write capabilities, whether your OAuth callback URL is registered.

3. Tools & resources — list every tool with a human-readable title, confirm annotations are in place, confirm read and write tools are separate, confirm tool names are ≤ 64 chars.

4. Documentation — public docs URL (a single help page or blog post is enough), minimum 3 example prompts that exercise different tools, setup and auth steps. You can share a private staging link with Anthropic during review if docs aren't public yet.

5. Privacy & compliance — privacy policy URL, data handling summary (what you collect, how long you keep it, who you share it with), confirmation of HTTPS and Origin-header validation.

6. Test account & branding — login credentials for a test account with realistic sample data, server logo (URL or SVG), favicon. For MCP Apps only: 3–5 PNG screenshots at min 1000px wide.

The technical requirements that trip people up

1. Tool annotations — the #1 reason for rejection

Every tool needs two things: a title and the right safety hint.

// Read-only tool
server.tool(
  "list_qr_codes",
  "List all QR codes in the account.",
  schema,
  handler,
  {
    title: "List QR Codes",
    readOnlyHint: true,
    destructiveHint: false,
  }
);

// Write tool
server.tool(
  "create_qr",
  "Create a new dynamic QR code.",
  schema,
  handler,
  {
    title: "Create QR Code",
    readOnlyHint: false,
    destructiveHint: false,
  }
);

// Destructive tool — be explicit
server.tool(
  "delete_qr",
  "Permanently delete a QR code.",
  schema,
  handler,
  {
    title: "Delete QR Code",
    readOnlyHint: false,
    destructiveHint: true,
  }
);

Missing annotations reportedly cause around 30% of all directory rejections. The other mistake: don't bundle read and write into one generic tool. A tool called api_request with a method parameter accepting GET, POST, PATCH, DELETE will fail review. Split them.

2. OAuth callback URL

For the browser-based Claude (claude.ai), register exactly this redirect URI:
https://claude.ai/api/mcp/auth_callback
Claude Code uses a loopback redirect on localhost with an ephemeral port. If you want to support Claude Code users, your auth server needs to accept loopback redirects with the port ignored.

PKCE with S256 is required. Your authorization server metadata should declare:

{
  "code_challenge_methods_supported": ["S256"]
}

Plain OAuth 2.0 without PKCE won't pass.

3. Origin-header validation

Your MCP server must validate the Origin header and reject requests not coming from Claude. This is a security requirement, not optional.

// Cloudflare Workers example
const origin = request.headers.get("Origin");
if (origin !== "https://claude.ai") {
  return new Response("Forbidden", { status: 403 });
}

4. Protected Resource Metadata

Claude uses this to discover your authorization server. Host it at /.well-known/oauth-protected-resource:

{
  "resource": "https://mcp.qrflows.app",
  "authorization_servers": ["https://qrflows.app"],
  "scopes_supported": ["qr:read", "qr:write"]
}

If this endpoint is missing, Claude can't complete OAuth discovery and the connector won't authenticate.

The documentation requirement

Anthropic wants docs that let a reviewer test your connector in 10 minutes without prior knowledge of your product.

The minimum:

What the connector does (2–3 sentences)
How to connect step by step
At least 3 example prompts that exercise different tools
What the expected output looks like
Privacy policy link

For QRflows I created qrflows.app/mcp as the dedicated docs page. A single well-organized page is enough.

The test account

Create a separate account — not your main production account. Load it with realistic sample data. Write down the credentials before you open the form.

For QRflows I created a test account with 6–7 QR codes of different types (URL, WiFi, vCard, Smart Rules) so reviewers could test list_qr_codes, get_qr_stats, and update_qr_url with real data.

If your tools operate on empty state, reviewers can't tell if they work or are broken.

Review timeline

Anthropic is upfront: they can't promise to review or respond to every submission individually because of volume. The typical timeline they cite is ~2 weeks, but it can run longer.

My submission has been in review for about a month. No response yet — from what I can tell that's within the normal range given submission volume right now.

While you're waiting: your server is already usable as a custom connector. Share the URL, write about it, put it in your docs. The directory listing is a distribution multiplier, not a prerequisite.

What I'd do differently

Read the submission guide before building. Once I had the full list of requirements, I realized I was missing the Protected Resource Metadata endpoint and had to add it after the fact. Twenty minutes of reading upfront would have saved two hours.

Load the test account before submitting. I initially created a test account with no data. Reviewers testing list_qr_codes would have seen an empty array with no way to tell if the tool worked.

Write docs first. The form asks for a public docs URL. If you don't have it ready, you have to pause. Write the docs page before you open the form.

Submission checklist

How I Built an MCP Server So Claude Can Create QR Codes From Chat

QRflows — Fri, 29 May 2026 21:11:00 +0000

I launched a SaaS product called QRflows — a dynamic QR code platform. Two months in, I decided to build an MCP (Model Context Protocol) server for it. Now Claude can create, update, and track QR codes directly from a chat conversation, without touching a dashboard.

This post is about why I built it, how it works technically, and what I learned along the way.

What is MCP and why did I care

MCP is Anthropic's open protocol that lets AI assistants like Claude connect to external services. Think of it like a USB standard — any MCP-compatible server can plug into Claude and give it new tools.

For QRflows, this meant Claude could become a QR code manager. A user types "create a QR code for my restaurant menu that routes to the breakfast version before 11am and the dinner version after" — and it just happens.

That's a real use case for my product's Smart Rules feature. Before MCP, the user had to go to the dashboard, create a QR, set up routing rules manually. With MCP, the whole thing is one sentence in chat.

Here's what it looks like in practice — Claude fetching stats across all QR codes for a full month:

The stack

QRflows itself runs on Laravel + React. But the MCP server is completely separate:

Runtime: Cloudflare Workers (deployed with wrangler deploy)
Language: TypeScript
MCP SDK: @modelcontextprotocol/sdk
Auth: OAuth 2.0 (required by Anthropic for remote MCP servers)
Storage: Cloudflare KV for OAuth token store

The server lives at mcp.qrflows.app and communicates via HTTP (Streamable HTTP transport).

The tools I implemented

The MCP server exposes 10 tools to Claude:

create_qr          — create a new QR code (16 types supported)
update_qr_url      — change the destination URL without reprinting
update_qr          — update any QR fields
update_wifi_qr     — update WiFi credentials
list_qr_codes      — list all QR codes in the account
get_qr             — get details for a specific QR
get_qr_stats       — get scan analytics
delete_qr          — delete a QR code
apply_smart_rules  — set geo/device/time routing rules
get_account_usage  — check plan limits and usage

Each tool has proper MCP annotations:

server.tool(
  "create_qr",
  "Create a new dynamic QR code in QRflows (16 QR types).",
  {
    name: z.string().describe("Human-readable name for the QR code"),
    qr_type: z.enum(qrTypes).default("url"),
    content: z.record(z.unknown()).describe(
      "Payload by type, e.g. url: { url }; smart_rules: { default_url, rules: [...] }"
    ),
  },
  {
    title: "Create QR Code",
    readOnlyHint: false,
    destructiveHint: false,
    idempotentHint: false,
    openWorldHint: true,
  },
  async (input) => {
    const api = new QrflowsApi(env, token);
    return toolSuccessWithUserMarkdownLeadingJson(
      await api.createQr(input)
    );
  }
);

The readOnlyHint, destructiveHint, and idempotentHint annotations are important — they tell Claude how to handle each tool safely. Read-only tools like list_qr_codes get readOnlyHint: true. The delete_qr tool gets destructiveHint: true so Claude knows to be careful.

OAuth was the hard part

Anthropic requires remote MCP servers to implement OAuth 2.0. This makes sense — you don't want Claude connecting to a QR service without the user explicitly authorizing it.

The flow looks like this:

User adds QRflows as a connector in Claude
Claude redirects to mcp.qrflows.app/auth/authorize
User logs in with their QRflows credentials
OAuth token is issued and stored in Cloudflare KV
All subsequent MCP tool calls use that token to hit the QRflows API

The trickiest part was the token refresh logic. Cloudflare Workers have no persistent state between requests, so I use KV with TTL to store tokens and refresh them automatically.

// Store in KV with expiry
await env.OAUTH_STORE.put(
  `token:${userId}`,
  JSON.stringify({ access_token, refresh_token, expires_at }),
  { expirationTtl: 3600 }
);

Smart Rules through chat

The most interesting use case is Smart Rules — QRflows' geo/device/time routing feature.

A user can tell Claude:

"Create a QR code that sends people in Spain to qrflows.app/es and everyone else to qrflows.app"

Claude translates this into a create_qr call with qr_type: "smart_rules" and the right routing config:

{
  "qr_type": "smart_rules",
  "content": {
    "default_url": "https://qrflows.app",
    "rules": [
      {
        "condition_type": "country",
        "condition_value": "ES",
        "destination_url": "https://qrflows.app/es",
        "label": "Spain"
      }
    ]
  }
}

This is where natural language + structured API really clicks. Describing routing rules in JSON is annoying. Describing them in English is natural. Claude handles the translation.

And when you ask for stats on a specific QR, Claude returns a full analytics breakdown inline:

Response format: markdown first

One thing I got wrong initially: my tools returned raw JSON. Claude would display it as a code block and the conversation felt clunky.

The fix was to make tools return a markdown block first, then the JSON for Claude's internal use, separated by a delimiter:

Here's your QR code for the restaurant menu:

![QR Code](https://qrflows.app/qr/abc123.png)

**Download:** [PNG](https://...) | [SVG](https://...)
**Destination:** https://your-menu.com
**Type:** Menu QR

---
qrflows_tool_json
{ ... raw json ... }

Claude surfaces the markdown naturally in conversation. The JSON after the delimiter is parsed by Claude if it needs to chain tool calls.

When listing all QR codes, Claude also renders a full breakdown table automatically:

How to connect it right now

The MCP server is live at https://mcp.qrflows.app/mcp.

To connect in Claude (claude.ai):

Go to Settings → Connectors
Click Add custom connector
Enter https://mcp.qrflows.app/mcp
Authorize with your QRflows account

Then try:

Create a WiFi QR code for my office. SSID: OfficeWifi, password: correct-horse-battery

Show me scan stats for all my QR codes from last week

Update the URL on my "Menu QR" to point to https://myrestaurant.com/menu-v2

Submitting to Anthropic's connector directory

I've submitted QRflows to Anthropic's official MCP connector directory. The review is ongoing — once approved, QRflows will appear in the built-in connector list inside Claude without users needing to add a custom URL.

If you're building an MCP server and wondering about the submission process: there's a Google Form linked from the Anthropic docs. The technical requirements include Streamable HTTP transport, OAuth 2.0, and proper tool annotations. The review takes a few weeks.

What I'd do differently

Start with OAuth earlier. I built all 10 tools first, then retrofitted OAuth. That was backwards. OAuth shapes your entire architecture — do it first.

Test with real Claude conversations, not just the MCP inspector. The inspector tells you if tools work. Only real conversations tell you if Claude uses them correctly. Claude sometimes misinterprets tool descriptions in ways the inspector won't catch.

Keep tool descriptions conversational. I initially wrote terse, developer-style descriptions. Claude is better at using tools described the way you'd explain them to a colleague.

From idea to indexed: how I launched a SaaS in 60 days with Laravel + React

QRflows — Sat, 23 May 2026 16:16:52 +0000

60 days from first commit to Google indexing. Here's what I built,
what stack I chose, and what actually slowed me down.

What I built

QRflows is a dynamic QR code platform. The core idea: QR codes you
can edit after printing, with real-time scan analytics, Smart Rules
routing, and landing pages — all in one dashboard.

Sounds simple. The execution was not.

Why Laravel + React

I needed something that could scale without becoming a mess at
50k users, but also ship fast enough that I'd still be alive by
launch day.

Laravel handles the backend — API, auth, queue jobs, database.
React handles the frontend — the dashboard, QR builder, analytics
views. They communicate through a clean REST API.

This separation matters. When the frontend needs to change, the
backend doesn't care. When the backend logic gets complex, the
frontend stays simple. Scalability isn't just about servers — it's
about not painting yourself into a corner architecturally.

The hardest part

Getting the UX and architecture to work together without
compromising either one.

It's easy to build something scalable that's painful to use. It's
easy to build something beautiful that falls apart under load.
Getting both right at the same time — that's where the 60 days went.

Specific example: the QR builder. It needed to feel instant and
intuitive for non-technical users, but under the hood it had to
handle 16 different QR types, each with different validation rules,
different output formats, and different downstream jobs.

The solution was a clean abstraction layer in Laravel — each QR type
is its own class with a shared interface — combined with a React
component that adapts its form fields dynamically based on the
selected type. No spaghetti. No special cases everywhere.

Analytics that actually tell you something

Most QR tools show you a scan count. That's it.

I wanted analytics that suggest what to do next — not just what
happened. So the dashboard shows engagement score, scan consistency,
peak hours, and actionable recommendations.

One feature I didn't plan but users needed

A/B testing for QR codes. One printed code, multiple destinations,
weighted traffic split.

Turned out marketing teams using physical materials needed this badly
— they couldn't run experiments without reprinting everything.

What I'd do differently

Start with fewer QR types. I launched with 16. I should have launched
with 5 and added the rest based on what users actually needed.

Premature completeness is just as dangerous as premature optimization.

Where it is now

QRflows is live at qrflows.app. Free trial,
no credit card. Still early — but indexed, shipping, and getting
first users.

If you're building something similar with Laravel + React I'm happy
to compare notes. What's your biggest architectural headache right now?

DEV Community: QRflows

Google Translate was crashing our React app — here's how we fixed "removeChild" for good

Why Google Translate breaks React

Which code is vulnerable

Reproducing it without Google Translate

The fix: three layers

Layer 1: a DOM guard so the crash can't happen

Layer 2: stop giving Translate bare text nodes

Layer 3: translate="no" — but only where it makes sense

How we verified it

TL;DR

Why I added llms.txt to my SaaS — and what happened when Claude actually read it

What llms.txt actually is

Why most explanations miss the point

The specific reason I added it alongside MCP

Who actually reads llms.txt right now

What I'd do differently

The file itself

Links

How to Submit Your MCP Server to Anthropic's Connector Directory (From Someone Who Did It)

Why bother with the directory at all?

What you can submit

The submission form — what it actually asks

The technical requirements that trip people up

1. Tool annotations — the #1 reason for rejection

2. OAuth callback URL

3. Origin-header validation

4. Protected Resource Metadata

The documentation requirement

The test account

Review timeline

What I'd do differently

Submission checklist

Links

How I Built an MCP Server So Claude Can Create QR Codes From Chat

What is MCP and why did I care

The stack

The tools I implemented

OAuth was the hard part

Smart Rules through chat

Response format: markdown first

How to connect it right now

Submitting to Anthropic's connector directory

What I'd do differently

Links

From idea to indexed: how I launched a SaaS in 60 days with Laravel + React

What I built

Why Laravel + React

The hardest part

Analytics that actually tell you something

One feature I didn't plan but users needed

What I'd do differently

Where it is now

Layer 3: `translate="no"` — but only where it makes sense