LEDRIC

ledric is a self-hosted content engine designed from the ground up for the agent era. The same content store powers three distinct surfaces:

• Humans edit through a SvelteKit admin GUI, or via a click-to-edit overlay dropped on the live site itself.
• Agents edit through MCP — twenty structured tools that mirror the admin API, with describe_model so an LLM can learn the entire content model in a single call.
• Sites read through a thin HTTP API or typed SDKs (TypeScript and PHP).

Everything goes through the same validation, the same versioning, the same slug-history. There is no separate "agent track" with looser rules — Claude and your marketing lead are both calling the same draft underneath.

For the longer story, read the Concepts page for the mental model, or Why ledric for honest comparisons against Contentful, Sanity, Payload, Strapi, and Directus.

A typical project has three moving parts: a content type, a daemon serving it, and a consumer that reads from it.

1. Describe a content type

Either ask Claude ("add a blog_post type with title, slug, body, cover image, and tags") or write it by hand. Either way, the schema lives in the same database as the content — no separate config files to keep in sync.

defineType("blog_post", {
  title: { type: "string", required: true, max: 160, searchable: true },
  slug:  { type: "slug", from: "title" },
  body:  { type: "markdown", searchable: true },
  cover: { type: "asset", kinds: ["image"] },
  tags:  { type: "array", of: { type: "string" } },
});

2. Edit content

Humans use the admin GUI, or click any element on the live site — the inline editor opens the right form in a drawer. Agents call draft and publish over MCP. Both paths write to the same store, with the same validation rules and the same parent_version optimistic concurrency. Drafts and published versions live side-by-side; renaming a slug retires the old one but reads keep resolving forever via 301.

3. Read from your site

Your site fetches over plain HTTP — the typed SDKs save boilerplate but they're optional. The wire shape is identical from TypeScript and PHP.

// TypeScript
import { LedricClient } from "@ledric/sdk";
const ledric = new LedricClient({ url: process.env.LEDRIC_URL! });
const posts = await ledric.find("blog_post", { limit: 10, published: true });

// PHP
use Ledric\LedricClient;
$ledric = new LedricClient(getenv('LEDRIC_URL'));
$posts  = $ledric->find('blog_post', ['limit' => 10, 'published' => true]);

For the full walkthrough — schema, seeded content, an Astro frontend, inline-editor wiring — see Build with an agent (TypeScript) or Build with an agent — PHP.

After 25 years building bespoke content systems for clients — pre-headless-CMS days through the major players since — ledric is the data layer I'd actually want to use.

Most pages I build aren't "title, body, hero image." They're collections of sections: a hero with desktop and mobile backgrounds, a pricing table reused across three pages, a testimonials block, a CTA, a feature grid — sometimes with prose flowing around them, sometimes entirely composed of them.

A typical session against the MCP server looks like:

1. "Go through this page design in Figma and prepare all required asset exports."
2. "Import all assets into ledric, tagging them appropriately."
3. "Build out the required sections, and roll them into a page."

Without ledric in the loop, Claude could write static HTML and call it a day. ledric exists because I want my marketing team to roll out updates without me — and I want them to wire up their own LLM tools to the same content store.