Search Docs

Search through documentation...

OpenStatus Logo

For AI Agents

Most decisions about which data table to use now happen inside an agent's context window. These endpoints exist so an agent can read the library, pick the right blocks, and wire them up without guessing.

Machine-readable endpoints

EndpointWhat it is
/api/mcpThese docs as an MCP server — see below
/llms.txtIndex: blocks, install recipes, links to every page
/llms-full.txtEvery documentation page inlined in one file
/r/index.mdBlock catalog with install commands and dependencies
/r/registry.jsonThe shadcn registry manifest
/docs/<page>.mdAny docs page as raw markdown

Every docs page has a Copy as markdown button, and appending .md to any docs URL returns the source — /docs/drizzle-orm.md, for example. Agents fetching the rendered HTML pay several times the tokens and lose code-fence fidelity on the way through.

Ask the docs instead of reading them

The endpoints above hand an agent pages. /api/mcp serves the same content as an MCP server, so the agent asks a question and gets back the section that answers it — a targeted section costs a fraction of the page it lives in, and the page costs a fraction of llms-full.txt.

claude mcp add --transport http data-table-filters https://data-table.openstatus.dev/api/mcp

Any MCP client works — it speaks Streamable HTTP, needs no auth, and holds no session:

{
  "mcpServers": {
    "data-table-filters": {
      "type": "http",
      "url": "https://data-table.openstatus.dev/api/mcp"
    }
  }
}

Four read-only tools:

ToolAsk it
get_install_plan"I need a table over 2M Postgres rows" → the exact shadcn command
search_docs"how do faceted counts work" → the sections that answer it
get_docA page in full, or one section of it, as markdown
list_blocksThe catalog: what each block adds and when it applies

Start with get_install_plan — it returns the command, the wiring notes, and the pages to read next, which is the whole decision an agent has to make before it writes any code.

This is the docs server. The data-table-mcp block is the other direction: it turns your table into an MCP endpoint so agents can query your data.

Agent rules and skills

Claude Code — install the plugin, which ships the full skill with reference docs for every block:

/plugin marketplace add openstatushq/data-table-filters
/plugin install data-table-filters@openstatus

Any agent with the skills CLI:

npx skills add https://github.com/openstatushq/data-table-filters --skill data-table-filters

Cursor — copy .cursor/rules/data-table-filters.mdc into your project.

Everything elseAGENTS.md in the repository root covers both using the library and contributing to it.

Then describe what you want:

Add a filterable table for my logs Postgres table with server-side filtering and infinite scroll

Install recipes

Large table — 100k+ rows, filtered in SQL

npx shadcn@latest add \
  https://data-table.openstatus.dev/r/data-table.json \
  https://data-table.openstatus.dev/r/data-table-schema.json \
  https://data-table.openstatus.dev/r/data-table-cell.json \
  https://data-table.openstatus.dev/r/data-table-sheet.json \
  https://data-table.openstatus.dev/r/data-table-drizzle.json \
  https://data-table.openstatus.dev/r/data-table-query.json \
  https://data-table.openstatus.dev/r/data-table-nuqs.json

Define the table once with createTableSchema, pass it to createDrizzleHandler in a route handler and to createDataTableQueryOptions on the client. Filtering, faceted counts, sorting, and cursor pagination execute in SQL, and rows are virtualized — the client only ever holds the pages it rendered.

Client-side table — data already in memory

npx shadcn@latest add \
  https://data-table.openstatus.dev/r/data-table.json \
  https://data-table.openstatus.dev/r/data-table-cell.json \
  https://data-table.openstatus.dev/r/data-table-sheet.json

Use useMemoryAdapter. No API route and no schema block required.

Unknown data shape

Install data-table and data-table-schema, then render <DataTableAuto data={json} /> — see Auto-infer.

Why the schema matters for agents

One createTableSchema definition drives six surfaces:

  1. Column definitions and cell renderers
  2. Filter controls
  3. The row detail sheet
  4. The server-side query handler
  5. The natural-language filter parser
  6. The MCP tool schema

An agent writing a table from scratch has to keep those six in sync by hand, which is where hand-rolled tables quietly go wrong. Here the schema is written once and everything else is derived from it.

Expose your table to agents at runtime

The docs above are for agents that build the table. The data-table-mcp block is for agents that query it: it turns the same schema into an MCP endpoint, so an agent can filter and page through your data with typed parameters.