MCP server

Wrap Quicky.Page as a publishing tool inside any MCP-compatible AI client. Publish pages, upload images, and return one-click edit links from a single tool call.

Two ways to connect:

• Remote MCP at https://quicky.page/mcp — recommended. Speaks Streamable HTTP with OAuth 2.0 (PKCE + dynamic client registration), so it drops into any host that supports remote MCP: Claude.ai (web, Desktop, Mobile, Claude Code), ChatGPT (Developer Mode), Cursor, VS Code (GitHub Copilot Chat), Zed, and others. Sign in once and pages auto-save to your Quicky.Page account.
• Local stdio via the @quickypage/mcp-server npm package — runs as a local subprocess, no Quicky.Page sign-in, all pages anonymous (editKey returned to the agent). Use this for hosts that don't yet auto-flow OAuth for Remote MCP, or whenever you don't want an account.

Remote MCP (recommended)

The remote MCP endpoint at https://quicky.page/mcp is the account-connected surface. It implements OAuth 2.0 with PKCE (RFC 6749, RFC 7636), dynamic client registration (RFC 7591), protected-resource metadata (RFC 9728), and resource indicators (RFC 8707), so most modern MCP hosts can register themselves and kick off the sign-in flow with just the URL — no manual client ID or token paste required.

Tokens are RS256 JWTs audience-bound to https://quicky.page/mcp; they can't be reused against any other service. Revoke any time from your account settingsor from the host's connector panel.

What changes when you're signed in

• Pages published via publish_page are saved to your account immediately and show up in the History menu on quicky.page the next time you open it.
• The page's editKey is held server-side. You can call update_page with just the page id — no editKey argument required.
• rename_page_slugreads the editKey from your account too. You still need a slug entitlement (purchased through Stripe Checkout on the page's share card, or granted via an operator's premium token).

Connect from your tool

Quick reference for the most common hosts. Every entry below uses the same Remote MCP URL: https://quicky.page/mcp.

Claude.ai (web, Desktop, Mobile)

1. Open Claude.ai → Settings → Connectors → Add custom connector.
2. Paste the server URL: https://quicky.page/mcp
3. Click Connect. You'll be redirected to quicky.page to sign in (Google or magic-link email) and grant the connector permission to read, publish, and update pages on your account.
4. Return to Claude and ask: "Publish this as a Quicky.Page". The page lands in your account automatically.

The same custom connector is shared across Claude.ai web, Claude Desktop, and the Claude mobile apps — set it up once and it works everywhere.

Claude Code (CLI)

Claude Code ships with a built-in MCP manager. Add the remote server from the CLI:

claude mcp add --transport http quickypage https://quicky.page/mcp

Then run /mcp inside Claude Code and pick quickypage to start the OAuth flow. Claude Code opens your browser, you sign in to Quicky.Page, and the tools become available in the current session. Use claude mcp list to confirm the connection.

ChatGPT (Developer Mode connectors)

If you have a Pro, Plus, Business, Enterprise, or Edu account and Developer Mode is enabled for your workspace, ChatGPT can speak the full MCP protocol — including write tools like publish_page and update_page.

1. Enable Developer Mode at Settings → Apps & Connectors → Advanced settings. (Business and Enterprise admins may need to flip the workspace-level toggle first.)
2. Go to Settings → Connectors → Create.
3. Paste the MCP URL: https://quicky.page/mcp
4. Authentication: pick OAuth. ChatGPT will discover the authorization server automatically from /.well-known/oauth-protected-resource/mcp.
5. Save, then approve the connector. The five tools become callable from any conversation.

Don't have Developer Mode? Use the Custom GPT path instead — it imports our OpenAPI spec as an Action and works on any ChatGPT plan that supports Custom GPTs.

Cursor

Add to ~/.cursor/mcp.json (global) or .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "quickypage": {
      "url": "https://quicky.page/mcp"
    }
  }
}

Open Cursor and go to Settings → MCP. Cursor will spot the new server, hit it, get a 401 with our OAuth metadata, register itself via Dynamic Client Registration, and open your browser to sign in. Approve on the consent screen and the tools light up.

If Cursor doesn't open the browser automatically (a known intermittent issue), copy the authorization URL from the MCP panel logs and paste it into your browser manually.

VS Code (GitHub Copilot Chat)

VS Code supports remote MCP servers in Copilot Chat's Agent mode. Configure either per-workspace or globally.

Per workspace — create .vscode/mcp.json:

{
  "servers": {
    "quickypage": {
      "type": "http",
      "url": "https://quicky.page/mcp"
    }
  }
}

Globally — run MCP: Open User Configuration from the Command Palette (Ctrl/Cmd + Shift + P) and paste the same object.

Save the file and click the Start CodeLens that appears above the server entry. VS Code opens the OAuth flow in your browser, then exposes the tools to Copilot Chat in Agent mode. Verify with MCP: List Servers in the Command Palette.

Visual Studio (the IDE, not Code) has the same support — set the type to HTTP/SSE in the MCP configuration UI and click Auth in the CodeLens above the server.

