CodeQR

CodeQR Remote MCP Server

Remote MCP server for CodeQR with OAuth 2.0 authentication. Compatible with ChatGPT, OpenAI Agents SDK, Grok (xAI), and any MCP client supporting Streamable HTTP transport.

How It Works

┌──────────┐      ┌─────────────────────┐      ┌──────────┐
│  ChatGPT │      │  CodeQR MCP Remote  │      │ CodeQR   │
│  or any  │─────▶│                     │─────▶│ API      │
│  MCP     │◀─────│  OAuth 2.0 + MCP    │◀─────│          │
│  client  │      │  Streamable HTTP    │      │          │
└──────────┘      └─────────────────────┘      └──────────┘

1. Client discovers auth endpoints via /.well-known/oauth-protected-resource
2. Client registers dynamically via POST /oauth/register
3. GET /oauth/authorize shows this server's consent screen — the app's self-declared name, marked unverified unless its exact redirect URI is listed in src/oauth/verified-clients.ts, and the host that redirect URI points at. On approval the user goes to CodeQR, where they log in, choose which project to grant access to, and approve — no API key is ever handled. The callback only completes in the browser that approved.
4. CodeQR returns them to GET /oauth/callback, which trades the code for an access + refresh token pair
5. Client exchanges authorization code for access token (PKCE)
6. Client sends MCP tool calls with Bearer token to POST /mcp

The CodeQR access token lasts 7 days and is renewed transparently. Each renewal gives the session another 120 days, so a connection in use does not expire on a fixed date; an idle one ends 120 days after its last renewal, and none outlives one year from when it was made (the expires_in the client is given).

Quick Start

# Install dependencies
npm install

# Set environment variables
cp .env.example .env
# Edit .env with your SERVER_URL

# Development
npm run dev

# Production
npm run build
npm start

Deploy

Vercel (Recommended)

The project is configured for Vercel serverless functions:

# Install Vercel CLI
npm i -g vercel

# Deploy
vercel

# Set environment variables in Vercel dashboard:
# - SERVER_URL — Your public server URL (e.g., https://mcp.codeqr.io)
# - UPSTASH_REDIS_REST_URL — From your Upstash Redis database (REST API)
# - UPSTASH_REDIS_REST_TOKEN — From your Upstash Redis database
# - CODEQR_OAUTH_CLIENT_ID — client_id of the OAuth app registered in CodeQR
# - CODEQR_OAUTH_CLIENT_SECRET — its client_secret
# - CODEQR_APP_URL — Dashboard origin (default: https://app.codeqr.io)
# - MCP_UI_ENABLED — Set to 1 to show the item card in hosts that render MCP Apps (off when unset)
# - STAINLESS_API_KEY — Optional Stainless API key
# - LOG_LEVEL — Log level (default: info)

The app will be available at https://your-project.vercel.app. All routes are handled by the serverless function at api/server.ts.

OAuth storage: Set Upstash Redis (UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN) so authorization codes, access tokens, and registered clients persist across serverless invocations. If these variables are omitted, the server falls back to an in-memory store (fine for local development only).

Docker

docker build -t codeqr-mcp-remote .
docker run -p 3000:3000 -e SERVER_URL=https://mcp.codeqr.io codeqr-mcp-remote

Railway / Render / Fly.io

Set environment variables:

