Zitegen MCP tools

What it is

@zitegen/mcp is a Model Context Protocol server that exposes your Zitegen account to any MCP-compatible AI tool. It runs as a small local process and talks to Zitegen over an authenticated HTTP API — so an agent can list your sites, edit a page's component tree, run a real build, and publish, all through structured tool calls.

Every tool writes through the same server-side path the dashboard uses, so an agent and a human can work on the same site without stepping on each other or drifting out of sync.

Setup

MCP access is available on the Pro plan and above. Generate a key under Settings → API keys (keys are prefixed zit_), then register the server with your client. For Claude Code:

claude mcp add zitegen -e ZITEGEN_API_KEY=zit_... -- npx @zitegen/mcp

Any client works the same way: run npx @zitegen/mcp with ZITEGEN_API_KEY set in its environment. The key is sent as a bearer token on every request. Point at a self-hosted or staging instance by also setting ZITEGEN_API_URL.

The tools

Sites & discovery

• list_sites — list your sites with id, name, slug, and deploy status.
• generate_site — create a whole new site from a prompt (costs 10 credits); can also translate the home page into locales.

Pages & files

• list_pages — list a site's pages cheaply, without compiling Astro output. Includes each page's draft/published status.
• get_page_tree — get one page's raw, editable component tree, including its status.
• get_files — get the site's fully compiled Astro project files.
• push_files — replace a page's component tree with edited JSON (full-tree replacement, not a patch). Prefer patch_page for a small or mechanical edit.
• patch_page — apply a small batch of targeted edits (insert / update / replace / delete by node id) without fetching or resending the whole tree.

Reusable components

• convert_to_shared_component — turn a node into a site-scoped Reusable Component.
• list_shared_components — list a site's Reusable Components.
• attach_shared_component — add an existing Reusable Component onto another page.

AI editing

• ai_prompt — send a natural-language edit to a page and save the result (costs 3 credits). Also accepts a content-type detail-page template's id (from manage_templates, not list_pages) — the edit is told it applies across every entry of that content type.

Content & CMS

• manage_content_types — define content types with custom field schemas (list / create / update / delete). A type also has its own draft/published status — a draft type's entire URL section, and every one of its entries regardless of that entry's own status, is hidden from the live site until the type is published. Deleting a content type is owner-only — it cascades to every entry of that type.
• manage_articles — manage blog posts and any content type's entries (list / create / update / delete / generate). An article's body can include the same rich-content blocks the dashboard editor's toolbar offers — callouts, cards, accordions, and tabs — not just paragraphs, headings, and lists. Category/tags are backed by real taxonomies (see manage_taxonomies) — assign any taxonomy's terms via the `terms` field, a term is auto-created just by naming it. Deleting an article is owner-only.
• manage_taxonomies — manage the categorization system behind an article's category/tags, extensible with custom taxonomies. Every site automatically has a "category" (hierarchical) and "tags" (flat) taxonomy; a custom one you create (e.g. "Region") is assignable only to the content types its `objectTypes` lists (blog and/or specific content types) — not automatically every content type. List / get / create / update / delete taxonomies, plus create/update/delete individual terms — usually unnecessary, since manage_articles' `terms` field creates a term automatically. Deleting a taxonomy is owner-only and irreversible; "category"/"tags" can never be deleted or have their slug changed.
• manage_templates — view and customize a content type's detail-page template (the shared layout its entries render through), bound with {{fieldKey}} placeholders and content/table-of- contents marker nodes. Not an ordinary page — list_pages and get_page_tree never include it. Supports the same saved-variant lifecycle as the dashboard's Templates panel (list / create / rename / set active / duplicate / delete, one saved variant per locale can be active at a time) plus full tree editing, mirroring push_files/patch_page.
• list_leads — list submissions to a site's forms. Any <form> in the page tree is auto-detected and captured with no extra wiring — filter to one form to get its real field names as columns. Read-only, newest first.
• manage_form — configure what happens after a visitor submits (list / get / update): the success/error message text, an optional redirect, tightening-only upload limits, and an outbound webhook fired on every submission. Also manages up to 5 custom, conditional notifications per form (addNotification / updateNotification / removeNotification) — each with its own recipient, subject, and body ({all_data} or {field.fieldName} merge tags), optionally gated on conditions (equals/contains/notEquals/isEmpty/isNotEmpty, AND-only) that must all match for it to fire. Everything here is also editable as plain fields in the dashboard's Leads tab — either surface works.
• list_wordpress_connections — list a site's WordPress connections (a site can have more than one, e.g. a blog on one WP install and a docs/knowledge-base on another). Returns each connection's id, label, site URL, and whether authentication is saved — never credentials. Read-only; connecting/editing WordPress connections is dashboard-only. Requires a paid plan.
• browse_wordpress_content — two-step live discovery on a connection from list_wordpress_connections: omit `restBase` to list its post types, then pass a `restBase` to page through that type's real items (title, excerpt, date, link, image), optionally filtered by `search`. Always fetched fresh, nothing cached. This is for discovery only — to actually render items on a page, bind a grid/list node via push_files/patch_page with data-zg-wp-connection (the connection id) and data-zg-wp-collection (the post type's slug from step 1 — not its `restBase`; e.g. "post", not "posts") props; the platform resolves slug to restBase itself and renders the live items at build/deploy time.

Build, deploy & config

• preview_site — run a real astro build and deploy to the preview branch, without touching production.
• publish_site — run a real astro build and publish to production on Cloudflare Pages.
• get_build_logs — return build and deploy stages and logs for a site.
• manage_domain — connect, check, or remove a site's custom domain.
• manage_site_settings — get or patch a site's settings (name, SEO, locales, fonts, palette, badge toggle, and more).
• manage_page_seo — get or patch one page's SEO fields: meta title/description, canonical URL, noindex, OG image, structured-data type/fields, and focus keyword.

Keeping token cost down

MCP conversations pay for every tool call and its response out of the client's own context — a heavy call (a full compiled file tree, a raw component tree) stays in that context and gets resent on every later turn. For a small edit or a fresh page, the difference between an efficient session and an expensive one is usually just which tools get called.

Put the detail up front instead of drip-feeding it. One thorough message lets generate_site build the whole page in a single call, instead of needing several follow-up ai_prompt round trips to add what you left out:

If you do go the get_page_tree → push_files route, say so when nothing else has touched the site since your last push. An agent that re-fetches the tree defensively before every edit is paying for a read it often doesn't need — if you're the only one editing and no canvas session or design sync ran in between, tell it to work from the tree it already has instead of re-fetching. For the push itself, a small mechanical change (an added field, a copy tweak) usually only needs a targeted check afterward — confirming the new node is in the returned tree — rather than a full screenshot or pretty-printed re-read of the whole page.

Real builds, shared limits

preview_site and publish_site each run a genuine astro build — the same build the dashboard's Preview and Publish buttons run. On paid plans they share a single budget of 150 real builds per day, per site, counted across MCP and the dashboard buttons together. The lighter tools (listing, reading trees, editing) aren't rate-limited that way.