Drivethrough

Attach or detach a custom domain the user already owns (paid plans). "attach": connect the domain to the site — returns the exact DNS records to add; afterwards use check_domain {action: "connect"} for a one-click registrar link and check_domain {action: "status"} to poll until active. "detach": remove the domain from the site. The site keeps its drivethrough.site address throughout.

manage_domain

Check a site's custom domain, read-only. "status": live verification progress — pending_dns (waiting on DNS records) → pending_ssl (certificate issuing) → active (serving with TLS); poll after setup and tell the user when it's live. "connect": look up one-click setup at the user's registrar (GoDaddy, Cloudflare, IONOS, Squarespace, …) — when a URL comes back, relay it and their registrar creates the records in one click; otherwise relay the copy-paste records manage_domain attach returned.

check_domain

Get a one-time link where the user sets the API keys a site's integrations need (Pro plan) — two steps, like create_upload. Call it with the site: it returns a link (10 minutes, one use, no sign-in). Send it to the user as a clickable link and have them paste the keys there. NEVER ask for a key in the chat, and never put one in a file — this tool never receives or returns a key's value. When they say they're done, call again with the returned session: it reports which names are set. A deploy that needs an unset secret is refused with a fresh link already in the error — relay that one instead. Pass names to rotate a key that is already set. A webhook's secret comes FROM the other service: tell the user to add a webhook there pointing at its URL (get_integrations and the deploy error give it) and paste the signing secret it shows into the link page; a url_token secret is generated on the link page, which then shows the full URL to paste.

create_integration_setup_link

Provision the per-site database. Idempotent. Deploying a drivethrough.json that declares types does this automatically. Site pages read and write rows via the same-origin Data API: GET /api/data?type=X lists, POST /api/data with {type, json} inserts. Anonymous writes (write: "public", or "viewers" on a public site) additionally require Cloudflare Turnstile in that POST: GET /api/config for the turnstile_site_key, load https://challenges.cloudflare.com/turnstile/v0/api.js, render <div class="cf-turnstile" data-sitekey="…"></div> inside the form, and send the widget's "cf-turnstile-response" input value as "turnstile_token" in the body. The widget is usually invisible; owner and invited-viewer writes on private sites skip it entirely.

create_db

Mint a short-lived upload link the USER opens in their browser to add local files (photos, PDFs, audio, video) — the route for binary assets when you cannot reach the bytes and they aren't hosted anywhere. Two-step: (1) relay the returned upload_url as a clickable link — it opens a drag-and-drop page (no sign-in needed) that takes up to 20 files, 25 MB each, and expires in 30 minutes. (2) When the user says they're done, call this tool again with the SAME `site` plus the returned `session` — it lists what they uploaded ({upload_id, filename, size_bytes}); ship each with deploy_site files: [{path, upload_id}] (mode "patch" adds them to a live site). Never base64-encode a file instead — but if the bytes are already in YOUR runtime (e.g. a chat attachment mounted in your sandbox) AND you can make HTTP requests, you may PUT them straight to the returned put_url (one file per request, its filename as the last path segment) without involving the user. Choosing a route for a binary asset: already on the public web → deploy_site {path, source_url}; this server runs on the user's machine → deploy the directory; file only in the chat or on the user's machine → this tool. Tiny pasted assets (≤1 MB, e.g. a favicon) may still go inline as base64 content. Upload ids are single-use: the deploy that references one consumes it (the bundle keeps the bytes; the staged copy is removed and its quota refunded) — to rename or duplicate the file later, use deploy_site {path, from_path}. An upload no deploy references within 24 hours is deleted, so deploy soon after the user confirms. Pass size_bytes when the user told you a file's size — quota errors then surface here instead of failing their upload.

create_upload

Delete a site. Two-phase and safe: the site leaves the driveway immediately (guests lose access, share links are revoked, the name frees up) but stays recoverable for 30 days via restore_site. Only after 30 days is it destroyed for good.

delete_site

Deploy a site to Drivethrough. Idempotent: creates the site if needed, else ships a new version. Sites are private by default. Pass `files` with generated content — the platform assembles the bundle server-side, so no local filesystem or build toolchain is needed. Content you generated counts even once it is sitting in a file: if you wrote the page to your own sandbox, read that text back and send it as files[].content. An account's first deploy needs a username (it starts every site address): if the deploy returns username_required, ask the user to confirm the suggested one or pick their own, then retry with `username`. Images and other binary assets — pick the route by where the bytes live: already at a public URL → {path, source_url} (fetched server-side); a local file — the user's, or an attachment already in your runtime — → create_upload first, then {path, upload_id}; already deployed on this site → {path, from_path} copies it server-side (with delete_paths, a move). Never base64-encode a file, by hand or in code — inline base64 is capped at 1 MB and is only for tiny pasted assets; a file shipped via upload_id is referenced, never additionally inlined. To rework an already-deployed site, read it back with get_site first, then deploy with mode "patch" — only the files that change. For small text changes to existing files, use edit_site instead: it sends find/replace pairs, never whole files. Every deploy's version number is a restore point: prior versions stay listed (get_site history), diffable, viewable (preview_site), and returnable (revert_site). A successful deploy may still return `warnings` — things that will bite at runtime but only for visitors, never for you: a form type anonymous visitors can write with no page loading the Turnstile widget, or a page that fetches a data type its visitors have no permission to read. Resolve them before telling the user it works.

deploy_site

Edit a deployed site's text files in place — the efficient way to make small changes (wording, values, a link, a style tweak) to a live site. Send only find/replace pairs, never whole file contents: the platform reads the current version, applies the edits, and ships a new version with everything else carried forward. Prefer this over get_site + deploy_site whenever the change is small relative to the file. Each `find` must match the deployed text exactly (whitespace included) and exactly once — add surrounding context to pin down one occurrence, or set replace_all. All-or-nothing: if any edit fails to match, nothing deploys and the error says how to recover, so you can try an edit without reading the file first. Edits are never lossy: the pre-edit version stays restorable via revert_site, so to undo an edit, revert — don't hand-invert it. After visual changes, preview_site shows what actually rendered.

edit_site

Show a site's connections to other services' APIs (Pro plan) and how they last went: which secrets are set (never their values), the declared routes, actions, schedules (next run, last result, failures) and webhooks (URL, last event), and the latest 20 outcomes, including real page use. Read-only. Pass reference: true for the drivethrough.json format these are declared in, with two complete examples — read it before adding one to a site.

get_integrations

List the authenticated account's sites with their addresses, visibility, and status. Pass include_deleted to also see recently deleted sites (recoverable for 30 days via restore_site).

list_sites