Simple Host

View saved version →

---
name: connect-domain
description: Give a Simple Host site a shorter or custom address, either a short <name>.simple-host.app (one call, no DNS) or the person's own domain or subdomain (for example rsvp.example.com via a CNAME record, or example.com via an A record) to a site they already have on Simple Host, using the connect_domain, domain_status and remove_domain tools. Use when the person wants their site on a nicer or shorter address, or asks how to point a domain they bought (Vercel, GoDaddy, Porkbun, Namecheap, Cloudflare, Squarespace and others) at their site. Optional, since every site already has its own address where sign-in and private collections work. Gets the two DNS records (the address and a TXT ownership record), relays them with registrar-specific steps, and checks until the domain is live.
---

<!-- Derived from simple-host-website/skills/connect-domain/SKILL.md (+ references/registrars.md). Keep in step. -->

# Connect a custom domain

[Open ChatGPT Plugins](https://chatgpt.com/plugins). Click **Add**, then choose **Add custom MCP server**. Name it **Simple Host**, paste `https://simple-host.app/mcp`, and save. In the sign-in window, sign in with Google or an email code, then choose **Allow**. In a chat, pick Simple Host from the **+** menu, or just ask.

A Simple Host site is already live at its own address, `https://<site>.<handle>.simple-host.app/`,
where visitor sign-in and private collections already work. This is optional and gives it a
nicer or shorter address, served over HTTPS: a short `<name>.simple-host.app`, or the person's
own domain. You do the Simple Host side with the
tools; the person adds two DNS records where their domain is managed. The person's own explicit
instructions take priority over this guidance.

ChatGPT and Codex list each tool separately. Call `connect_domain`, `domain_status`, or
`remove_domain` directly, using its input schema. If the tool is missing, ask the person to refresh the connection.

You are already signed in as the person. Never ask for a Simple Host email, code or password.
If a tool says the connection is no longer signed in, ask them to reconnect Simple Host in the
app's settings.

**Ask first.** Connecting an address moves the site there. Before any `connect_domain` call,
name the site and the exact address and wait for a yes. The same goes for `remove_domain`.

## The short address: `<name>.simple-host.app`

One call, no DNS step. Offer it first when the person wants a shorter address and has no
domain of their own.

- `connect_domain` with `site` and `domain: "clay-studio.simple-host.app"`. It answers
  `status: "active"` at once. Give the person `https://clay-studio.simple-host.app/`.
- First come, first served. `domain_taken`: another site has it; suggest another name.
  `name_reserved`: reserved names (`www`, `api`, `admin`, `mail` and others) are refused.
  `invalid_name`: one label, lowercase letters, digits and hyphens.
- It behaves exactly like a custom domain: everything below applies, and the site's
  `<site>.<handle>.simple-host.app` address redirects there.
- A site has one bound address. Claiming the short address replaces a custom domain at once;
  a custom domain replaces the short address only once it is live, and until then the site
  keeps serving at the short address. A short address the site lets go keeps redirecting to it.

## What a bound address changes

- The site is served from the domain, on its own origin, over HTTPS (certificates are handled
  by Simple Host; the person never uploads one).
- Once active, the site lives only at the domain: its `<site>.<handle>.simple-host.app` address
  (and any older link) redirects there, and pages save only on the domain. The tools keep
  working as before.
- Visitor sign-in and private collections carry over. Pages written with `SH.requireSignIn()`
  before each save and `window.SH_CONFIG = { site: "<site>" }` before the script tag (see
  `website-deploy`) work unchanged; on a custom domain 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: website-deploy
description: Publish or update a site and its saved data on Simple Host (simple-host.app). Use when the person asks to put their files online, change an existing site, or configure forms and saved entries. Covers KV, SQLite, and files with access presets, visitor sign-in, domains, named viewers, versions, downloads, and visitor counts.
---

<!-- Derived from simple-host-website/skills/website-deploy/SKILL.md and internal/mcp/instructions.go. Keep in step. -->

# Publish and update a website on Simple Host

Simple Host publishes static websites at `https://<site>.<handle>.simple-host.app/`, and each
site can save what visitors send (KV, SQLite and files), with visitor sign-in by emailed code or
Google. Use the signed-in Simple Host connector tools; if they are missing or signed out, ask the
person to connect Simple Host (https://simple-host.app/install.html). Never ask for, read or pass
on sign-in codes, API keys or passwords in chat.
ChatGPT and Codex list each tool separately. Call the named tool directly, using its input schema.
Call tools only for the work the person requested; a planning question alone does not authorize publication or storage changes.
When the person asks to add their photos to a site, call `create_upload_link`. It shows a photo picker in the chat, or returns `photos_url` to give them; never ask them to convert, resize, or host photos elsewhere.

## 1. Decide what to build

People ask in a few words and never say who sees what. Pick the row, call `get_page_recipe` with
its topic, run the recipe's setup calls, and build the whole thing: the page, the storage with its
preset, sign-in only where the row says, and a line telling the owner how they see what comes in.

| They ask for | Topic | Who sees what |
|---|---|---|
| a booking, appointment or table reservation (even a "booking request") | `booking` | the customer signs in with their email when they press Book, then sees their own bookings and status; the owner sees all and confirms from chat |
| a quote request, contact or enquiry form, waitlist, sign-up, volunteer or job application, feedback | `inbox` | anyone sends without signing in; only the owner reads, from chat |
| a menu, prices, opening hours, a stock list the owner changes | `public` | everyone reads; the owner changes it from chat with `storage_put_kv`, no republish |
| a client portal, client documents, a private page for one client | `portal` | one site per client, opened only to that client's email |
| a guestbook, comments, reviews or questions anyone may post without signing in | `comments` | everyone reads; anyone posts after a spam check (auth.js runs it); the owner removes posts, or approves each one first (`approve_first`) |
| reviews, comments, community posts by people who sign in | `wall` | everyone reads; people sign in to post and can take back their own |
| photos visitors share | `gallery` | everyone sees; people sign in to upload |
| a shared list (shifts, tasks, a sign-up sheet) | `board` | people sign in and edit it together |
| favourites, measurements, a checklist, things each visitor keeps for themselves | `personal` | each person sees only their own |
| the owner's own notes or log on the site | `private` | only the owner, signed in on the site |
| a shop with a cart and orders | `records` | each customer sees their own orders; the owner sees all |

## 2. Do the job

- **A new site.** `create_site` with every file inline (`{"index.html": "..."}`; generated binary assets in
  `files_base64`), named with lowercase letters, numbers and hyphens. Give the person the `url` the
  tool returned, exactly as returned.
- **"My site" or "our site".** It already exists: `list_sites`, `get_site`, then `read_site_file`
  for only the files you will change (`paths` reads several at once). For a small change, send
  `update_site`'s `edits` ({path, find, replace}) instead; otherwise send `update_site` with
  `keep_other_files: true` and just those files. New hou

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: website-deploy-builder
description: Plan a website on Simple Host before building it. Use when the person has an idea for a site or web tool but has not settled what it should do, asks whether Simple Host can handle bookings, forms, accounts, payments, a database, private pages or server code, or wants to know what to build with Simple Host KV, SQLite or files. Explains who can read and write what, then hands implementation to website-deploy.
---

<!-- Derived from simple-host-website/skills/website-deploy-builder/SKILL.md. Keep in step. -->

# Plan a website on Simple Host

Use this skill to decide what to build. When the person has chosen, hand the build to the
`website-deploy` skill, which publishes it. Use the signed-in Simple Host connector; if it is
missing, ask the person to connect Simple Host (https://simple-host.app/install.html). Never ask
for sign-in codes, API keys or passwords in chat.

## What Simple Host is

A static-file host: every site lives at `https://<sitename>.<handle>.simple-host.app/` and serves
HTML, CSS, JS, images and fonts. Simple Host serves static files and its built-in storage; it does not run your own server code. Each site can still save data in
three kinds of resource the owner creates: KV (named JSON values), SQLite (tables and queries) and
files (photos, PDFs). Each resource, and each SQLite table, has a preset that says who may read,
add, edit and delete. Visitors sign in with Google or an emailed code; no password or sign-up form.

## Map the request

| They want | Plan |
|---|---|
| a landing page, portfolio, CV, multi-page site | static only, relative links |
| bookings, appointments, table reservations | SQLite preset `records`, recipe `booking`: the customer signs in when they book and sees their status; the owner confirms from chat |
| a quote request, contact form, waitlist, sign-up, application, feedback | SQLite preset `inbox`, recipe `inbox`: anyone sends without signing in; only the owner reads |
| a menu, prices, opening hours the owner updates | KV preset `public`, recipe `public`: the owner changes it from chat, no republish |
| orders from a small shop | SQLite preset `records` with a status and a linked change table |
| a client portal | one site per client, opened only to that client's email (named viewers), recipe `portal` |
| reviews, comments, a guestbook anyone may post to without signing in | preset `comments`, recipe `comments`: a spam check instead of sign-in; the owner removes posts or approves each one first |
| reviews, comments, a guestbook by people who sign in | preset `wall`: everyone reads, people sign in to post |
| photos visitors share | files preset `wall`, recipe `gallery` |
| a shared sign-up sheet or task list | preset `board` |
| things each visitor keeps for themselves | preset `personal` |
| only some people may open the whole site | named viewers by email, or one shared passcode; ask which if they did not say |
| their own domain, or a shorter address | the `connect-domain` skill, or a short `<name>.simple-host.app` |
| a tool that runs only in the browser | static plus `localStorage` or `IndexedDB` |
| data from a public API | static plus `fetch()` to a CORS-enabled API, no secret keys in the page |

## How to use this skill

1. Ask what they are trying to build, in plain language. Let them describe the idea.
2. Decide whether it can run as a static site. Name any part that cannot (server code, payments
   processing, custom account systems, long-running jobs) and suggest a substitute or another
   service for that part.
3. If visitors save anything, state each resource, its preset, and whether sign-in is needed,
   before designing the page. Personal details go in `inbox`, `records` or `personal`, never in a
   resource everyone signed in can read.
4. Always pair a form with a way for the owner to read it back: from chat with
   `storage_sql_query`, or an owner page on the site (recipe `admin`).
5. Give a short plan: how to structure i

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.