Structured Content for LLMs and AI Agents

Structured content beats scraped HTML as agent input. The structure carries meaning the model would otherwise have to guess. A typed field says "this is the price." An HTML <div> says nothing. Benchmarks back this up, and they hold a surprise. Flat structure beats nested structure. Deep trees, the thing most CMS platforms sell as structured content, score worse than flat records. Draftbase ships typed fields plus a 26-tool MCP server, so we think about this shape a lot. Here's what agents read well, and what to hand them.

This post is about consumption. To design the model in the first place, see schema-driven content modeling.

Why do LLMs read structured content better than scraped HTML?

Two reasons, and only one of them is about tokens.

The token reason is well known. Raw HTML is mostly not content. Navigation, ad markup, script tags, and footer links often make up 40 to 60 percent of a page. All of it enters the context window. All of it costs money. None of it answers the question.

The second reason matters more. HTML says how a thing looks, not what it is. A price, a headline, and a cookie banner can all be a <div class="text-lg">. The model has to guess which is which from position and wording. Sometimes it guesses right. A named field skips the guess. The field is called price, so it's the price.

What does "structured content" mean to an agent?

Not the same thing it means to a content strategist.

To a strategist, it means the model is broken into meaningful pieces instead of one blob of formatted text. That's right, and it's the base.

To an agent, it means something narrower. Every value it needs is reachable by name, in one hop, with a type it can trust. entry.fields.price is 12 tokens and no doubt. Finding that price inside a rendered page is a search problem.

The underused angle: flat structure beats nested structure

Here's the finding that should change how you model content for agents.

NEXT-EVAL tested three input formats for LLM web data extraction. Slimmed HTML, hierarchical JSON, and flat JSON. Flat JSON won, with an F1 of 0.9567 and the least hallucination.

Read that ordering again. Flat JSON beat hierarchical JSON. Structure helped, but nesting hurt.

That's awkward for the industry. In CMS marketing, "structured content" usually means a deep node tree. A rich text document with blocks inside blocks inside marks is structured. It's also the exact shape the benchmark ranked below flat records.

So give an agent a flat map of typed fields, and prose as prose. Don't hand it a five-level tree and call it a favor.

Should you give an agent markdown or JSON?

Depends on which part of the content you mean, and the split is cleaner than it sounds.

Prose wants markdown. Headings, emphasis, lists, and links all survive. The syntax costs a handful of tokens. JSON was built to move data between machines, not to save tokens. Wrapping every paragraph in braces and quotes buys nothing for a block of text.

Fields want JSON. A price, a date, a status, a reference id. These need exact types and a strict shape, above all when the agent feeds them into a tool call.

Content	Format	Why
Article body	Markdown / MDX	Keeps hierarchy, near-zero syntax tax
Price, date, status	Flat JSON field	Exact type, no parsing
Author, category	Reference id	One hop to a full record
Rendered page	Neither	40 to 60 percent boilerplate

Most CMS platforms force one answer for everything. Store prose as MDX and structure as typed fields, though, and you land on the split the research points at. That's one reason the MDX vs rich text call matters more once agents read your content.

How do AI agents actually read content from a CMS?

Two paths, and they solve different problems.

The delivery API

A plain HTTP fetch, filtered and paginated. This is the right path when the agent knows what it wants.

const res = await fetch(
  "https://api.draftbase.co/delivery/entries?templateId=blogPost&limit=20",
  { headers: { Authorization: `Bearer ${process.env.DRAFTBASE_KEY}` } },
);

Fields come back named and typed. No DOM, no boilerplate, no extraction step.

Semantic search helps here too. Pass mode=semantic and the query matches by meaning, not keyword overlap. So "how do I reset my password" finds the login troubleshooting entry that never says "reset."

MCP

The delivery API assumes your code already knows which query to run. An agent often doesn't.

MCP flips that. The server lists its tools, and the model picks. Draftbase exposes 26 of them, covering everything the dashboard does. Listing entries, reading one, creating, updating, scheduling, rolling back. The write side has its own walkthrough: how to let an AI agent edit content.

The tool descriptions do real work. A tool named list_entries with a typed templateId parameter tells the model what's possible. No examples in the prompt needed.

What a good agent-facing content shape looks like

Four habits, and none of them require new infrastructure.

Name fields for what they hold, not where they render. price survives a redesign. sidebarValue doesn't, and it tells an agent nothing anyway.

Keep prose in one field. An agent that has to reassemble a paragraph from nine nested nodes will sometimes reassemble it wrong.

Return ids for references instead of inlining the whole related record. One hop is cheap. A fully resolved graph blows the context window on data nobody asked for.

Say what state the content is in. An agent quoting a draft as though it were live is a real failure mode, and a status field prevents it.

What goes wrong when an agent reads your content?

Four failures worth naming, because each one has a cheap fix.

The agent quotes a draft. Your API returns unpublished entries, the agent doesn't check status, and a customer gets told about a feature that doesn't ship for a month. Draftbase's delivery API sidesteps this by serving published content only. If yours doesn't, filter on status before the content ever reaches the model.

Nested references eat the context window. One entry resolves an author, who resolves an org, which resolves 40 other entries. The agent now has 60,000 tokens of graph and no room to think. Return ids and let it ask again.

A json field arrives shapeless. Free-form JSON blobs are the one field type a schema can't describe. The model guesses at the shape, and it guesses differently each run. Keep agent-facing data in typed fields.

Content drifts and the agent doesn't notice. A model that read your docs on Monday will happily answer from that snapshot on Friday. Cache with an expiry, or invalidate on a publish webhook. Freshness is a plumbing problem, not a prompt problem.

None of these are exotic. They're the same failures as any API integration, with a model in the loop that won't raise an exception when something looks off.

When structured content doesn't help

Worth saying plainly, because the pitch usually skips it.

If your content is one long essay, splitting it into fields buys you nothing. Some content really is just prose. Cutting it into 14 fields makes editing worse and retrieval no better.

Structure also doesn't fix stale content. An agent will quote a wrong price with full confidence if that's what the field says. Typed and correct are different things. Only one of them is your CMS's job.

And if an agent only ever reads your public site, a clean llms.txt and decent semantic HTML may be enough. Not every use case needs an API key.

Start with the fields you already have

Pick the content type an agent would touch first. Then check three things. Is every value it needs a named field? Is the prose in one field, not a tree? Does the response say whether the content is published?

Draftbase fits this because what it stores is already the shape the benchmark favors. Flat typed fields, MDX prose as a plain string, references as ids. REST, GraphQL, semantic search, and a 26-tool MCP server sit on top. The Hobby plan is free. The Startup plan is $49/mo, both on the headless CMS pricing page.