DEV Community: thinslatelabs

How we built a remote MCP server with OAuth on Cloudflare Workers (and got it into ChatGPT and Claude)

thinslatelabs — Sat, 31 Oct 2026 09:17:31 +0000

Dashly is a dashboard you keep up by talking to ChatGPT or Claude. You mention lunch, a run or what you spent, or you send a photo of a meal, a nutrition label, a receipt or the bathroom scale, and the assistant logs it into Dashly over the Model Context Protocol (MCP). Dashly turns those entries into live tiles against your goals.

All of that goes through one URL, https://dashly.si/mcp. It runs on Cloudflare Workers with D1 as the database, it signs people in with OAuth 2.1, and it is listed in both ChatGPT's app directory and Claude's connector directory. Below is how it's put together and what we learned the hard way. Every snippet is from our repo, trimmed.

The shape of the Worker

The API is a Hono app. The same app also runs on Node with SQLite, so routes and services only ever see a small Platform object (db, email, rateLimit, config, now, log), and everything Cloudflare-specific lives in one file. On Workers, Prisma talks to D1 through the D1 adapter:

const db = new WorkerdPrismaClient({ adapter: new PrismaD1(env.DB) }) as unknown as PrismaClient;

The public site and the web app are static files in the same Worker's assets. Cloudflare serves those on its own and only runs our code for the paths that need a server. That list matters more than it looks, because MCP clients probe /.well-known/* before they ever touch /mcp:

"assets": {
  "directory": "../../dist",
  "binding": "ASSETS",
  "not_found_handling": "404-page",
  "run_worker_first": [
    "/api/*", "/mcp", "/mcp/*", "/oauth/*", "/.well-known/*",
    "/app", "/app/*", "!/app/assets/*", "!/app/sw.js"
    // ...
  ]
}

