Markdown got popular for a reason that has nothing to do with safety: it's fast to type by hand. Fewer symbols, less shifting between keys, a format a person can hold in their head. That's a real, useful property — for a human typing.

An LLM writing through MCP tool calls isn't typing by hand. It doesn't benefit from fewer symbols, and it doesn't get tired of angle brackets. So the actual question isn't "what's fastest to type" — it's "what can be checked." That's why Carapace's content is HTML, not Markdown: a small, fixed set of tags and attributes that can be validated, not a looser format optimized for a constraint that doesn't apply here.

## The problem with just rejecting bad input

An allowlist alone solves half the problem. The other half is: how does the model know what's allowed *before* it writes something and gets rejected? Guessing and getting corrected works, technically, but it's slow, and it means every session starts from zero.

The `carapace://style-guide` resource exists to close that gap. It's a live MCP resource — not documentation that can drift out of date, but the actual sanitizer's own allowed tags, attributes, and class vocabularies, served as data. A connected model reads it before writing, the same way it would check a schema before calling any other tool.

> The resource can't lie about what's allowed, because it's generated from the same rules that enforce what's allowed. There's no separate documentation step where the two could drift apart.

## Components work the same way

This generalizes past plain tags. Carapace ships a small set of purpose-built components — a video embed, a handful of layout primitives for structure — and a `describe_components` tool that lists exactly what exists, what parameters each one takes, and a real usage example. A model composing a page discovers `<video-embed>` the same way it discovers which HTML tags are safe: by asking, not by guessing at a raw `<iframe>` and getting rejected.

None of this makes the vocabulary bigger than it needs to be. Growth still happens by adding something specific and named — a new component, a new enumerated class — never by loosening what raw markup can already do. The style guide just means the model finds out what's available by reading, instead of by trial and error.