How remarkdown bridges your AI and your reMarkable.

1. What is the Model Context Protocol?

The Model Context Protocol (MCP) is the wire format Anthropic, OpenAI, and others use so an AI can call tools you control. Your client — Claude, ChatGPT, Cursor, Gemini CLI — sends a JSON-RPC request to a server you've authorized. The server runs the tool against whatever real-world resource it owns, and returns the result.

For remarkdown, the resource is your reMarkable cloud account. The tools are push_markdown, list_documents, and read_document. The server is a Cloudflare Worker we operate, and it's the only thing that holds the device token your tablet handed out when you paired.

2. Connecting an AI

The first time an MCP client (say, Claude.ai) connects to mcp.remarkdown.org/mcp, it discovers our OAuth metadata from a /.well-known/oauth-protected-resource document, runs an OAuth 2.1 authorization-code flow against auth.remarkdown.org (PropelAuth), and ends up with a short-lived bearer token scoped to your account.

That token is what the client presents on every tool call. We validate it against PropelAuth's introspection endpoint and pull your user ID from the response. If the token is missing, expired, or revoked, the call fails with a 401.

Setup is the easy part — there's a per-client walk-through on the Connect page for Claude.ai, ChatGPT, Claude Desktop, Claude Code, Cursor, Gemini CLI, and any other MCP client.

3. The path a document takes

When you ask your AI to push a markdown document to your tablet, here's what happens:

1. The client builds an MCP tools/call request with the markdown body, your chosen document title, and the bearer token, and POSTs it to mcp.remarkdown.org/mcp.
2. The Worker validates the bearer with PropelAuth, resolves it to your user ID, and looks up your encrypted reMarkable device token in Postgres.
3. The Worker decrypts the device token in memory using a key-encryption key (KEK) that only the Worker holds.
4. The Worker streams the markdown body plus the decrypted reMarkable token into a Cloudflare Container that runs the conversion binary. The binary turns markdown into a native reMarkable notebook — handwriting-editable on the tablet, not a flat PDF.
5. The Worker uploads the converted notebook to your tablet's cloud through the same sync API the official reMarkable apps use. Your tablet picks it up next time it syncs.
6. The Worker writes one audit-log row (tool, MCP client, timestamp, document title, outcome). No body, no contents.
7. The MCP call returns to your AI with a success message it can read back to you.

The whole round trip usually completes in under three seconds for a typical meeting-notes document.

4. What remarkdown stores

Three things. That's the full list.

• Your email — from sign-in, via PropelAuth.
• An encrypted reMarkable device token — issued by your tablet at pair time and encrypted at rest. Only the Worker can decrypt it.
• An audit log — one row per tool call: action, MCP client identifier (where available), timestamp, document title, outcome.

Things that are not stored anywhere on remarkdown's infrastructure:

• The contents of any document you push or read.
• Your reMarkable password — pairing happens through a one-time 8-character code from my.remarkable.com, never a password.
• Aggregated traffic profiles. No Google Analytics, no Mixpanel, no third-party trackers.

The privacy policy spells this out in formal terms; this section is the engineering version of the same story.

5. Security model

The KEK never leaves the Worker. The conversion Container receives the user's plaintext device token in the request body for each call, but it never sees the encryption key. A full Container compromise can't decrypt any other user's token at rest.

OAuth 2.1 with Dynamic Client Registration. Every MCP client identifies itself via DCR; we don't pre-allowlist Claude or ChatGPT — they register themselves, present a redirect URI, and a scoped bearer flows out the other end. Tokens are short-lived and refreshable through the same flow.

TLS everywhere. Worker ⇄ client, Worker ⇄ Container, Worker ⇄ reMarkable cloud, Worker ⇄ Postgres (via Cloudflare Hyperdrive). The only plaintext data lives in Worker memory for the duration of a single request.

Session cookies are opaque. The dashboard's session cookie (remarkdown_sid) is HttpOnly, Secure, SameSite=Lax, and contains a random session identifier — never a JWT, never personal data.

6. Built on Cloudflare Workers

The whole worker bundle is a few hundred KB of TypeScript running on Cloudflare's edge in 320+ cities. Routing is Hono. Identity is PropelAuth. Persistence is PlanetScale Postgres reached through Cloudflare Hyperdrive, with a single short-lived KV namespace for OAuth state and another for dashboard sessions.

The markdown-to-notebook conversion runs inside a Cloudflare Container — a small Rust binary built from remarkable_rust, a reMarkable client library we maintain in the open. Worker calls Container over a private Durable Object binding; end-user traffic never hits the Container directly.

Cold start for the Worker side is a few milliseconds. The first Container hit warms it up, and subsequent calls reuse the same instance for ten minutes.

7. Why this exists

remarkdown is built by Ploton Labs, Inc. — a small team that thinks paper still matters. We use reMarkables ourselves and we wanted a way to push AI-drafted notes (meeting summaries, brainstorm dumps, reading lists) to the tablet without going through a clunky export. So we built it.

Free covers everything you can do with your own AI client. Pro adds the integrations that push to you when you're not at a screen. Questions? support@remarkdown.org.