Write the blog and these docs from Claude

Content on gemboss.com lives in a database called GemBlog, with an MCP server in front of it. You write with Claude, it saves to the database, and a generator turns the database into the static pages you are reading.

Connect it

GemBlog runs over stdio, so it is a local command rather than a URL:

Point DATABASE_URL at production to edit the live content, or leave it on the local SQLite default to draft safely.

Write

Draft a docs article in the use-cases category about reading the funnel by device. Summarise it in one sentence, and set what it was checked against.

create_help_article and create_post both start as drafts. Nothing is public until you publish, and publishing to the database is still not publishing to the site.

Write plain markdown. Fenced code blocks become the site's command blocks and markdown tables become its scrollable tables, so you do not need to write any HTML.

Publish, then actually publish

Two distinct steps, and conflating them is the mistake to avoid:

1. publish_help_article marks it published in the database and in the public API.
2. The site is static. Run the generator, which writes the HTML and opens a pull request against the website repo. Merge it and the page is live.

The second step exists on purpose. A static site does not depend on the content service being up, keeps the content checks that run against files, and gives every publish a diff someone can read.

One rule about editing

An article whose body was authored as HTML rather than markdown is marked as such, and editing its markdown will not re-render the page. This protects hand-drawn illustrations and tables that markdown cannot express. The update result tells you which happened, so check it rather than assuming.

Next

• Connect Claude Code to GemBoss
• What Claude can and cannot change