• SERVER_URL — Your public server URL (e.g., https://mcp.codeqr.io)
• UPSTASH_REDIS_REST_URL / UPSTASH_REDIS_REST_TOKEN — Recommended for multi-instance or restarts
• PORT — Port (usually set automatically by the platform)

Connect to ChatGPT

1. Deploy this server to a public URL
2. In ChatGPT, go to Settings > Advanced > Developer Mode
3. Go to the Connectors tab
4. Click Add Connector
5. Enter your server URL (e.g., https://mcp.codeqr.io/mcp)
6. ChatGPT will auto-discover the OAuth endpoints and prompt you to authorize

Connect to OpenAI Agents SDK

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-4o",
    tools=[{
        "type": "mcp",
        "server_label": "codeqr",
        "server_url": "https://mcp.codeqr.io/mcp",
        "require_approval": "never",
    }],
    input="Create a short link for https://codeqr.io",
)

Available Tools

Conversion event tools are not offered. track_lead and track_sale need the conversions.write scope, which CodeQR grants to workspace owners only, and requesting it makes CodeQR reject the whole authorization for everyone else. The per-link trackConversion toggle is a links.write field and IS exposed on create_link/update_link (plans that include conversion tracking only).

Smart rules are exposed on create_link/update_link as rules: conditional routing by any of the twelve attributes the API implements, and traffic splitting across 2-4 destinations, which is how an A/B test is expressed — one rule with no condition and a split. Where the workspace doesn't have smart rules enabled, the API rejects the whole call — the create or update fails outright, so no link or QR code is created without the rules it asked for — and the server doesn't forward that rejection as-is: it reports that smart rules aren't enabled on this workspace, with a link to details. src/plan-limit-message.ts recognizes plan wording it knows: a capability gate like this one becomes "isn't enabled on this workspace", a quota becomes "has reached its limit of N …"; anything it doesn't recognize passes through unchanged. Four of the field's invariants cannot be stated in JSON Schema (weights totalling 100, url xor split, the all-or-nothing condition, the unconditional rule coming last), so they are checked in src/smart-rules.ts before the request is sent — which saves a round-trip and answers in a sentence, rather than the serialized error body the SDK surfaces.

The trap worth knowing: value is compared whole and case-insensitively against what the request carries, which for three attributes is narrower than the name suggests. device is the operating system (iOS, Android, Windows, Mac OS, Linux — never mobile), language a two-letter code, referrer a bare domain. A wrong value is not an error anywhere: the API accepts any string and the rule silently never matches.

create_qrcode/update_qrcode also take title and walletPass. title sets the QR code's display title and is printed in large type on the Google/Apple Wallet pass saved from the code (replacing "QR Code"). Within walletPass, name and logo override the workspace name and logo shown on that pass, and barcodeText sets the text shown under the QR code, e.g. a member name or card number; when it is absent, CodeQR sends no text for that line — the title is never repeated there. Custom branding is only available on plans that include it, and never during a trial: a new non-null walletPass is rejected with 403 on any other plan or during a trial, while null (clearing it) is always accepted. Outside those plans, or during a trial, a stored value is ignored when the pass is built, so passes fall back to the workspace name and logo. logo is an https URL: the API downloads it and stores its own copy, so the response returns that copy's URL, not the one sent. barcodeText is 1-40 characters after trimming. On update_qrcode, an object replaces the stored value as a whole (a field left out of it is cleared, not merged) — send name, logo and barcodeText together to keep all three; null clears the override and reverts to the workspace branding, the same way rules: null ends a running smart-rules test.

Interactive cards (MCP Apps)

With MCP_UI_ENABLED=1, hosts that render MCP Apps (ChatGPT, Claude) show a card for the QR code or short link returned by create_qrcode, update_qrcode, create_link, update_link and get_link_info: its image, short link with a copy button, whether it is dynamic, the destination and the scan or click count, plus a button to open it in the CodeQR dashboard and one that asks how many scans or clicks it had.

• The tools' _meta.ui.resourceUri points at ui://codeqr/item-card.v1.html, served through resources/read (src/widgets/). Each read is logged as mcp.resource_read.
• The result carries structuredContent (an allowlist of fields; hosts show it to the model too) and _meta["io.codeqr/card"] (image and dashboard URLs, for the card only). content is unchanged, for clients without UI.
• get_analytics gets an analytics card (ui://codeqr/analytics.v1.html): what is counted and for which period, the total, a trend line or the top five rows, and a button to open the analytics in the dashboard. Its 24h / 7d / 30d chips re-run the call from inside the card through the host (tools/call), only when the host says it can, and only with intervals every plan can read.
• The pages live in web/item-card/ and web/analytics/, with the bridge to the host in web/shared/. yarn widgets:build bundles them into src/widgets/generated/, which is committed; yarn verify fails when it is stale. To look at them in a browser, run node scripts/build-widgets.mjs --html, serve web/dev/ and open harness.html?fixture=qr&theme=dark&locale=pt-BR&width=375 or harness.html?widget=analytics&fixture=countries&interval=30d.

Unset, the tool list, the resource list and every result are what they were.

API Endpoints

Architecture

src/
├── index.ts              # Express app & server startup
├── config.ts             # Environment configuration
├── oauth/
│   ├── store.ts          # OAuth state: Upstash Redis or in-memory fallback
│   └── pkce.ts           # PKCE S256 verification
├── middleware/
│   └── auth.ts           # Bearer token validation middleware
└── routes/
    ├── well-known.ts     # OAuth discovery metadata endpoints
    ├── oauth.ts          # Authorization & token endpoints
    └── mcp.ts            # MCP tool definitions & handlers

Production Considerations

• OAuth persistence: Configure Upstash Redis (see .env.example) for serverless and multi-instance deployments. Without it, the in-memory store is used (single process only).
• Add rate limiting to the OAuth and MCP endpoints
• Add HTTPS (usually handled by your reverse proxy / platform)
• Add monitoring (the /health endpoint is ready for probes)
• Consider token rotation for long-lived sessions

Publishing to the MCP Registry

This server is listed in the official registry as io.codeqr/codeqr. The registry stores only the metadata in server.json — never the code.

Publishing is authorized by DNS: a TXT record on the apex of codeqr.io holds the public half of an Ed25519 key pair. Apex, not a selector — MCP DNS auth follows SPF-style placement, and a record under _mcp-auth. fails with a generic signature error that does not name the cause.

# 1. Bump the version in package.json, src/config.ts and server.json together.
#    `yarn test` fails if they drift — the registry refuses to republish a
#    version it already has.
#
#    Then bump it in the CodeQR app too: the Server Card at
#    app/.well-known/mcp/server-card.json/route.ts advertises this server's
#    version, and no test can reach across repos to check. It already drifted
#    once, to a release that never existed.

# 2. Authenticate with the private key (kept outside this repo).
PRIVATE_KEY="$(openssl pkey -in /path/to/codeqr-io.pem -noout -text | grep -A3 "priv:" | tail -n +2 | tr -d ' :\n')"
mcp-publisher login dns --domain codeqr.io --private-key "$PRIVATE_KEY"

# 3. Publish, then confirm the entry is live.
mcp-publisher publish
curl "https://registry.modelcontextprotocol.io/v0/servers?search=codeqr"

If the key is ever rotated, remove the old TXT record — a stale one is tried first and makes verification fail.

Directory listings

Aggregators crawl the ecosystem and list servers whether or not anyone claims them, so an unclaimed entry still exists — as a bot's guess at what this server does. Claiming replaces the guess and unlocks editing the name and description a reader sees. None of this is done by merging a file; each one is a one-time action on the aggregator's own site.

The GitHub OAuth route Glama also offers only associates repos under a personal account, which this repo is not — it belongs to the codeqr-io org. Hence the file.

License

MIT — CodeQR