Zed

Open the Zed settings file (cmd + , on macOS, or zed: open settings from the Command Palette) and add a context_servers entry:

{
  "context_servers": {
    "quickypage": {
      "url": "https://quicky.page/mcp"
    }
  }
}

Zed picks up the change live. The Agent Panel will show a warning indicator with an Authenticate button — click it, complete the sign-in in your browser, and Zed stores the access and refresh tokens in your system keychain.

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json (on Windows: %USERPROFILE%\.codeium\windsurf\mcp_config.json):

{
  "mcpServers": {
    "quickypage": {
      "serverUrl": "https://quicky.page/mcp"
    }
  }
}

Then fully quit and reopen Windsurf — just closing the window doesn't reload MCP servers.

Heads up:Windsurf doesn't currently auto-flow OAuth 2.0 for Remote MCP, and our remote endpoint requires a Bearer token on every request. Until that changes, the cleanest path on Windsurf is the local stdio package below — pages stay anonymous and the editKey is returned to the agent.

Cline

Open Cline's MCP settings (gear icon → MCP Servers → Edit Configuration) and add:

{
  "mcpServers": {
    "quickypage": {
      "type": "streamableHttp",
      "url": "https://quicky.page/mcp"
    }
  }
}

Heads up:Cline's Streamable HTTP support doesn't auto-flow OAuth either. If you don't have a Bearer token to paste into a headers block, switch to the local stdio package below.

Other MCP hosts

Anything that speaks Streamable HTTP MCP with the 2025-06-18 protocol revision and supports OAuth 2.0 with dynamic client registration can hit https://quicky.page/mcp directly. The server advertises everything a discovery-aware host needs:

• /.well-known/oauth-protected-resource/mcp — RFC 9728 protected-resource metadata
• /.well-known/oauth-authorization-server — RFC 8414 authorization-server metadata
• /oauth/register — RFC 7591 dynamic client registration
• /.well-known/jwks.json — JWKS for verifying access-token signatures

If your host doesn't speak OAuth 2.0 with DCR, fall back to the local stdio package— it doesn't require an account and works in any host that can spawn an MCP subprocess (Claude Desktop, Cursor, Cline, Goose, Continue.dev, custom MCP clients, etc.).

Anonymous use

The remote MCP at https://quicky.page/mcpalways requires a Bearer access token — there is no anonymous Remote MCP. If you want to publish without an account, use the local stdio package below. It runs as a subprocess on your machine, doesn't speak OAuth, and returns the editKey directly in the tool result so you (or the agent) can update the page later without signing in.

Local stdio (no account)

The MCP server is also published to npm as @quickypage/mcp-server. It runs locally over stdio and is launched by the host process with npx. No account, no OAuth — pages are anonymous and the editKey is returned to the agent.

Configure: Claude Desktop

Edit your config file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "quickypage": {
      "command": "npx",
      "args": ["-y", "@quickypage/mcp-server"]
    }
  }
}

Restart Claude Desktop. Ask: "Publish this as a Quicky.Page" — the agent will call publish_page and return a public URL plus a one-click edit link.

Configure: Cursor / Windsurf / Cline / others

The same stdio config works in any host that can spawn an MCP subprocess. Drop this into the host's MCP config file (Cursor: ~/.cursor/mcp.json, Cline: the MCP settings JSON, Windsurf: ~/.codeium/windsurf/mcp_config.json):

{
  "mcpServers": {
    "quickypage": {
      "command": "npx",
      "args": ["-y", "@quickypage/mcp-server"]
    }
  }
}

Tools

Both the remote MCP and the local stdio package expose the same five tools. Each tool carries MCP annotations (readOnlyHinton read-only tools, destructiveHint on tools whose write is a full replacement) so MCP hosts can apply correct auto-permissions.

publish_page

Publish a markdown body or qp.v1 blocks as a public web page. Returns { url, editUrl, id, slug, editKey }.

• title: optional. Becomes the leading <h1>.
• content: markdown body. Recommended for most cases.
• blocks: explicit qp.v1 array. Use when you need structural control or uploaded images.
• slug: optional premium custom URL path segment.

// Agent calls publish_page:
{
  "title": "Launch notes for v0.4",
  "content": "# What's new\n\n- Public API\n- MCP server\n- Browser extension"
}

// Returns:
{
  "url":     "https://quicky.page/abc123",
  "editUrl": "https://quicky.page/?id=abc123#edit=...",
  "id":      "abc123",
  "slug":    null,
  "editKey": "..."
}

upload_image

Upload attached or generated image bytes through Quicky.Page's signed upload API. Supports PNG, JPEG, WEBP, and GIF up to 20 MB. The returned block can be passed directly to publish_page or update_page.

The tool accepts exactly one image source: filePath, sourceUrl, or base64 data. Prefer filePath when the image already exists on the local filesystem. Use sourceUrl for hosted images, and reserve base64 data for very small images — some MCP hosts struggle with large inline tool arguments.