If /.well-known/* is missing from run_worker_first, the discovery documents fall through to the static site's 404 page and the connector just fails to connect, with nothing useful in any log.

Transport: one POST endpoint, no sessions

We use Streamable HTTP and keep it stateless. There is one route. requireBearer is the only HTTP gate, and a fresh McpServer is built for every request from the caller's identity:

export function mcpRoutes(p: Platform) {
  const app = new Hono<{ Variables: BearerVars }>();
  // Before requireBearer, so a browser preflight (no Authorization) is answered, and a 401 carries CORS headers.
  app.use('/', publicCors);
  app.all('/', requireBearer(p), async (c) => {
    const auth = c.get('auth');
    const mcp: McpCtx = { p, auth, defer: c.get('defer') };
    return getHandler(p).fetch(c.req.raw, {
      authInfo: { token: '', clientId: auth.clientId ?? MCP_PERSONAL_CLIENT_ID, scopes: auth.scopes, extra: { mcp } },
    });
  });
  return app;
}

The handler comes from the official TypeScript SDK (@modelcontextprotocol/server). We create it once per platform instance and let it build the server per request:

handler = createMcpHandler((reqCtx) => {
  const mcp = reqCtx.authInfo?.extra?.mcp as McpCtx | undefined;
  if (!mcp) throw new Error('MCP context missing');
  return buildServer(mcp);
}, {
  onerror: (err) => p.log.warn({ fn: FN, err }, 'mcp handler error'),
});

Building per request sounds wasteful, but on Workers isolates come and go, so any in-memory session would have to be rebuilt from storage anyway. And because the server is built from the caller's AuthContext, every tool closes over the right user id, and there is no shared state that could leak between people. The SDK version we're on speaks the 2026-07-28 protocol, where each request carries its own protocol envelope instead of relying on an initialize handshake. Older clients that still send initialize get a stateless answer too.

CORS is open on /mcp, the discovery documents and the token, register and revoke endpoints, so browser tools like MCP Inspector can run the whole flow. It's closed everywhere a cookie is involved.

OAuth discovery

A remote MCP client starts with no token. It calls /mcp, gets a 401, and has to work out where to sign in from that response alone. So the 401 carries a WWW-Authenticate header that points at the protected resource metadata:

export function unauthorizedChallenge(config: OAuthConfig): string {
  return challengeHeader({
    resource_metadata: protectedResourceMetadataUrl(config),
    scope: config.defaultScopes.join(' '),
  });
}

The client fetches that document (RFC 9728), which names the authorization server, then fetches the authorization server metadata (RFC 8414) for the authorize, token, register and revoke endpoints.

The location of the first document is the part we'd warn anyone about. For a resource at https://dashly.si/mcp, the metadata belongs at https://dashly.si/.well-known/oauth-protected-resource/mcp. The well-known segment goes between the host and the path. A bare /.well-known/oauth-protected-resource describes a resource with no path. We serve both, so a client finds it either way:

export function protectedResourceMetadataPath(config: OAuthConfig): string {
  const { pathname } = new URL(config.resourceUrl);
  const suffix = pathname === '/' ? '' : pathname;
  return `${PROTECTED_RESOURCE_PATH}${suffix}`;
}

app.get(PROTECTED_RESOURCE_BARE_PATH, () => json(protectedResourceMetadata(config)));
app.get(protectedResourceMetadataPath(config), () => json(protectedResourceMetadata(config)));
app.get(AUTHORIZATION_SERVER_PATH, () => json(authorizationServerMetadata(config)));

The authorization server metadata says a few things clients actually rely on. We only support public clients with PKCE, so token_endpoint_auth_methods_supported is ['none'] and code_challenge_methods_supported is ['S256']. We advertise client_id_metadata_document_supported: true and a registration_endpoint, because the two big hosts register in different ways.

Client registration: metadata documents and DCR

There are three kinds of client_id our server accepts. An https URL is a Client ID Metadata Document: we fetch it, and the document is the registration. A dcr_ id is a client that registered itself through dynamic client registration (RFC 7591). Anything else would have to be a client we seeded by hand.

Fetching a URL that an unauthenticated caller chose is an SSRF surface sitting right in front of your login, so the fetch is fenced. We check that the host resolves to a public address, refuse redirects, cap the body size and time out quickly. The document must also claim its own URL as client_id, or anyone could host a document pretending to be someone else:

if (d.client_id !== clientId) {
  throw clientError('Client metadata document does not claim its own URL as client_id.');
}

Workers helped here. The platform refuses connections to private address ranges, so a DNS rebinding trick can't reach anything internal, and workerd only implements redirect: 'follow' and 'manual'. We use 'manual' and treat any non-2xx answer as a refusal.

The sign-in itself is a normal web flow. /oauth/authorize validates the request and redirects to a consent page in our web app, the person signs in with an emailed code or Google, and approving posts to /oauth/decision, which mints a single-use authorization code. Codes live for 60 seconds, access tokens for an hour, and refresh tokens for 90 days, sliding, so a connection that keeps being used never sends the person back to the consent screen.

Tokens: hashed rows, and family revocation

Every token is opaque and stored as a SHA-256 hash in D1. Validating one is a row lookup, which makes revocation instant. Disconnecting an assistant in Settings ends its access on the next call.

Every token minted from one authorization shares a family id, which is the grant's id. That gives replay detection something to act on. A refresh token is single use, so seeing one twice means a copy is loose:

if (row.consumedAt) {
  await ctx.tokens.revokeFamily(row.familyId);
  ctx.deps.log.warn({ clientId, userId: row.userId, familyId: row.familyId }, 'refresh token replayed, family revoked');
  throw reject();
}

The same happens when an authorization code is redeemed twice. Whoever redeemed it first loses their tokens too.

Personal `dsh_` tokens

Some places that list MCP servers want to health-check your server with a static credential and can't run an OAuth flow. Scripts are the same. For those, a signed-in person can create a personal token in the web app. It starts with dsh_, is shown once, and is stored hashed like everything else. requireBearer branches on the prefix and produces the same AuthContext either way:

if (raw.startsWith(PERSONAL_TOKEN_PREFIX)) {
  const found = await personalTokensService.authenticate(p, raw);
  if (!found) {
    const reason = (await personalTokensService.wasIssued(p, raw)) ? TOKEN_REJECT_REASONS.REVOKED : TOKEN_REJECT_REASONS.UNKNOWN;
    throw await rejected('Invalid access token', 'token', reason);
  }
  auth = {
    userId: found.userId, via: 'token', clientId: null, clientName: null,
    scopes: [...OAUTH_DEFAULT_SCOPES], tokenId: found.tokenId, familyId: null, source: sourceForClient(null, found.name),
  };
} else {
  // validateAccessToken(oauth, raw) and the same AuthContext from the OAuth row
}

source ends up on every entry the caller writes. It is derived from what we can verify (the client id's host, a dcr_ id, or token:<name>), never from the name a client gives itself. When a person sees "logged from Claude" on an entry, it's because the token came from a client registered under claude.ai.

Rate limiting behind shared IPs

ChatGPT and Claude call your server from their own backends, so thousands of different people arrive from a handful of IP addresses. A per-IP limit on valid traffic would throttle everyone at once. We limit a valid token per token, and only count unknown tokens against the caller's IP, since those are the guesses:

// Only guesses count per IP: a valid token is never throttled by its IP (many users can share one NAT), and
// neither is a token Dashly issued that has since expired or been revoked (a client that has not refreshed yet).

The token endpoint is keyed the same way, by a hash of the code or refresh token being redeemed, with a coarse per-IP ceiling on top. Keying it on client_id looked natural at first, but every ChatGPT user shares one client_id, and anyone could drain that bucket.

D1 in practice

D1 suits this workload well. The thing to design around is that D1 has no interactive transactions. A Prisma $transaction([...]) batch is atomic on SQLite but runs sequentially on D1. So we write multi-step operations to be safe to retry, and we validate everything before writing anything.

log_entries is the clearest case. An assistant often logs a whole meal in one call, and we promise all or nothing. Every entry is parsed and checked against its topic first, and only then do the inserts start:

const details = parsed.flatMap((e, idx) => checkAgainstTopic(topics.get(e.topicId)!, e, true).map((d) => ({ ...d, path: at(idx, d.path, indexed) })));
if (details.length) throw new AppError(ERROR_CODES.VALIDATION_FAILED, 'one or more entries are invalid; nothing was written', details);

Migrations are plain numbered SQL files that both D1 and the Node SQLite build apply, and the backend test suite runs on both runtimes (workerd through vitest-pool-workers, and Node).

Designing tools for an assistant

We have 24 tools, and the protocol side turned out to be the easy part. The work was in writing tools that a model uses correctly without a human checking each call.

One canonical unit per topic. A topic stores every value in one unit, and the tool descriptions tell the model to convert before logging. The server instructions say it plainly:

'Every topic has one canonical unit. Always convert the person\'s amount into that unit before you log it (a glass of water is about 250 ml if the unit is ml).',

The model is good at "a glass is about 250 ml" and bad at keeping track of which unit it used last Tuesday. Putting the unit in the topic, and returning it from list_topics, keeps the stored history consistent. Changing a unit is its own operation (update_topic with a unitFactor) that rescales the history and the goal together.

Goals always have a direction. "Protein 140" is a target. "Calories 2000" is a limit. "Sleep 7 to 9" is a range. A model will happily guess, and a wrong guess turns a good day red. So the goal schema is a discriminated union with no default, and the description tells the model to ask:

export const GoalSchema = z
  .discriminatedUnion('direction', [
    z.object({ direction: z.literal(GOAL_DIRECTIONS.AT_LEAST), value: z.number().finite().positive(), ...WINDOW }),
    z.object({ direction: z.literal(GOAL_DIRECTIONS.AT_MOST), value: z.number().finite().nonnegative(), ...WINDOW }),
    z.object({ direction: z.literal(GOAL_DIRECTIONS.BETWEEN), min: z.number().finite().nonnegative(), max: z.number().finite().positive(), ...WINDOW }),
  ])

The matching description ends with "If the person gives a number without saying whether it is a limit or a target, ask them." Assistants do ask, which is what we want.

Things to avoid. Some topics are things a person wants less of: takeaway, impulse buys, or, if you tell Claude about them, headaches. Those topics get polarity: 'avoid'. A day with nothing logged counts as a good day, the streak becomes days without, and the only goal allowed is at_most.

Results that survive any host. Some hosts forward only the content text of a tool result to the model and drop structuredContent. Then the model never sees the ids it needs for the next call. So every result puts a sentence first and the same data as JSON after a blank line:

export function textResult(text: string, structured: unknown): CallToolResult {
  const compact = JSON.stringify(structured);
  const json = compact.length < PRETTY_JSON_MAX_CHARS ? JSON.stringify(structured, null, PRETTY_JSON_INDENT) : compact;
  return {
    content: [{ type: 'text', text: `${text}${TEXT_PARTS_SEPARATOR}${json}` }],
    structuredContent: JSON.parse(compact) as Record<string, unknown>,
  };
}

Errors are tool results. A validation failure comes back with isError: true, a [CODE] message line and one line per bad field with its allowed values. The model reads it, fixes the input and tries again. Only an unknown tool or a malformed request becomes a JSON-RPC protocol error. Scope and subscription checks also run inside each tool through one wrapper, so the model gets a readable explanation instead of an HTTP status it can't act on:

export function guarded<A extends unknown[]>(p: Platform, auth: AuthContext, toolName: ToolName, handler: ToolHandler<A>): ToolHandler<A> {
  return async (...args) => {
    try {
      await requireEntitled(p, auth);
      requireScopes(auth, SCOPE_BY_TOOL[toolName]);
      return await handler(...args);
    } catch (err) {
      if (!(err instanceof AppError || err instanceof McpAccessError)) p.log.error({ fn: FN, tool: toolName, err }, 'tool failed');
      return errorResult(err, p.config.appUrl);
    }
  };
}

Scopes, annotations and output schemas each live in one table keyed by tool name. A contract test registers every tool and fails if any table is missing an entry, so adding a tool can't skip a step.

What directory review asked for

Claude's directory ran an automated policy scan and listed us. ChatGPT's review went deeper, and most of what it asked for is now encoded in the server.

Annotations that match behaviour. Every tool declares all four hints as explicit booleans: readOnlyHint, destructiveHint, openWorldHint and idempotentHint. OpenAI checks them against what a tool can actually do. Our rule now is that openWorldHint is true whenever a write can change what someone else sees. Dashly dashboards can be shown on a paired TV or at a shared link, so nearly every write is open-world:

const READ = hints(true, false, false, true);
// Adds something that shows on the person's dashboards; calling again adds another.
const ADD_SHOWN = hints(false, false, true, false);
// Replaces or removes something that shows on the person's dashboards; calling again changes nothing more.
const CHANGE_SHOWN = hints(false, true, true, true);

Per-client wording. Inside ChatGPT you can't show plans or prices, or link to a page that starts a purchase, and the reviewer flagged some of our example wording. We didn't want to weaken the descriptions every other client reads, so the bearer middleware already knows the source, and a small rewrite table applies only for ChatGPT, to the instructions, every tool description and input schema, and the capabilities resource:

export function wordingFor<T>(source: string, value: T): T {
  return isChatGpt(source) ? chatgptWording(value) : value;
}

A test holds every rewrite pair to the review's rules and fails when one stops matching anything.

A working test account and test cases. Reviewers sign in with a dedicated account that holds a couple of weeks of sample data, so every tool has something real to work on. The ChatGPT package also carries test cases: a prompt, the tools it should trigger, and what should happen. Directories that health-check the server with a static credential get one dsh_ token each, minted by a small script, so revoking one directory never affects another.

Connecting from ChatGPT. This is the one that took longest. Our server supports metadata documents and DCR, and we expected ChatGPT to use one of them. What finally connected was declaring ChatGPT's own metadata document as a provided client in the package's mcp.json:

"auth": {
  "type": "oauth",
  "client": {
    "mode": "provided",
    "clientId": "https://chatgpt.com/oauth/client.json",
    "tokenEndpointAuthMethod": "none"
  }
}

Since that clientId is an https URL, our server resolves it like any other metadata document. Domain verification was a static file at /.well-known/openai-apps-challenge, which also had to be allowed past the Worker's /.well-known/* route so it reaches the static assets.

If you're building one

A few things we'd do again from day one. Serve the protected resource metadata at the path-inserted location and the bare one. Rate limit by token rather than by IP. Hash tokens and look them up per request so revocation is real. Give the model units, goal directions and error messages it can act on, and assume some hosts will only show it your text.

If you want to see the result from the user's side, Dashly is at dashly.si, and dashly.si/connect has the steps for adding it to ChatGPT, Claude or any MCP client that takes a URL.

How we stopped backlink spam signups on our link in bio platform (nofollow wasn't enough)

thinslatelabs — Thu, 29 Oct 2026 14:06:11 +0000

Short answer: if your free link in bio pages attract spam signups from backlink hunters, rel="nofollow" won't stop them. What worked for us was two changes: a Cloudflare Turnstile check on signup, so scripts can't create accounts cheaply, and "go links", so a published page no longer contains any link to the spammer's website. Every outbound link is rewritten to keepp.link/go/<handle>/<linkId> and a Cloudflare Worker redirects the click from the edge.

Below is the full story, with the code.

What is Keepp?

Keepp is a link in bio that works as a full website. Creators and small businesses get a page at keepp.link/yourname, or on their own domain, built from blocks. Next to their links, the same page can run a shop with Stripe checkout paid into the seller's own Stripe account, take bookings, collect forms and run a live chat. There's a free plan, and Claude and ChatGPT can build and edit a Keepp page directly through its MCP server.

Here are three example pages built from Keepp templates:

That's what a real Keepp page looks like: a profile, social links, sections, products and bookings. It's also why the spam pattern below stood out so clearly.

The problem: spam signups that only wanted a backlink

Anyone can sign up for free and publish a page. That's the product, and it also makes a link in bio platform a target for link building.

We noticed a pattern in new signups. A good share of them published a page with one thing on it: a single link to some other website. No photo, no bio, no products, nothing a person would build for their own audience. Then they never came back.

These were backlink hunters, or the scripts they run. A free profile page on a domain with some authority, holding a link to their site, is something they collect by the hundred.

Why nofollow links didn't stop backlink spam

Every outbound link on a published Keepp page was already marked:

<a href="https://example.com" target="_blank" rel="noopener nofollow ugc">

nofollow ugc tells search engines a user put the link there and we don't vouch for it. In theory that removes the reason to spam us. In practice the spam signups kept coming, for a few reasons:

Since 2020, Google treats nofollow as a hint, not a rule. Link builders know this, and many still count nofollow links as worth having.
The tools doing this don't read rel attributes. They work from lists of "sites that give you a free profile with a link", sign up, paste the URL and move on.
A link is still a link. It can send referral traffic, get a new page crawled sooner, and pad out a backlink report sold to a client.

Nofollow made us a worse target, but it didn't take us off the list. Two things had to change: signing up had to get harder for a script, and the page itself had to be worthless as a backlink.

Step 1: Cloudflare Turnstile on email signup

Keepp has no passwords. You enter your email, we send a one-time code, and you type it in. That code request was the cheapest step to automate: one POST with an email address.

We put Cloudflare Turnstile in front of it. The sign-in page runs a Turnstile check in interaction-only mode and sends its token with every code request, with a fresh one for a resend. Most people never see it; when Cloudflare wants a closer look, a single tick box appears under the email field. The API refuses a code request without a valid token.

The check is a small Express middleware, so any route can use it:

function requireTurnstile({ action, allowUnreachable = false }, deps = {}) {
  const verify = deps.verify || verifyTurnstile;
  return async function turnstileMiddleware(req, res, next) {
    try {
      const token = req.body?.turnstileToken || req.get?.('cf-turnstile-response');
      if (!token) {
        return next(new AppError('Please complete the check and try again.', TURNSTILE_ERRORS.REQUIRED, 400));
      }
      const result = await verify({ token, remoteIp: clientIpFromRequest(req), action });
      if (!result.ok && allowUnreachable && result.reason === TURNSTILE_UNREACHABLE) return next();
      if (!result.ok) {
        return next(new AppError('We could not verify that you are human. Please try again.', TURNSTILE_ERRORS.FAILED, 403));
      }
      return next();
    } catch (err) {
      return next(err);
    }
  };
}

Two details worth getting right:

Send Turnstile the visitor's real IP, not the proxy's. Behind a reverse proxy, req.ip is the proxy. clientIpFromRequest reads the address the visitor actually connected from.
Decide what happens when Cloudflare is down. For sign-in we set allowUnreachable: true. If siteverify itself can't be reached, the request goes through and the route's per-IP and per-email rate limits still apply. Refusing would lock every real user out for the length of a Cloudflare outage. A missing token or a failed check is still refused.

Turnstile stops cheap bot signups. It doesn't stop a person, or a farm of people, signing up by hand. For them, the page itself had to stop being worth anything.

Step 2: go links, a Cloudflare Workers redirect for every outbound link

When a page is published, every web link the owner typed is now written as a link back to us:

https://keepp.link/go/<handle>/<linkId>

A visitor who taps it gets a 302 to the real address. A crawler reading the page sees only links to keepp.link. There is no link to the spammer's site anywhere in the HTML, followed or not.

On a page like this one, the social icons, buttons and cards all point to keepp.link/go/... in the published HTML. To the visitor nothing changes: tap the YouTube icon, land on YouTube.

Here's how it's built.

The stored page never changes

Only the published render writes go links. The editor, previews and the stored page document keep the real URLs, so turning the feature off is just a republish.

Stable link ids without a schema change

Each block on a Keepp page has a short ref (8 hex characters), so a link block's id is its ref. A social icon is <blockRef>-<iconRef>. Items inside an article block have no id of their own, so they use <blockRef>-<hash of the URL>.

The redirect map lives in the edge snapshot

The map from link id to address is never stored by itself. It's rebuilt from the published page by the same render that writes the HTML, so the two can't disagree. Keepp already publishes each page as a snapshot to Cloudflare R2, and the map now travels in that snapshot as a go field.

The Cloudflare Worker answers the click

Our Worker already serves published link in bio pages from R2. Go links became one more route, checked before anything else:

async function goTarget(env, handle, linkId) {
  if (env.PAGES) {
    try {
      const object = await env.PAGES.get(pageSnapshotKey(handle));
      const fromSnapshot = object ? snapshotGoTarget(await object.json(), linkId) : undefined;
      if (fromSnapshot !== undefined) return fromSnapshot;
    } catch {
      // The API is always right, only slower.
    }
  }
  return fetchGoTarget(env.API_BASE, handle, linkId);
}

async function goRedirect(env, url) {
  const parsed = parseGoPath(url.pathname);
  const site = String(env.SITE_BASE || url.origin).replace(/\/+$/, '');
  if (!parsed) return null;
  const target = await goTarget(env, parsed.handle, parsed.linkId);
  return new Response(null, {
    status: 302,
    headers: {
      location: target || `${site}/${encodeURIComponent(parsed.handle)}`,
      'cache-control': 'no-store',
      'x-robots-tag': 'noindex, nofollow',
    },
  });
}

Most clicks resolve from the R2 snapshot at the edge. If there's no usable snapshot, the Worker asks the API, which rebuilds the map from the database. A link that no longer exists sends the visitor to the owner's page instead of an error. cache-control: no-store means a link the owner edits points to the new address straight away. Only http and https targets are ever redirected to, so a go link can't turn into a javascript: URL.

Keeping crawlers off /go/

robots.txt disallows /go/, and every redirect also sends x-robots-tag: noindex, nofollow. One trap: a crawler with its own group in robots.txt ignores the * group entirely. Our robots.txt names the AI crawlers individually to welcome them, so Disallow: /go/ has to be repeated in every group.

What stays a direct link

mailto, tel and sms links, links to keepp.link itself, and the Google Maps link Keepp builds from a location stay direct. A map's pasted place URL can be any address, so that one becomes a go link.

Click analytics still see the real destination

The page runtime reports outbound clicks to the owner's analytics. It reads the real host from a data-out-host attribute on the link, so owners still see that people went to YouTube or their shop, not "keepp.link".

Rolling it out, and the trap we hit

The rollout order: deploy the API, push the Worker and robots.txt, turn the feature on, restart the API, then republish every page.

We did the last steps in the wrong order. The republish tool reads its settings itself, but the API only reads them when it starts. We turned the feature on and republished before restarting the API. Every existing page got go links, then every page an owner published afterwards went back to raw links, because the running API still had the old setting. Restart with the new settings before republishing. It's now the first line of our rollout notes.

Results so far

Both changes went live on 28 October 2026. It's early, so no big numbers yet. The one-link spam signups have slowed down, and we expect them to keep falling as the lists these tools work from catch up: a Keepp page no longer gives a backlink to anyone.

Real users lose nothing. Their links work as before, each click is a fast redirect from the edge, and their analytics still show where people went.

FAQ

Does nofollow stop backlink spam?
Not on its own. Google has treated nofollow as a hint since 2020, and the bots behind spam signups don't check rel attributes. Removing the outbound link from the HTML takes away what they came for.

What are go links?
Go links are redirect URLs on your own domain, like keepp.link/go/handle/linkId, written in place of external links when a page is published. The visitor is redirected to the real address; the page's HTML only links to your domain.

Does Cloudflare Turnstile add friction to signup?
Very little. Keepp runs it in interaction-only mode on the email code request, so most people never see it and the rest tick one box. If Cloudflare can't be reached, the request falls back to normal rate limits instead of being refused.

Do go links slow down a link in bio page?
No. The page itself loads the same way. A click costs one 302 from a Cloudflare Worker, answered at the edge from the page's R2 snapshot in most cases.

What is the best link in bio for a small business or creator?
Look for one that works as a full website, so you can sell, take bookings, collect forms and chat with visitors on the same page, with payments going to your own account. That's what we built Keepp to be.

Render at publish, serve from the edge: how a link in bio page shows up in 190 ms

thinslatelabs — Wed, 28 Oct 2026 12:06:38 +0000

I build Keepp, a link in bio and small website tool. A while ago we measured our published pages against real creator pages on six other link in bio platforms, on a phone-sized browser, on a fast connection and on 4G. This post is the engineering side of that: what makes the difference, and a small script so you can measure your own pages.

The numbers, briefly

On 8 October 2026, median of three loads each, Largest Contentful Paint:

Page	Fast connection	Fast 4G	Weight	Scripts
Keepp creator page	0.19 s	0.60 s	0.28 MB	3
Stan Store creator page	0.33 s	1.04 s	1.2 MB	35
Linktree creator page	0.78 s	1.62 s	1.7 MB	67
bio.site creator page	1.40 s	49.8 s	6.5 MB	5

The full table, with ten pages, Carrd, Gumroad and Linkin.bio, is in the original write-up on the Keepp blog.

The 4G column is the one that matters for a link in bio page. Nearly every visit comes from a phone, usually from inside an app, often on a signal nobody picked.

Two ways to build the same page

A link in bio page has two very different audiences.

The creator edits it now and then, in a logged-in editor. That is a real app: state, previews, drag and drop. A client-rendered SPA is a perfectly good fit.

The visitor opens it once, for a few seconds, from a phone. They need a picture, a name and some buttons, as fast as possible.

A lot of link in bio tools serve both with the same architecture. The public page is a shell plus a JavaScript bundle that fetches the profile and builds the DOM on the phone. That is how you end up with 67 scripts to show a list of links, and why the time to first meaningful paint swings so much with the connection.

The alternative is to split them:

Render once, at publish. When the creator presses Publish, the server builds the complete HTML for the page: layout, theme, text, links, image URLs. All the work that would otherwise happen on every visitor's phone happens once.
Store the finished page at the edge. Keepp keeps that finished copy on Cloudflare's network, and a visit is served from the nearest location as a plain document. No app server, no database query and no framework boot on the request path.
Rebuild on write. Any change that affects the public page (an edit, a price change, a product selling out) triggers a rebuild of that copy. Reads stay dumb and fast. The cost moves to writes, which are rare.
Keep the critical path small. The page needs no script to paint. One small, deferred runtime script handles the interactive parts, like opening a product, a booking or a form, after the page is already on screen. In the benchmark that came to three scripts in total on the network.

None of this is a new idea. It is static site generation and CDN caching, applied to a category that mostly grew out of SPAs. The interesting part is mostly discipline: keeping every new feature out of the request path.

One property I didn't plan for but like a lot: because the stored copy is complete on its own, published pages keep opening even when our own servers are unreachable.

Measure your own page

Here is a stripped-down version of how the numbers above were taken. It uses Playwright with Chromium, an iPhone-sized context, and Chrome's network emulation for the 4G run. Each load gets a fresh context, and you keep the median.

// npm i -D playwright && npx playwright install chromium
const { chromium, devices } = require('playwright');

// Chrome DevTools' Fast 4G: 165 ms latency, 9 Mbps down.
const FAST_4G = {
  offline: false,
  latency: 165,
  downloadThroughput: (9 * 1024 * 1024) / 8,
  uploadThroughput: (1.5 * 1024 * 1024) / 8,
};

async function measureLcp(browser, url, network) {
  const context = await browser.newContext({ ...devices['iPhone 13'] });
  const page = await context.newPage();
  if (network) {
    const cdp = await context.newCDPSession(page);
    await cdp.send('Network.emulateNetworkConditions', network);
  }
  await page.goto(url, { waitUntil: 'load', timeout: 120000 });
  const lcp = await page.evaluate(() => new Promise((resolve) => {
    new PerformanceObserver((list) => {
      const entries = list.getEntries();
      resolve(entries[entries.length - 1].startTime);
    }).observe({ type: 'largest-contentful-paint', buffered: true });
  }));
  await context.close();
  return lcp;
}

const median = (xs) => [...xs].sort((a, b) => a - b)[Math.floor(xs.length / 2)];

(async () => {
  const url = process.argv[2];
  const browser = await chromium.launch();
  for (const [label, network] of [['fast', null], ['fast 4G', FAST_4G]]) {
    const runs = [];
    for (let i = 0; i < 3; i += 1) runs.push(await measureLcp(browser, url, network));
    console.log(`${label}: ${(median(runs) / 1000).toFixed(2)} s LCP (runs: ${runs.map((r) => Math.round(r)).join(', ')} ms)`);
  }
  await browser.close();
})();

Run it with node lcp.js https://your-page.example. For page weight, listen to page.on('response') and add up the body sizes, or read the transfer sizes from performance.getEntriesByType('resource').

A few things that tripped me up:

Use a fresh context per run. A warm cache makes everything look great.
Measure from one place and say where. Edge-served pages and origin-served pages react very differently to distance.
Pick real pages, not the platform's own showcase. Showcase pages are often tuned in ways an ordinary page isn't.

Takeaways

If you're building anything where the public view is read far more often than it's written (a link in bio page, a menu, a portfolio, a landing page), it's worth asking whether the visitor's phone really needs to build it. Doing the work once at publish time and serving a finished page from the edge removed most of our performance problems before we had to optimise anything.

If you measure your own link in bio page with the script, I'm curious what you get. The full benchmark and method are here: The fastest link in bio page you can publish.

What We Learned Letting Claude and ChatGPT Edit Live Websites Over MCP

thinslatelabs — Sun, 18 Oct 2026 07:52:09 +0000

We run Keepp, a link in bio and website builder for creators and small businesses: one page that holds a website, selling, bookings, forms and chat. A few weeks ago we shipped an MCP server so Claude and ChatGPT can build and edit those pages directly. A person says "add my new class times and a booking button" in a chat, and the assistant changes a real, public page.

That is a different job from most MCP servers, which read data or run a search. Ours writes to something strangers will see. Here is what that taught us.

1. Let the model write the whole document, but make stale writes fail

Our first instinct was a dozen small tools: add a block, move a block, change a colour. Models were bad at it. They lost track of order, half-applied changes, and made the page inconsistent.

What worked was one tool, put_page, that replaces the whole page document. The model calls get_page, edits what it got back, and sends the complete list of blocks. Anything left out is deleted, and the tool description says so plainly.

The risk is obvious: the owner edits the page in the editor while the assistant is mid-change, and the assistant overwrites it. So every get_page returns a version, put_page requires it, and a write against an old version fails with a clear error instead of silently winning. Optimistic concurrency turned out to be the single most important guard on the whole server.

2. Keep the schema out of every tool listing

A page has many block types, each with its own fields. Putting all of that in the put_page input schema bloated every tool listing the host sent to the model, on every turn.

We moved the full block catalogue into an MCP resource. The tool description points at it, so the model reads it once when it needs it, rather than carrying it in every request. Tool listings stayed small and the model still had every field when it built a page.

3. Never trust a URL the model gives you

Models love to put image URLs straight into a page, often from wherever they found them. That makes the public page depend on someone else's server, and some of those images vanish a day later.

Every image URL in a write is now downloaded and stored on our side as part of the write. If one cannot be fetched, the whole write fails and names the block. The model gets told exactly what went wrong and usually fixes it on the next try.

4. Return structured results on every path

Hosts handle tool results differently. Some only show the model the text content, some read structuredContent. We declare an outputSchema on every tool and return structured content on every success path, with a readable sentence in the text as well. A test fails the build if any tool is missing either.

The same goes for safety hints. Each tool declares whether it is read-only, destructive, or touches the outside world, from one table in the codebase, so hosts can decide when to ask the user first.

5. OAuth for native clients needs loopback on any port

Remote MCP over OAuth worked first time in browser hosts. It broke for native clients like Claude Code, which sign in through a callback on localhost with a random port. Our redirect check wanted an exact match.

The fix is in the spec for native apps: loopback redirect URIs are allowed on any port. Once we accepted that, sign-in worked everywhere. Client ID Metadata Documents also meant we did not need dynamic client registration for the hosts we cared about.

6. Different hosts need different tool sets

Not every host wants every tool. Some app directories do not allow selling subscriptions inside the assistant, so for those clients we hide the plan tools entirely rather than letting them fail. Filtering by client at listing time is cleaner than refusing at call time.

What it looks like in practice

The result is that a creator can open Claude or ChatGPT, connect Keepp once, and say what they want: a shop with three products, a booking page for sessions, a contact form and a chat. The assistant reads the catalogue, writes the page, and gets back the live URL and a link for each part that opens as its own page.

If you are building an MCP server that writes to anything public, the short version is: give the model whole documents with a version check, keep big schemas in resources, own every asset it hands you, and return structured results everywhere.

Our developer docs, including how to connect the MCP server, are at keepp.link/developers. Keepp itself is at keepp.link.