QRflows

Posted on Jun 3

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

#mcp #claude #saas #cloudflare

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.