---
title: AI, MCP and skills
description: Understand why Quilium exposes an MCP server and a skills library, so you can decide where an AI agent fits in your workflow and what to expect when one builds alongside you.
updated: 2026-06-22
---
## Why this page exists
Most CMSs treat AI as a feature bolted on the side: a "write me a paragraph" button, a chat box that drafts copy. Quilium takes a different stance. An AI agent like Claude is a **first-class operator** of the site, on the same footing as a developer or an editor.
This page explains the design rationale, the **why** behind that choice and the mental model that makes working with agents productive. It is not a how-to. When you want to actually connect an agent or write good prompts, follow [Connect an agent over MCP](/en/docs/connect-agent-mcp) and [Prompting well for Quilium](/en/docs/prompting), or take the [AI tutorial path](/en/docs/ai-setup). If you would rather not connect anything, the CMS already ships [an integrated assistant](/en/docs/integrated-ai-agent).
## One site, two kinds of operator
The core idea is simple: a human and an agent drive the **same CMS through the same operations**. There is no second, dumbed-down API for the AI and no privileged back door either. Creating a page, adding a content block, defining a `content-type`, uploading media, publishing, all of it is the same set of typed operations whether a person clicks through the CMS, a developer scripts the CLI, or an agent calls a tool.
We designed it this way on purpose. A site built by an agent is a normal Quilium site: a developer can open it, understand it, and keep working on it by hand. A site built by hand can be extended by an agent without a migration. The two paths converge on one [content model](/en/docs/content-model) and one [architecture](/en/docs/architecture).
Same operations, not the same speed. An agent is not faster at deciding what to build, it is faster at executing the mechanical steps once the decision is made. The thinking stays with you.
## The MCP server: typed operations an agent can call
[MCP](/en/docs/ai-mcp-skills) (Model Context Protocol) is the open standard that lets an AI agent call tools exposed by a server. Quilium ships an **MCP server** that turns every CMS capability into a typed operation: read the site context, fetch a page with its content, create a collection entry, update a field, reorder navigation, generate an image, and so on.
Think of the MCP server as the **same verbs a developer already uses, made callable by an agent**. When an agent adds a content block, it sends the same payload shape a developer would, the [wrapper rule](/en/docs/content-model) included: a content block's data goes in `custom: {}`, a collection entry's in `data: {}`. The agent does not get a softer contract. If it sends the wrong wrapper, it gets the same 422 a script would.
That symmetry is the point. Because the agent operates through typed operations rather than free-form HTML generation, its work is **structured, inspectable, and reversible**. You can read exactly what it changed, and you can change it back.
Placeholder: diagram, agent ↔ MCP server ↔ CMS data model. Show the agent calling typed operations on the MCP server, and the server reading/writing the same pages, content blocks and collections a developer touches through the CLI. To produce from the fil-rouge demo site.
## The skills library: task knowledge for agents
Knowing the operations is not the same as knowing **how to use them well**. A typed call to create a `content-type` tells you nothing about whether a bullet list should be a `wysiwyg` field or a `repeat`, when a section deserves its own collection, or how translations must be written one locale per call. That knowledge is what the **skills library** carries.
A skill is an atomic, self-contained guide that encodes one canonical Quilium pattern, the kind of thing a senior developer would otherwise have to explain. Skills are **knowledge modules for agents**, loaded on demand based on what the agent is trying to do, never all at once.
This library is served by the MCP server and consumed by the agent alone. You do not install it or pick from it, and that is deliberate: knowledge that lives on the server is knowledge that cannot go stale on someone's laptop. Two *installable* skills exist alongside it, `quilium-builder` and `quilium-webmaster`, and they cover a different territory — the process around the CMS rather than the CMS itself: the order a whole site gets built in, the CLI loop, the Liquid layer. Those you add to your project once, with `npx skills add quiliumio/quilium-skills`. The distinction is worth holding on to, because both are called skills: **you install two, the agent fetches fifty.**
### How skills are organised
The library is a three-level taxonomy, browsed by an agent through two operations: `get-skills` returns the whole catalog as groups, categories and leaf skills (each with a slug and a "load when…" description); `get-skill ` returns the full guide for one of them. There are five kinds of skill, each answering a different question:
| Skill kind | Answers | When an agent loads it |
|---|---|---|
| `meta` | How does the library itself work? | Once, before anything else |
| `reference` | What is the exact syntax or catalog of X? | On a syntax doubt |
| `practices` | How do I do X well? | About to do X |
| `tasks` | What atomic capability can I perform here? | Matching a single user intent |
| `processes` | How do I orchestrate a multi-step workflow? | A multi-step request |
### A task usually needs several skills
A real task rarely maps to one skill. Adding a collection of articles, for instance, pulls in a `practices` skill for deciding the right shape, `reference` skills for field types and routing, and a `practices` skill for the MCP call mechanics. The agent composes them. The library is built around this: each skill declares the others it relates to, and the agent follows those links rather than working from a single guide.
That composition is enforced by one rule we treat as load-bearing: **never duplicate the canonical patterns**. A skill that needs another skill's content references it, it does not copy it. Copies drift; when a pattern changes, every stale copy becomes a quiet source of wrong output. By keeping each pattern in exactly one place, the whole library stays consistent, and so does what agents produce from it.
## The typical multi-agent flow
When an agent builds a Quilium site from a prototype, the work tends to split along the same seams a human team would use. A common arrangement, **illustrative, not prescriptive**, is three roles:
1. **An architect agent decides the structure.** It reads the prototype, inventories the distinct sections, and maps them to page-types, content-types and collections. This is the high-judgement phase, what is reusable, what is a collection, where each thing lives.
2. **A template agent writes the [Liquid](/en/docs/templating-philosophy).** With the structure fixed, it scaffolds the layouts and element templates that render each type, wiring fields and queries to the data model.
3. **A content agent fills the site.** It ingests the prototype's real content into pages, content blocks and collection entries through the MCP server.
Placeholder: diagram, the typical multi-agent flow, architect agent (decides structure) → template agent (writes Liquid) → content agent (fills content), with a "human review" gate before publishing. Mark the flow as one example arrangement, adaptable, not a fixed pipeline. To produce from the fil-rouge demo site.
Treat this as a useful default, not a contract. One agent can wear all three hats on a small site. A complex project might split the roles further or loop back, the architect revising the model after the template agent hits a wall. The value is in the **separation of concerns**, structure, rendering and content are genuinely different kinds of work, not in the exact number of agents.
## Guardrails: agents build, humans publish
Letting agents operate the CMS only works because of where we draw the line. The design assumes a human stays in the loop at the moments that matter.
- **Page work happens in draft.** Agents create and edit pages without publishing them, so nothing they do to a page is live by default. Collection entries have no draft state, which is why an agent is told to show the first entry before writing the rest.
- **Publishing is a human decision.** Agents do not auto-publish. `publish-page` is never called on an agent's own initiative, it waits for explicit human confirmation. This is a deliberate rule in the skills library, not an afterthought.
- **Changes are inspectable.** Because every agent action is a typed operation on structured data, you can review exactly what changed before it ships, page by page.
The agent proposes, you dispose. An agent can build an entire site and hand it to you ready to review, without publishing a single page. Going live is always your call, by design.
## Why the skills library is not end-user documentation
You will not find the skills library in this documentation, and that is intentional. The skills are **agent tooling, not a public catalog**.
The audience is the difference. This documentation explains Quilium to *you*, a developer or designer reasoning about how to build. A skill exists to keep an *agent* grounded on a canonical pattern at the moment it acts, its descriptions are written for intent-matching by a model, not for reading. Exposing them as a public reference would invite two mistakes: treating an absent skill as "Quilium can't do this" (the library is not exhaustive), and reading agent-internal phrasing as a stable API contract (it evolves with the platform). The skills library is read through `get-skills`, not crawled, and it is deliberately kept out of the public index.
So the split is clean: **this doc is the why and the how for humans; the skills library is the how, in-context, for agents.** They cover the same platform from two sides, and you only need this one.
## Where to go next
- [What is Quilium](/en/docs/what-is-quilium), the two ways to build and the three building blocks.
- [The content model](/en/docs/content-model), the data model agents and developers share.
- [Quilium's architecture](/en/docs/architecture), how the pieces fit and render.