---
title: Configure your content
description: Shape your sites and collections in the admin or over MCP, with a schema, routes, rules and a style guide, and no deploy.
section: guides
order: 1
---

# 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:

```sh
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](/docs/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.

::callout{type="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.
::