kapa.ai

Kapa.ai Documentation Audit

A RAG/AI-search vendor whose own docs are missing the things they sell to others: a machine-readable index, complete endpoint reference pages, and consistent terminology across surfaces. The product story and integration guides are strong; the developer reference layer underneath them is thin and contradictory.

1. No llms.txt or llms-full.txt published (critical)

Location: https://docs.kapa.ai/llms.txt and https://docs.kapa.ai/llms-full.txt

Problem: Both URLs return HTTP 404. Kapa sells a product whose explicit pitch includes "Give Context to AI Coding Agents" via MCP, and whose docs index talks about being machine-parseable, yet the company has not published the de-facto agent-discovery files for its own documentation.

Consequence: Coding agents (Claude Code, Cursor, Codex, Copilot) trying to programmatically discover Kapa's docs have to fall back to crawling HTML or web search, which is exactly the inefficiency Kapa's own product page argues against. It also undercuts every sales narrative about "documentation built for AI."

The fix: Publish llms.txt at the docs root with a curated map of high-value pages (API overview, quickstart, auth, every reference endpoint, SDK quickstarts), plus an llms-full.txt containing the full reference content. Mirror the structure Anthropic, Mintlify, and others already use.

2. API reference pages are placeholder shells (critical)

Location: /api/reference/chat, /api/reference/chat-streamed, /api/reference/query-v-1-projects-chat, /api/reference/query-v-1-projects-chat-chat-stream, /api/reference/retrieval, /api/reference/feedback

Problem: The scraped content for these pages contains only narrative descriptions ("Chat with your kapa.ai instance. It creates a new Thread object…"). Request bodies, response schemas, headers, error codes, and code samples are absent. The /api/reference/query-v-1-projects-chat page explicitly reads as "a documentation index rather than the full endpoint reference page." /api/reference/retrieval is a single paragraph pointing at itself.

Consequence: A developer (or agent) trying to call POST /query/v1/projects/{project_id}/chat/ cannot learn from the docs what fields the body takes, what comes back, what 4xx codes mean, or how to handle errors. They have to reverse-engineer from the SDK source or contact support — for the company's flagship endpoint.

The fix: Publish full OpenAPI-rendered reference pages with: request schema (with field types, required/optional, defaults), response schema, all status codes including the documented 429, example request in curl + Python + TypeScript, and example success/error response bodies. Link the underlying OpenAPI/JSON Schema spec from the page so agents can fetch it directly.