The zeroheight MCP server can create pages in your design system. An AI agent connected to zeroheight — Claude Code, Claude Desktop, Cursor, VS Code, or any other MCP client — can assemble a documentation page from the context it already has (e.g. your codebase, Figma files, other MCP servers) and save it straight into a styleguide.

This guide covers what you need to get set up, how a write session works in practice, the tools involved, and the current limitations.

Setting up

In order to be able to create pages in your styleguide, you will need to be connected via MCP via login as a zeroheight user with admin/editor permissions.

Viewers connecting using SSO and MCP via login, admins/editors connecting using MCP via link or local MCP cannot create pages in zeroheight.

Once connected with write permissions, the MCP exposes new properties on existing tools (like get-page) to toggle between read and write and new tools that are required to create rich pages.

Creating pages

The write follows the same five steps every time. You don't have to spell them out — a capable agent works this out from the tool descriptions — but knowing the shape makes it much easier to steer and to debug.

1. Choose where the page goes

Your agent calls list-pages to read the styleguide's navigation tree and picks a category ID for the new page. Pages can only be created in the current work-in-progress release, so the agent must use IDs from the the current work-in-progress release.

Prompt example:

Look at my Foundations category in the Acme design system and tell me where a new page about elevation should go.

2. Read the content format guide

Page content is written in zeroheight's editor XML format. Rather than guessing it, your agent fetches the zeroheight://editor-instructions MCP resource, which documents every supported element. Clients that can't read MCP resources directly (for example, the Claude desktop app) can reach the same guide through the read-resource tool.

3. Gather the references the page needs

Any references to external sources (e.g. Figma, Storybook etc) need to point to IDs in zeroheight before the page can be saved and these IDs can be fetched by the agent using:

• upload-asset for images and downloadable file attachments
• list-design-libraries then get-designs to embed Figma designs, or images for a do's & don'ts block
• list-repositories, get-repository, then create-markdown-snapshot to embed a markdown file from a connected git repository
• list-component-sets and get-component-set for component data tables
• list-token-sets and list-tokens for token mentions and token tables
• get-storybooks and get-stories for Storybook embeds
• get-livecode-settings before writing a livecode block that imports a package

If your Figma or git connection has lapsed, these tools still list existing items but the page save will fail. The tool response says so explicitly and returns a re-authorisation link — follow it, then ask your agent to try again.

4. Create the page

Your agent calls create-page with the category, a page name, and the content. It can optionally create the page hidden from viewers, which is a good default when you want to review before anyone sees it.

The tool returns the new page's URL — ask your agent to share it.

5. Verify and publish

Your agent can read the page back with get-page to confirm the content landed as intended. Then open the page in zeroheight and take it the rest of the way yourself:

• If you use releases, the page sits in the work-in-progress release until you publish a release.
• If you created the page hidden, unhide it in the app when you're happy with it.

What you can put on a page

Write mode supports the current zeroheight block types, so an agent can build essentially the same page you could build in the editor: text and headings, tables, lists, code blocks, callouts, images and attachments, Figma design uploads, do's & don'ts, component sets, token mentions and token tables, markdown from a connected repository, Storybook embeds, livecode, and tabs.

Accuracy on references depends on your prompt and on how your libraries are named, in the same way it does for a person: an agent asked to "embed the primary button" will pick well from a tidy Figma library and less well from an ambiguous one. Being specific — naming the file, the frame, or the token set — makes a large difference.