Leed is a platform for publishing documentation and content-driven websites, with an AI layer built into every part of it rather than bolted onto the side. Your team works in the CMS at app.leed.ai; what you publish lands on your own domain as a fast static site that you, and your readers’ AI tools, can both read.
The three surfaces
The CMS is where your team works. It is a real-time collaborative editor for pages, menus, forms, email layouts and assets, wrapped around the operational side of running a site: an editorial calendar, analytics, contacts, team management and deployments. Two things about it surprise newcomers, and both are deliberate — every change autosaves as you type, so there is no Save button and no unsaved-changes state, and nothing you write is visible to the public until you publish it. Touring the Workspace walks the five-tab rail the whole app hangs off.
Your published site is the output: a static site, built from your content and your templates together, served on your own domain. Behind it is a Git repository that holds the site’s code — Handlebars layouts, CSS, static files — which most teams never open and developers can clone, edit and push. Every publish rebuilds the whole site, which is why a change takes a couple of minutes to appear rather than being instant; How Publishing Works traces the whole route.
The AI layer
The AI layer has three audiences, and knowing which one you are is the fastest way to find the right page.
You, inside the CMS. The Leed Assistant answers questions about your workspace and drafts content for you. It lives in the editor’s right rail, on the Assistant tab, and in the Chat tab of the rail; it is available to Administrators. Leed Assistant covers what it can do.
Your team’s own AI tools. The Operator MCP at https://app.leed.ai/mcp lets Claude, Claude Code, Cursor or any other MCP client read your workspace and draft content in it, scoped to the signing-in user’s role. Reads are broad; writes land as drafts and tracked suggestions, and publishing stays a human action. Start at Connecting to the Operator MCP.
Your readers’ AI tools. The Docs MCP and the site AI agent run on your domain, not Leed’s, and give the AI clients your readers use structured access to your published documentation. See Docs MCP: AI Access for Your Readers and the Site AI Agent.
All three are free on every plan, including Free. There is no tier at which an MCP server is switched off.
What you can do with it
| You want to… | Leed gives you |
|---|---|
| Publish product docs or an API reference | A documentation page type whose left-hand menu also sets your URLs, live search, code tabs and generated API pages — start at What a Documentation Set Is |
| Run a blog or content site | Scheduling, authors, an editorial calendar, and Labels and Series for grouping posts and driving index listings |
| Capture and follow up with leads | Forms that become contacts: How Forms Work end to end, then Contacts in the Engage workspace |
| Understand what readers do | The Know Dashboard — traffic, journeys, search gaps, broken links and per-page analytics inside the editor |
| Let AI tools work with your content | The Operator MCP for your team and the Docs MCP for your readers, both mapped on AI in Leed |
| Keep control of the site’s code | A Git-backed site repository you clone and edit locally, driven by the Leed CLI |
The mental model in one picture
flowchart LR OPS["Your team's<br/>AI clients"] -->|"Operator MCP"| CMS CMS["The CMS<br/>app.leed.ai"] -->|"publish"| REPO DEVS["Your developers"] -->|"leed site push"| REPO REPO["Your site repository<br/>content, layouts, CSS"] -->|"deployment: full site build"| SITE["Your published site<br/>your own domain"] SITE -->|"Docs MCP, site agent"| READERS["Your readers'<br/>AI clients"]
Both inputs — what your team writes in the CMS and what your developers push from the repository — converge on the same repository and the same build. That is why one rule governs everything else in these docs: nothing you change is public until a deployment publishes it. Editing, uploading, renaming a label, changing a setting and drafting over MCP are all private acts; publishing is the only public one. How Leed Fits Together redraws this picture with the manual steps marked, and is worth ten minutes before you start building anything real.
Everything in these docs
Twenty-four categories, grouped by what you would be doing when you need them. Each entry links to the page that opens that category.
Writing and publishing
| Category | What it covers | Start at |
|---|---|---|
| Your Account | Signing up, signing in, workspaces you belong to, sessions and API tokens | Creating Your Account |
| CMS Workspace | The shell: the five-tab rail, the stage, notifications, the profile menu, the must-publish dots | Touring the Workspace |
| Editing Pages | Creating pages, the editor and its toolbar, page settings, comments, revisions, scheduling | Managing Pages |
| Assets | Images, video, audio and documents — one library, with transcription and AI image generation | Asset Library |
| Content Model | Page types, menus, labels and paths — the four things that decide your site’s shape | How Content Is Organized |
| Publishing | Deployments, preview versus live, promoting, scheduling, domains and failed builds | How Publishing Works |
| Published Site | What a reader actually receives: feeds, sitemaps, caching, social cards, site search | What Your Visitors Get |
Documentation sites, your audience and your numbers
| Category | What it covers | Start at |
|---|---|---|
| Documentation Sites | Leed’s headline use case: docs sets, folders that set URLs, themes, search, API reference pages | What a Documentation Set Is |
| Forms | Building a form, placing it on a page, submissions, response emails, spam protection | How Forms Work |
| Engage | The CRM side: accounts, contacts, personas, engagement scores, campaigns, short links | Engage Workspace |
| Transactional versus marketing email, layouts, audiences, tracking, bounces, unsubscribes | How Email Works in Leed | |
| Analytics | Dashboards, widgets, visitor tracking, journeys and attribution, link health, recommendations | Know Dashboard |
AI, people and plans
| Category | What it covers | Start at |
|---|---|---|
| AI and MCP | All five AI surfaces, connecting clients, every tool both MCP servers expose, and the guardrails | AI in Leed |
| Team and Permissions | Six roles, resource-level overrides, the billing and developer checkboxes, who can see what | Roles and Permissions |
| Settings | A map of every settings card and the page that owns the feature behind it | Settings Home and the Settings Map |
| Plans and Billing | The four tiers, what each gates, usage and limits, subscriptions, invoices and downgrades | Plans and Tiers |
For developers
| Category | What it covers | Start at |
|---|---|---|
| Leed CLI | Installing and authenticating the CLI, local development, validate/commit/push, OpenAPI import | Installing the Leed CLI |
| Site Repository | The repo folder by folder, the two branches, editable versus protected files, front matter | Your Site Repository |
| Templates and Layouts | Handlebars layouts and partials, the processing order, and overriding Leed’s own templates | How Templates Work |
| Template Helpers | Every helper Leed registers, what each returns, and the ones that fail quietly | How Helpers Work |
| Styling and Themes | Tailwind, the site token contract, dark mode, custom docs themes, theming alerts and diagrams | How Styling Works |
| Leed Markdown | The storage and interchange format: every feature, how it renders, and what import and MCP writes speak | Overview and Cheat Sheet |
When something is broken rather than merely unfamiliar, Help and Reference is the fast lane: the Troubleshooting Index maps a symptom to the page that explains it, and the same category holds the error-message list, the known limitations and an honest account of what Leed does not do.
If you would rather do it than read about it, the Quick Start gets one page live in a few minutes. If you would rather be pointed at the right reading order for your job, Choose Your Path lays out three routes and says which pages to skip for now. And if you are a developer who wants a terminal, a local build and a push before anything else, go straight to Quick Start for Developers.