Dual representation
The core invariant — every superlore component renders for humans and serializes a typed knowledge face for the MCP, from one authored instance.
This is the core invariant of superlore, and the reason it isn't just another docs generator: every component has two faces, produced from one authored instance.
Render face
A polished React component for the human site — tokens only, light and dark co-equal, accessible.
Knowledge face
A typed serialization the MCP exposes to agents — the records and relations behind the visual, never a description of a picture.
Why it matters
Existing tools render pages for people and retrofit an MCP over the scraped output. Their
components are render-only; the agent gets HTML it has to interpret. superlore inverts this: the
structured index is the source of truth, and both faces are projections of
it. A Timeline is never a picture an agent must squint at — the agent gets the items behind it.
Author the data
<Timeline items={[...]} />, <EntityCard fields={[...]} />, <DataTable rows={[...]} />.
The agent reading your KB later gets clean, typed records.
Not a picture
Don't paste a screenshot of a roadmap or describe a table in prose. That data becomes invisible to agents and unsearchable.
The contract for component authors
Implement both faces
If you add a component, you implement the render face and the knowledge face. A component that can't serialize to the MCP isn't done.
One source, no duplication
Both faces come from the same props. You never write the data twice; there's nothing to keep in sync.
Type the knowledge face
The serialization is typed ({ kind: "timeline", items: [...] }, and so on) so get_component_data
returns a stable shape an agent can rely on.
See it end to end
The full component catalog shows each knowledge face alongside its render. The structural differentiators each carry a typed face you can query over the MCP: