Supported Content Blocks
Understand the current canonical blocks and inline marks by writing purpose, not just by name.
Anydocs currently exposes 11 canonical block types, heading and list variations, and 5 inline marks. The important part is not memorizing names, but knowing when to use structural blocks versus lightweight inline emphasis. For both user delivery and AI delivery, clear canonical content structure is much more valuable than leaving behind markdown-only placeholder text.
Structure and narrative blocks
The core structure blocks are `paragraph`, `heading`, `list`, and `blockquote`. In practice, `heading` carries levels 1-3 and `list` carries `bulleted`, `numbered`, and `todo` styles. The most common ones are paragraphs and H2/H3 headings. The reader extracts TOC entries from heading levels 2 and 3, so those headings should carry most of the page structure.
- Use `heading` level 1 only when you truly need an in-body title
- the reader already shows the page title separately
- lists are good for steps, options, and checks, not for replacing heading hierarchy
Technical explanation blocks
Technical blocks include `codeBlock`, `codeGroup`, `table`, and `mermaid`. When you are writing install commands, config snippets, API calls, parameter matrices, or process descriptions, prefer these structured blocks instead of stuffing everything into paragraphs.
- `codeBlock` is for a single language or single command example
- `codeGroup` is for equivalent examples across languages or package managers
- `table` is for parameters, fields, and version comparisons
- `mermaid` is for flowcharts, state diagrams, and simple sequence diagrams
Emphasis and presentation blocks
Presentation-oriented blocks include `callout`, `image`, and `divider`. Inline `link` nodes belong inside surrounding text. Use these tools for emphasis, visual support, and reading-rhythm separation, not as the main document structure.
- `callout` is for warnings, notes, and publication boundaries
- `image` is useful for screenshots, diagrams, and visual references
- inline `link` nodes are for ordinary references inside text, not a separate page-layout primitive
- `divider` should be used only when a visible section break is genuinely helpful
When to use inline marks
The current inline marks are `bold`, `italic`, `underline`, `strike`, and `code`. They are only for local emphasis and should not replace block-level structure. For command names, parameters, paths, env vars, and short identifiers, prefer inline `code`; for longer material, switch to a standalone code block.
Minimum standard for AI authoring
If an agent writes pages through MCP, prefer canonical `DocContentV1` blocks or template-based inputs instead of plain markdown strings. `page_create_from_template` and `page_update_from_template` are often more reliable than hand-assembling large content payloads. If you must write `content` directly, keep every block type inside the allowed canonical list.