Skip to main content

Recipes

Each recipe is what you type, followed by the tool calls the assistant makes. Arguments are abbreviated.

New landing page, then publish​

Make a landing page for Harbor, a waitlist tool for indie founders. Use the logo in ~/Desktop/harbor-logo.png.

  1. get_markup_reference with topic: "grammar", then topic: "example", example: "startup-landing".

  2. create_project:

    { "name": "Harbor", "domain": "harbor" }

    Returns the project and a starter .page file. Nothing is live.

  3. upload_asset:

    { "project": "harbor", "filename": "logo.png", "source": { "path": "/Users/me/Desktop/harbor-logo.png" } }

    Returns img: <- logo.png.

  4. save_page:

    { "project": "harbor", "pages": [{ "name": "landing.page", "content": "[site]\ntitle: Harbor\nlogo: logo.png\n..." }] }

    Returns build.id (say 4567), any compiler issues, and preview_url, the project in the editor. The assistant shows you the preview link and stops.

Looks good, publish it.

  1. publish_build, which your client asks you to approve:

    { "project": "harbor", "build": "id:4567", "confirm": true }

    Returns status: "publishing", after_event_id, and an ETA (about 3 minutes on Free and Pro, about 10 seconds on Pro+).

  2. get_deploy_status, repeated with the returned after_event_id until done is true:

    { "project": "harbor", "build": "id:4567", "after_event_id": 91230, "wait_seconds": 60 }

    Ends with succeeded: true and the live URL, https://harbor.micropage.sh. If the page still shows the old version, wait up to a minute while Cloudflare's edge caches refresh after the deployment.completed event.

Edit a live page​

On acme.micropage.sh, change the pricing to $9/month and add an FAQ entry about refunds.

  1. get_page_source with project: "acme": the current .page source of the active build, plus the uploaded filenames.
  2. save_page with the whole edited source, every other line unchanged. The live site still shows the old version.
  3. The assistant shows you what changed and the preview link. Publishing is the same publish_build and get_deploy_status pair as above, once you ask.

The edit_page prompt runs steps 1 and 2 with the "change only what was asked" rule built in.

Roll back to an earlier build​

The new hero broke the layout. Put back yesterday's version.

  1. list_builds with project: "acme": builds newest first, with status and dates.

  2. get_page_source with version: "v11" if the assistant needs to confirm which build is the good one.

  3. publish_build, approved by you:

    { "project": "acme", "build": "v11", "confirm": true }

    Build 11 becomes the active build and is redeployed. The newer draft stays in the build history.

  4. get_deploy_status until done.

Write and send a newsletter post​

Write a post announcing the new export feature and send it to the "updates" list.

This needs MICROPAGE_MCP_ALLOW_SEND=1 in the server config. Without it the assistant can draft and preview the post, but publish_post refuses to send.

  1. get_markup_reference with topic: "posts_format".

  2. upsert_post:

    {
      "project": "acme",
      "title": "Export your data as CSV",
      "description": "Every table now has an export button.",
      "body_markdown": "Starting today ...",
      "email": true,
      "list": "updates"
    }

    Saves a draft. Nothing is published or sent.

  3. preview_post_send with slug: "export-your-data-as-csv". Returns will_email: true, the list, the active subscriber count, whether sending is allowed, and a confirmation_token. The assistant shows you the preview and waits.

Send it.

  1. publish_post, approved by you:

    { "project": "acme", "slug": "export-your-data-as-csv", "confirmation_token": "<from step 3>" }

    Publishes the post under /content, queues the email, and queues a site rebuild. Clients that support it show a final "email N subscribers?" dialog first. Follow the rebuild with get_deploy_status using the returned build_id and after_event_id. If another publish replaces the rebuild before it runs, get_deploy_status follows the replacing build and lists the hop under superseded (see Posts).

If the post changed after step 3, the token no longer matches and publish_post refuses; the assistant has to preview again. Publishing the same post a second time re-sends the email to the whole list, and preview_post_send says so.

Edit an existing post​

In the "export-your-data-as-csv" post, mention that exports include archived rows.

  1. list_posts with slug: "export-your-data-as-csv": every field under the names upsert_post takes, plus revision (say 4).

  2. upsert_post with every field passed back, the body edited, and the revision from step 1:

    {
      "project": "acme",
      "slug": "export-your-data-as-csv",
      "title": "Export your data as CSV",
      "description": "Every table now has an export button.",
      "body_markdown": "Starting today ... Exports include archived rows.",
      "email": true,
      "list": "updates",
      "revision": 4
    }

    Returns the new revision. If the post is published, the call also needs confirm_live_update: true, which the assistant asks you for first.

If someone changed the post after step 1 (in the editor, the CLI, or another session), upsert_post fails with REVISION_CONFLICT and nothing is saved. The assistant re-reads the post with list_posts, applies the edit to the current values, and saves again with the new revision.

  • Tools: every argument used above.
  • Safety: which of these calls to approve by hand.