Shape your sites and collections in the admin or over MCP, with a schema, routes, rules and a style guide, and no deploy.

Configure your content

The structure of your content lives in Hollware's database, next to the content itself: your sites, their collections, the schema of each collection's frontmatter, its routes, its rules and its style guide. You change it in the admin or have an agent change it over MCP, and it applies at once, to every save and publish after it. Nothing is deployed.

Sites and collections

A deployment serves one site or more. A site has its locales and its collections; a collection is a kind of entry, such as posts or pages. hollware init makes your first site from a preset, a blog unless you ask for docs or a collection of pages:

npx hollware init --site my-site --preset blog --locales en,es --local

From then on, open Collections in the admin, or read the structure over MCP with get_structure.

A collection's name is lowercase letters, digits and hyphens, such as blog. Five names are taken by routes of the read API and no collection may have them: admin, assets, ops, search and site.

In the admin

Collections lists the collections of the site and makes one from a preset.
The page of a collection edits its fields, its paths per locale, which fields hold the translations, the tags and the order, its rules and its style guide.
Site edits the locales, the public URL, the origins that may read from the browser, the style guide of the site and its webhooks, makes a new site, and puts one in the trash.

A change that would touch entries the site already holds says what first, and waits for you to confirm: a collection or a locale you remove keeps its entries out of reach until it comes back, and a schema that refuses some entries lists them, so you fix them at their next save. No entry is ever deleted.

Over MCP

An agent with a token that has schema:admin, the scope of an owner, shapes the site with the same rules:

Tool	What it does
`get_structure`	the definition of the site, its version, and the catalog of rules
`update_site`	replaces the definition, at the version read
`set_collection`	adds, replaces or removes one collection
`create_site`	makes a site, with you as its owner
`delete_site`, `restore_site`	put a site in the trash, and bring it back
`make_webhook_secret`	makes the secret that signs a webhook's deliveries

Each change is checked whole before anything is written, and every problem comes back at its path with its fix. One that touches existing entries answers needs_confirmation with what it would do; the agent sends it again with confirm: true once you agree. A change sent at a stale version answers conflict, so two people never overwrite each other.

The schema

A collection's schema is the JSON Schema of its frontmatter. A draft whose frontmatter does not fit is saved with an error in its verdict, and cannot be published until it fits. In the admin each field has a kind (text, date, choice, list of texts, number, yes or no), its bounds and whether it is required; anything else JSON Schema says is kept as it is.

Translations share names the field that ties the entries of one post in each locale.
Tags names the field that holds the tags, which list_entries filters by.
Newest first by names a date field: lists are newest first by it. Without it, by the date of first publication.

Some fields nobody should write by hand. Who writes it, on a date or a number field, lets Hollware fill it (automaticFields of the collection over MCP):

Hollware fills	With	A value written
`firstPublished`	the date the entry was first published	wins, so content moved from elsewhere keeps its dates
`lastModified`	the date of a change published after that	wins when it is later
`readingTime`	minutes, at 200 words a minute, the code blocks counted too	is ignored
`wordCount`	the words of the body	is ignored

Such a field is never required, the form of an entry leaves it out, and describe_site marks it readOnly so agents leave it alone. A site reads it filled, in the frontmatter, and hollware export --published writes it into the files; the Markdown Hollware keeps stays what was written. A new blog has its date filled this way.

Routes

The routes give the path of an entry in each locale, with :slug, such as /blog/:slug/ and /es/blog/:slug/. Links between entries are checked against them, and every locale of the site needs one.

Components

The body of an entry is Markdown with components, written as ::name{prop="value"}. Each collection declares the components it allows, with the JSON Schema of their props, a description and an example; any other component is an error. Agents read them with describe_site.

Rules

Rules come from a catalog, each with its parameters, such as a title of at most 60 characters unless a seoTitle is given; see Contracts.

Style guides

The style guide of a site and of each collection is Markdown for whoever writes. Hollware does not check it; agents read it with describe_site. Keep it short and concrete.

Note

A project made before 0.8 has a hollware.config.ts. Its Worker moves the config into the database on its first request after the upgrade, and never reads it again: from then on, shape the site in the admin.