// 1. Agent calls upload_image with a local file path:
{
  "filePath": "C:\\Users\\Joe\\Downloads\\poster.png",
  "mimeType": "image/png",
  "alt": "Generated launch poster"
}

// Returns a ready-to-use block:
{
  "publicUrl": "https://assets.quicky.page/abc123.png",
  "block": {
    "type": "image",
    "url": "https://assets.quicky.page/abc123.png",
    "alt": "Generated launch poster"
  }
}

// 2. Agent includes that block in publish_page:
{
  "title": "Launch poster",
  "blocks": [
    { "type": "richtext", "html": "<h1>Launch poster</h1><p>Generated in Claude.</p>" },
    { "type": "image", "url": "https://assets.quicky.page/abc123.png", "alt": "Generated launch poster" }
  ]
}

Picking an image source by host

The local stdio MCP server runs as a process on the user's machine, so filePath resolves against the host filesystem — not any cloud sandbox the model itself might be running in. The Remote MCP server has no filesystem at all, so only sourceUrl and base64 data work there. The right source depends on where the image lives:

Claude Desktop sandbox trap.When a user attaches an image in the Claude Desktop chat UI, the model sees it inside Anthropic's cloud code-execution sandbox at paths like /mnt/user-data/uploads/photo.jpg. Those paths exist only inside that sandbox — the locally-running MCP server cannot read them and upload_image will fail with a file-not-found error. The original local path is stripped before the image reaches the model, so the agent cannot infer it. If you only have a sandbox path, ask the user to save the file somewhere on their machine and paste the full path back into chat.

update_page

Update a previously-published page. Same URL, replaced content. Requires the editKey returned by publish_page(or implicit when you're signed in via Remote MCP).

• id, editKey: required.
• title, content, blocks: same as publish_page.

Quicky.Page is intentionally not a CMS — there is no diff, no history, no rollback. The new content fully replaces the old. If you only want to add something — for example, prepend an image to a page that already has body content — fetch the existing blocks with get_page first and pass the reconstructed array back to update_page, otherwise everything else on the page will be wiped.

Adding an image to an existing page

The canonical three-step recipe — works for both user-supplied and AI-generated images:

// Adding an image to an existing page is three calls, in order.
// update_page does a full replace — there is no diff or merge — so you
// must read the current blocks first and pass them back unchanged.

// 1. Upload the image bytes.
upload_image({ filePath: "/Users/joe/Downloads/photo.jpg", mimeType: "image/jpeg" })
//   → { publicUrl, block: { type: "image", url, alt? } }

// 2. Fetch the current page so you don't clobber existing content.
get_page({ id: "abc123" })
//   → { content: [ ...existing blocks... ] }

// 3. Send the full reconstructed blocks array back to update_page.
update_page({
  id: "abc123",
  editKey: "...",
  blocks: [
    { type: "image", url: "https://assets.quicky.page/abc123.jpg", alt: "..." },
    // ...existing blocks from step 2
  ],
});

rename_page_slug

Set, change, or clear a premium custom URL slug for an existing page. Requires the page id and editKey, plus a server-side QUICKYPAGE_PREMIUM_TOKEN.

get_page

Fetch the public content of a page by id. Read-only; no editKey required. Useful for verifying a just-published page or summarizing an existing one.

Edit links

Anonymous publish and update calls return an editUrl in the exact form https://quicky.page/?id=<id>#edit=<editKey> — id in the querystring, editKey in the URL fragment (the fragment is never sent to the server, so the secret never appears in access logs or in the Referer header on outbound clicks). Surface editUrl directly to the user when they need to edit later; do not reconstruct it from editKeyyourself. Treat both as secrets — anyone with either can edit the page. When you're signed in via the remote MCP, the editKey stays server-side and is omitted from the tool result; update_page works without you passing it.

Pointing at a different deployment

Set QUICKYPAGE_BASE_URL in the local stdio server's env block to target a staging deployment, a Vercel preview, or a local Next.js dev server:

{
  "mcpServers": {
    "quickypage": {
      "command": "npx",
      "args": ["-y", "@quickypage/mcp-server"],
      "env": { "QUICKYPAGE_BASE_URL": "http://localhost:3000" }
    }
  }
}

For the remote MCP, the URL itself is the target — https://staging.quicky.page/mcp, http://localhost:3000/mcp, etc.

Auth model

The remote MCP at https://quicky.page/mcp is the account-connected surface. It implements OAuth 2.0 with PKCE (RFC 6749, RFC 7636), dynamic client registration (RFC 7591), protected-resource metadata (RFC 9728), and resource indicators (RFC 8707). Tokens are RS256 JWTs audience-bound to https://quicky.page/mcp; public verification keys are at /.well-known/jwks.json.

The local stdio package does not sign in as a Quicky.Page user. Pages published through it are anonymous and editable only through the returned editUrl / editKey. If you want cloud persistence, use the remote MCP instead.

Prefer raw HTTP? See the API reference. Working inside ChatGPT without Developer Mode? See the ChatGPT Custom GPT. Want a one-click publish button in your browser? See the browser extension.