DEV Community: QRflows

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

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