bitHuman docs

Official2 tools

by bithuman-product · JavaScript

The bitHuman docs over MCP: two read-only tools, search and fetch; it needs no account and no key.

ai.bithuman/docs MCP Server

The ai.bithuman/docs MCP server exposes documentation access over the Model Context Protocol (MCP). It provides two read-only tools—search and fetch—for locating and retrieving content from the bitHuman docs. It operates without requiring an account or an API key.

🛠️ Key Features

MCP server for bitHuman documentation
Two read-only tools: search and fetch
No account required
No API key required

🚀 Use Cases

Searching within the bitHuman docs
Fetching specific documentation content after discovery

⚡ Developer Benefits

Simple integration via two focused, read-only tools
Authentication-free usage (no account or key)
Supports developer workflows needing doc lookup and retrieval

⚠️ Limitations

Only documentation access is described
Tools are read-only (no updates or write operations)

Topics

astrodocumentationopenapistarlightpublic

Captured live from the server via tools/list.

search

Search docs.bithuman.ai (bitHuman real-time avatar SDKs, the REST API, deployment options, models, pricing). Returns the best-matching pages, each with an id to pass to `fetch`.

Parameters3

query	string	required	What to look for, e.g. "Android first frame" or "LiveKit secret".
section	string	optional	Limit to one section.
limit	integer	optional	How many results (default 8).

Raw schema

{
  "type": "object",
  "properties": {
    "query": {
      "type": "string",
      "description": "What to look for, e.g. \"Android first frame\" or \"LiveKit secret\"."
    },
    "section": {
      "type": "string",
      "description": "Limit to one section.",
      "enum": [
        "Overview",
        "Platforms",
        "Models",
        "Guides",
        "Deploy",
        "Performance",
        "API reference",
        "Get started",
        "Resources",
        "Build",
        "API"
      ]
    },
    "limit": {
      "type": "integer",
      "minimum": 1,
      "maximum": 20,
      "description": "How many results (default 8)."
    }
  },
  "required": [
    "query"
  ]
}

fetch

Fetch one docs page as markdown by the id `search` returned (a path such as /platforms/python), or by its full URL.

Parameters1

string

required

A page path (/platforms/python) or URL (https://docs.bithuman.ai/platforms/python).

Raw schema

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "A page path (/platforms/python) or URL (https://docs.bithuman.ai/platforms/python)."
    }
  },
  "required": [
    "id"
  ]
}

README.md5 KBView on GitHub

bitHuman developer docs

Source for docs.bithuman.ai — bitHuman's developer platform. A custom Astro 6 site styled after developers.openai.com (semantic design tokens, light/dark, Shiki code, brand coral #FF5757 + Roboto). The API reference at /api/reference is rendered from the OpenAPI spec at build time, with no third-party script.

Local dev

bash

nvm use            # Node 22+ (Astro 6); see .nvmrc
npm install
npm run dev        # http://localhost:4321
npm run build      # static output -> dist/

Structure

code

src/
  content/docs/          The markdown pages; the file path is the URL
  config/nav.ts          Sections, sidebar groups, header, Resources menu, footer
  data/                  One source per fact: versions, pricing, platforms, demo avatars, offline copy
  layouts/               Base (head, nav, footer) and DocLayout (sidebar, chips, Next, pager)
  components/            Card, Chip, LiveDemo, CodeTabs, QuickstartPicker, PlatformSwitcher and the rest of the design system
  scripts/               The small browser scripts: tab and platform state, the explorer, the calculator, filters
  lib/                   Build-time helpers: data blocks, the OpenAPI reader, the curl → Python and Node generator
  styles/                tokens.css (light/dark tokens), components.css, prose.css
  pages/                 The home page, /start, the hubs, llms files and markdown twins
  openapi/bithuman.yaml  OpenAPI spec -> synced to public/api/openapi.yaml
scripts/                 The gates ci/run-local.sh runs, and the generators (redirects, versions, pricing)
STYLE.md                 The style guide: voice, terminology, claims, templates, budgets

Information architecture

Organized by the developer's question. The header is Get started · Platforms · Deploy · Models · Build · API · Performance, then Resources.

Get started (/start): the quickstart, the API secret.
Platforms (/platforms): iOS & iPadOS, Android, Web, Python, the CLI, LiveKit, REST, and the SDK references.
Deploy (/deploy): the bitHuman cloud, your servers, on the device, CPU only (no GPU), fully offline, pricing, and the use-case guides (/deploy/use-cases).
Models (/models): Essence 2, Expression 2, the first generation, how it works, the avatar file.
Build (/build): create your own avatar, persona, voices, recipes, and the example gallery (/examples).
API (/api), Performance (/performance), Resources (/resources).

A page that moves gets a row in scripts/ia-map.json; node scripts/gen-redirects.mjs regenerates the redirects in vercel.json, and ci/run-local.sh checks them before merging (--served after each deploy).

API reference

The reference at /api/reference is generated from src/openapi/bithuman.yaml (OpenAPI 3.1) — npm run sync-openapi copies it to public/api/openapi.yaml (runs automatically on dev/build). Edit the spec; no hand-written endpoint pages.

Deploy

GitHub push → Vercel build (project public-docs) → preview URL. DNS for docs.bithuman.ai is swapped to this project only once the rebuild is approved.

★ A push can succeed while the site keeps serving the old build

Verify a publish by fetching the live HTML, never by reading the Vercel status. This has bitten us: the push lands, the dashboard goes green, the deployment is marked Ready — and docs.bithuman.ai keeps serving the previous build. A green status says a build finished; it does not say the domain is pointing at it. The two failure shapes we have actually seen are an alias that never moved to the new deployment, and a cached HTML response served ahead of it.

So the last step of publishing is not git push. It is:

bash

# 1. Note the commit you pushed.
git rev-parse --short HEAD

# 2. Fetch the LIVE page — cache-busted — and grep for a string that exists
#    only in the new build. Pick a distinctive sentence from your own diff.
curl -sS "https://docs.bithuman.ai/models/essence-2?cb=$(date +%s)" \
  | grep -c "head-upsample"

# 3. Zero means the site is still serving the old build. Investigate the alias
#    before telling anyone the change is live.

Do the same for /llms.txt and /sitemap.xml when the change adds or removes a page — they are generated at build time and are the quickest signal that the build you are looking at is the build you pushed.

A page that carries a TKTK marker is not publishable at all — ci/run-local.sh is red until the marker is resolved (scripts/check-placeholders.mjs), and drafts/ holds page-sized text whose subject is not yet true. See drafts/README.md.

Install

Tools (2)

searchfetch

Remote endpoint

Streamable HTTP

Hosted server - connect over the network, no local install.

url

https://docs.bithuman.ai/docs-mcp

Add to VS Code Add to Cursor

claude_desktop_config.json

json

{
  "mcpServers": {
    "docs": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://docs.bithuman.ai/docs-mcp"
      ]
    }
  }
}

Desktop config is stdio-only; this bridges via mcp-remote. Native remote: Settings > Connectors.