# @feelreef/mcp

Edit a [feelreef](https://feelreef.com) **native site** from any MCP client — Claude, ChatGPT,
your own agent. Every edit lands on the site's own git repo (the source of truth), builds to a
preview, and goes live only when you say so.

The site's content is plain markdown plus a one-line `%% sitetile: … %%` grammar in a git repo —
an LLM's native tongue, not a wall of block JSON. So an agent connected here can *read what it
built*, not just write blindly. That's the point.

```
npx @feelreef/mcp        # or add it to your MCP client (below)
```

> **Scope, honestly.** These tools edit a feelreef native site that **already exists** — there is
> no create-a-site-from-nothing tool, and the hosted path for owners who aren't us is still parked
> (`src/phase2/`). Building needs either the sitetile renderer on your machine or a runner we
> provision per site. If you're a cold-start agent hoping to spin a site up unattended: not today.
> Editing, reading back, previewing and publishing an existing site — that part is real and it's
> yours. See <https://feelreef.com/for/agents>.

## Install (Claude Code)

```
claude mcp add feelreef -- npx -y @feelreef/mcp
```

Point any MCP client at the `feelreef-mcp` binary. Editing needs nothing but Node ≥20 — the
sitetile parser is vendored into the package, so `get_page` / `save_page` / `create_page` work on a
fresh machine with no other checkout. **Building** (turning the repo into a deployed site) needs
either the local sitetile renderer or a runner — see [Building](#building).

## The tools

| tool | what it does |
|---|---|
| `list_sites` | the sites this adapter can edit |
| `add_site` / `check_site` / `remove_site` | register / preflight / unregister a site |
| `list_pages` · `get_page` | a site's pages + posts; one page's markdown + parsed structure |
| `describe_page_grammar` | the coral vocabulary for a page body, so you never guess a section |
| `save_page` · `create_page` · `create_post` | validate, write, git-commit (no deploy) |
| `inspect_page` | **see** the built page: links, images, headings + a `problems` list |
| `site_status` | repo vs live — did my edit actually ship? |
| `build_preview` | build the repo IR → deploy to the preview `*.pages.dev` |
| `publish_site` | deploy to the **live domain**. Never automatic; needs `confirm:true` |

No delete tool by design: an agent that can't delete a page can't lose one.

## The loop

```
get_page → (edit the markdown) → save_page → build_preview → inspect_page the *.pages.dev
                                                                   │
                                                     happy?  →  publish_site {confirm:true}
```

`save_page` commits to the repo but changes nothing live. `build_preview` shows the result on a
preview URL. `publish_site` is the only thing that touches the real domain.

## Building

`build_preview` / `publish_site` are the same verbs wherever the build runs. The adapter picks the
path automatically:

- **Local** — on a machine with the sitetile renderer (`~/Developer/tile`), the build runs here.
  This is the maintainer's dogfood path.
- **Runner** — on any other machine, point the site at a reef-runner and the build
  happens in the cloud: the adapter uploads the site's IR, the runner builds and deploys it, and
  hands back the same honest report (a routes manifest and a read-back that the deployed URL really
  serves *this* build). Configure it per site:

  ```
  add_site key:"mysite" repo:"/path/to/site" previewProject:"mysite-preview"
           runner:{ url:"https://<your-reef-runner>", token:"<token>" }
  ```

- **Neither** — `build_preview` returns an honest error telling you to set up one of the above,
  rather than failing cryptically.

Runner access is provisioned per site today, not self-serve — ask us (hi@cver.net) and we'll
point one at your site. The runner's source and protocol spec live in the monorepo, which isn't
public yet; what ships here is the adapter that talks to it.

## Adding a site

`add_site` never trusts a path — it preflights the repo first (is it git, does its IR parse as
sitetile, is there a build-fixture trap, does Cloudflare actually bind the domain) and refuses
anything unsafe to edit. A site with a live domain + prod project is added *full* (can publish); a
site with only a preview project is *preview-only* (edit + preview, publish disabled until cutover).

## License

MIT © CVER Inc. — including the vendored sitetile parser in `vendor/`, which ships in this
tarball and is the thing that reads and writes your markdown. Read it: that's the whole content
model. (The renderer's own repo isn't public yet; the moat was never the parser — it's the loop
quality and the running platform.)