---
title: One source, every surface
description: What Reed emits besides a website, and why it comes from one representation.
---

A documentation site is one way to read your docs. It is not the only one that matters
now: agents read `llms.txt`, tools call MCP servers, and Skill packs carry your prose into
an agent's context.

Reed emits these from **one intermediate representation** — a per-page document plus an
OpenAPI-derived capability layer — rather than deriving each surface from another.

## Why that matters

The alternative is what most stacks do: build the site, then scrape the site to make the
machine-readable version. That works until the HTML changes, and it silently bakes
presentation decisions into data.

Deriving every surface from one representation means the surfaces cannot disagree about
what your documentation says. When a page changes, everything changes with it, in one
build.

## The surfaces

<CardGroup cols={2}>
  <Card title="llms.txt" href="/docs/derived/llms-txt">
    Your whole site as one plain-text file, with a markdown mirror per page.
  </Card>
  <Card title="MCP server" href="/docs/derived/mcp">
    A tool set derived from your OpenAPI spec, written into your repository.
  </Card>
  <Card title="Agent Skill" href="/docs/derived/skill">
    A Skill pack, optionally bundling pages of your own prose.
  </Card>
</CardGroup>

## What is generated when

`llms.txt` and the markdown mirrors are written by every `reed build`. They need no
configuration.

The MCP server and the Skill pack are generated by explicit commands, need their own
config blocks, and write into your repository rather than into the built site. They are
not part of a deploy.

## The output is yours, in every case

None of these surfaces calls back to Reed at runtime. The site is static files; the MCP
server is source you own and host; the Skill pack is a directory you commit. This is the
same property throughout: **the artifact survives Reed.**