Why a Litepress Markdown extension has two parts

At first glance, it seems unnecessary for a Markdown extension to have both frontend and backend parts. Why not have one definition, one registry, and one file that explains everything? Because an extension does not live in one runtime.

When an author uses a semantic block in Litepress, such as a newsletter form, that same block appears in several contexts. In the editor it needs a button, a popup, help, preview, and enough metadata for an AI agent to create it correctly. On the backend, the same block needs a model, validation, SSR behavior, assets, consent rules, and an integration contract.

A Litepress extension is not only a render function. It can describe itself: which parameters it expects, what valid Markdown looks like, what each field means, and when the block makes sense.

That is useful for humans, but it is also important for AI workflows. An LLM can receive concrete rules and structure from the system instead of guessing syntax from examples or prompt folklore.

That is the difference between adding AI as a surface feature and exposing a semantic system through MCP instructions that an agent can actually understand.