You do not type command names at fastsite. You say what you want and the agent picks the tool. The names are here anyway, for two reasons: so you can recognise what your agent just did to your site, and so you can be exact on the occasions where it matters. If no client is connected yet, start with connecting your agent and come back.

The two openers

Two commands are worth knowing by name, because every session starts with them.

List my sites.list_sites — returns the handles. A site handle is the first argument to nearly every other command, so this is how a session gets its bearings.
Read the authoring guide for site blog, then draft the page.get_authoring_guide — the rules the build audit actually enforces, folded in with that site's locales and embed syntax. An agent that reads it writes markup that publishes. One that guesses writes markup that gets rejected.

Your first ten minutes

Empty engine to published page. Say these one at a time and read what comes back before moving on.

  1. Create a site called Notes at notes.example.com. create_site gives you a handle to address everything else by.
  2. Read the authoring guide for that site. get_authoring_guide. Do this before any writing or design, not after the first rejection.
  3. Show me the shell files. shell_list_files — the Twig templates and CSS tokens that wrap every page.
  4. Snapshot the shell, then make the header darker. shell_snapshot, then shell_put_file. Snapshots are cheap and restoring one is a single command.
  5. Write a short about page. create_page. It lands as a draft.
  6. Preview the site. preview_site builds without deploying and hands back a URL. The build audit runs here, so this is where bad markup surfaces.
  7. Publish. publish_site. One git commit, live behind the CDN.

Nothing reaches the CDN on its own

Writing, editing, translating and redesigning all stay inside the engine. The public site changes when you say publish, and that is a single commit you can revert. Ask for a preview instead and you get a build nobody else is looking at.

Content

What have I got on the blog?list_posts
Show me post 14.get_post — includes the body HTML, which is what you want before asking for an edit.
Write a post about the release, publish it.create_post
Add a pricing page.create_page — same thing without a date. Slugs may be nested, so help/getting-started works if you are preserving an old URL structure.
Tighten the second half of that post and fix the heading.update_post — only the fields it sends change.
Bin the old launch page.delete_content — trash, not gone. The next build removes the page.

Research and checking

Both call out to a web-grounded model, so they cost a moment and are worth it on anything with a number in it.

Research what changed in the EU accessibility rules this year before you write.research — a structured brief with figures and sources, to write from. Sources first, draft second.
Fact-check that post.fact_check — per-claim verdicts with sources, kept on the content row. Prices and statistics are what it is for. Enable it per site.

Media

Import that image and use it as the featured image.upload_media_from_url. Alt text is required at upload, and images are embedded by media id — an external image URL in a body fails the build.
What is in the media library?list_media
Remove the old screenshot.delete_media, reversible with restore_media. purge_media is the one that deletes the files.

Design

The shell is the chrome around every page: Twig templates, CSS tokens, translation strings. Content never carries its own styling, so this is where a redesign happens.

What is in the shell?shell_list_files
Show me the base template.shell_get_file
Make the accent colour warmer across the whole site.shell_put_file on the tokens file — usually a one-line edit that recolours everything. Validated on write, triggers a rebuild.
Snapshot the shell first.shell_snapshot
Put it back how it was.shell_restore — and a restore takes its own snapshot first, so undoing an undo works.

Components

Build me a pricing table component.upsert_component — HTML or React. The build renders it to static markup, so nothing ships as JavaScript.
Which components does this site have?list_components, and delete_component to drop one.

Languages

Add German and translate everything.add_language — adds the locale and queues the translation.
Refresh the translations, I changed three pages.translate_site, which publishes when it is done.
Put a language switcher in the header.get_language_switcher returns the marker and the markup. Placement is yours — nothing is inserted automatically.
Drop Swedish.remove_language — removes the translations and the locale's pages, then rebuilds.

Publishing

Preview it.preview_site — builds, runs the audit, deploys nothing.
Publish.publish_site — returns a job to watch.
Is it done?get_build_status
What has been built lately?list_jobs — builds, publishes and translations, newest first.

Routing and site scripts

Point the old pricing URL at the new one.upsert_redirect. list_redirects also shows captured 404s, which is the better place to start.
Drop that redirect.delete_redirect
Add the analytics snippet.upsert_script — head or body, set at site level rather than pasted into a body. list_scripts and delete_script for the rest.

A script is the one thing that costs you the score

Everything else in the engine is built to keep a page at 100 across the board. Enable a header or footer script and the site opts out of that guarantee — it is your call, but make it deliberately rather than by pasting a tag out of habit.

Undoing things

Three separate safety nets, at three different sizes.

What is in the trash?list_trash, then restore_content. purge_content is the permanent one.
Restore the shell to yesterday's revision.shell_restore — design only, no content touched.
Back up the site.backup_site, list_backups, restore_backup — the whole site, database included. A restore rebuilds and publishes.

Sites, teams and credentials

Create a site for the new client.create_site
Change the base URL and the git branch.update_site — also where serve mode, canonical host and the fact-check toggle live.
Add my GitHub token so this can publish.add_github_credential, with list_github_credentials and delete_github_credential. Tokens are stored encrypted and never returned.
Invite my designer.create_team, invite_member, accept_invite, list_teams.

Webhooks

What can post into this site?list_webhooks — also lists the built-in mappers, which are what turn an inbound payload into a post or a page.
Give me an endpoint my automation can post drafts to.create_webhook
Did that fire?webhook_deliveries

The full mechanics are on the webhooks page.

When a command comes back with an error

Failures come back as readable messages rather than transport errors, which means your agent can usually read the message and correct itself. Ask it to. The three you will meet first:

  • The body was rejected. Content is body HTML only — no <script>, no inline styles, no external images. Tell the agent to read the authoring guide and rewrite.
  • An image failed the build. Images have to be uploaded first and referenced by media id, with alt text. A hotlinked URL never passes.
  • Nothing changed on the live site. Writing is not publishing. Ask for publish_site, or check get_build_status if you already did.

The protocol underneath — discovery, scopes, token lifetimes, the authoritative tool catalogue for your version — is on the MCP reference. Prefer plain HTTP? The REST API covers the same ground with an API key.