Public betaFree while in beta · no card required

Your agents can read your docs. Can they use them?

Update the source once, and your docs site, MCP server, Claude Skill, and llms.txt update with it. You maintain one folder of Markdown — not four pipelines.

Connect your repositorySee live sites
Static output you keepZero runtimeRuns in your CIYour AI key, never metered
← everything below comes from one push
docs.retidal.com/api/payments/createSearch… ⌘K
Getting started
Quickstart
Authentication
Payments
Create a payment POST
Retrieve a payment GET
List payments GET
Orders
Create an order POST
Webhooks
SDKs
TypeScript
Python
API reference → Payments
Create a payment

Creates a new payment and returns a client secret. Amounts are in the smallest currency unit.

Body parameters
amountinteger · required
Amount intended to be collected, in cents.
currencystring · required
Three-letter ISO currency code.
metadataobject
Set of key-value pairs to attach.
# Returns 201 with a client secret
POST /v1/payments
{ "amount": 2500, "currency": "usd" }
On this page
Body parameters
Response
Error codes
Idempotency
View as Markdown · Open in Claude
// You didn’t write this file. Your OpenAPI spec did.
{
  "name": "retidal-api",
  "tools": [
    { "name": "create_payment",
      "description": "Creates a new payment…",
      "inputSchema": { "amount": …, "currency": … } },
    { "name": "retrieve_payment", … },
    { "name": "create_order", … }
  ]
}

Your API, callable by agents

Every operation in your spec becomes a tool an agent can invoke — with the same names and schemas your reference pages show. You never maintain this file by hand.

docs.retidal.com/mcp.json
# Your users’ agents install this with one command
---
name: retidal-api
description: Create and manage payments and
  orders through the Retidal API.
---
# Retidal API
Authenticate with a bearer token, then create
payments with POST /v1/payments. Amounts are
in the smallest currency unit…

Your product, taught to agents

The skill is grounded in the same pages your human readers see — so an agent learns your product from the source of truth, not from a summary someone wrote last quarter.

docs.retidal.com/skill/SKILL.md
# What an agent sees instead of scraping your HTML
# Retidal API
> Payments and orders infrastructure.
## Docs
- [Quickstart](/docs/quickstart.md)
- [Authentication](/docs/authentication.md)
- [Create a payment](/docs/api/payments/create.md)
- [Webhooks](/docs/webhooks.md)

Your docs, readable by machines

Agents get one canonical index and a Markdown mirror of every page — no scraping, no guessing which div holds the content.

docs.retidal.com/llms.txt

In production

See it before you trust it

Don’t take a landing page’s word for it. Open the sites, fetch the llms.txt, view source.

The problem

Your API changed. How many files do you edit now?

the docs pagethe MCP configthe agent skillllms.txtthe SDK snippets…every release, by hand

Until one of them is wrong — and an agent confidently tells your customer how your API worked two versions ago.

You edit the files on the left. Everything on the right regenerates:

openapi.yaml — you edit this
paths:
  /v1/payments:
    post: createPayment
content/quickstart.mdx — and this
# Quickstart
Install the SDK and
create your first payment.
docs.json — and nothing else
{ "navigation": […],
  "template": "mint" }
reed build
Docs sitedist/
142 static pages
search index inlined
Markdown mirror per page
no runtime · host anywhere
MCP servermcp.json
{ "tools": [
  "create_payment",
  "retrieve_payment",
  "create_order" ] }
Claude SkillSKILL.md
---
name: retidal-api
description: Create and
manage payments…
---
llms.txt/llms.txt
# Retidal API
> Payments and orders
- /docs/quickstart.md
- /docs/api/payments.md

There’s no second pipeline to forget. All four artifacts come out of the same build, from the same source — keeping them in sync stops being a task on your list.

Docs as code

Catch the broken link in review, not in support

Every push builds. Every docs error lands as an annotation on the exact file and line, inside your pull request — your reviewer sees it, your users never do.

And when something does break, you’re not grepping prose: every error is a stable code with a documented cause and fix. You diagnose each mistake once, ever.

reed / buildcompleted in 31s
DS-0412
content/api/payments.mdx · line 14
Link target does not exist: /api/refunds. Did you mean /api/payments/refunds?
DS-0207
docs.json · navigation[2]
Page “webhooks-legacy” is referenced in navigation but has no source file.
PREVIEW
pr-142.retidal.reedbuild.dev
Preview deployment ready — built from this pull request’s head commit.

Static output

Your docs shouldn’t have a landlord

Every build writes plain HTML, CSS, and JavaScript to an output directory in your project — search index included, no external requests at runtime.

Put it on S3, nginx, Cloudflare, GitHub Pages. The output keeps serving from wherever you put it, with or without Reed.

Prefer not to depend on our builders at all? The compiler runs in your CI. MIT-licensed, all the way down.

$ reed build
142 pages compiled · 1.4s
search index inlined · pagefind
mcp.json · SKILL.md · llms.txt
dist/ 142 files · static · yours
$ aws s3 sync dist/ s3://docs  # or nginx, Pages, …
The site in the hero is Retidal’s production API. The whole 314-operation spec, rendered in one build — no hand-fixes afterward. Open it yourself →
314operations rendered
39tags · OpenAPI 3.1
0rendering errors

Included

The chores that come with docs, already handled

PR preview deployments

Your reviewers click a URL, not a checkout. Every PR builds from its own head commit.

Builds that don’t need the network

Your CI stops failing because a registry had a bad day. After one prefetch, builds run fully offline.

Docs next to your code

Point a site at a subdirectory of your monorepo. Only pushes that touch it rebuild.

Errors you never diagnose twice

Stable DS-codes with documented fixes — searchable and linkable, not prose to grep.

Your brand without a fork

Three templates share one token contract. Restyle with CSS variables, keep getting updates.

Your domain, handled

A subdomain now, your own domain when you’re ready — certificates managed for you.

Migration

You already wrote your docs. Don’t write them again.

The Fern importer reads the files you have today: your content lands unchanged, your config is translated, and what it could not carry over is reported as a warning. Coming from Mintlify, the translation is manual — the differences are documented field by field.

Coming from Fern

fern.config.jsondocs.json
your MDX pagesunchanged
your navigationtranslated
your OpenAPI refsunchanged
Verified page-by-page against real Fern projects — you see the fidelity report before you switch anything off.
Migration guide

Coming from Mintlify

your docs.jsontranslated by hand
your MDX pageskeep their paths
your componentschecked against the catalog
your redirectsre-declared in docs.json
There is no --from mintlify importer. The migration page lists the field-level schema differences you translate yourself.
Migration guide

Pricing

Three sites are included during Reed’s public beta

Public beta current
$0 · no card required
Sites3
Build minutes200 / month
Site size200 MB
Custom domainsincluded
MCP · Skill · llms.txtincluded
PR preview deploysincluded
Connect your repository

Checked on 4 August 2026: Fern Hobby is $0 with one site, Fern Team is $150 / mo with one site, Mintlify Starter is $0 with no AI credits, and Mintlify Pro is $450 / mo billed annually or $540 / mo billed monthly. Verify current prices before purchasing.

Reed is free during the public beta. Post-beta prices and plan limits have not been decided. The quotas listed here are the current limits, and Reed does not charge per seat during the beta.

AI features run on your key. Reed does not resell or meter model usage.

Your docs are already in the repo. Connect it.

Connect a repository and Reed builds the docs site, an MCP server, a Claude Skill, and llms.txt from it.

Get started free