Skip to content

Choosing an SDK

View Markdown

Every client below speaks the same HTTP API and authenticates with the same stack API key. You can load data with one client and query with another, on the same graph.

The first-party SDKs (@littlebigbrain/client, lbb) are generated from one API contract. Their shapes match across languages.

SDK / surface Package Runtime Use it when…
TypeScript client @littlebigbrain/client Node 18+, browsers, edge workers You’re building a JS/TS app, API route, or edge function
Python client littlebigbrain (imports as lbb) Python 3.10+ (httpx + pydantic) Scripts, notebooks, data pipelines
MCP server @littlebigbrain/mcp Node (stdio) or hosted HTTP You want an AI agent (Claude, Cursor, Codex) to search, query and write the graph
HTTP API n/a Any language No SDK for your language, or you want the native SPARQL Protocol

Whatever you pick, the flow is the same:

  1. Declare your types and links. See Load your data.
  2. Write records as JSON.
  3. Turn on search for a type.
  4. Search by meaning, then follow links with SPARQL.

The quickstart shows the flow in TypeScript, Python and cURL. If your data is RDF already, load it as it is.

Standard SPARQL tools need no SDK. Each stack serves the SPARQL 1.1 Protocol at /sparql. YASGUI, Protégé and RDFLib’s SPARQLWrapper connect with the endpoint URL and a bearer token.

Run lbb-server locally and connect the same HTTP clients to its local URL. For exact local queries, lbb-testctl query sparql also reads RDF with SPARQL. Class-declared embeddings use /v1/embeddings* and /v1/search, as shown in Search by meaning.

The older lbb-testctl graph search, multi-search, full-text and record-index embeddings commands, and Python’s LbbLocalClient search methods, are deprecated for new integrations. Their existing execution and arguments remain unchanged; no removal version is set. Their BM25, fusion and explicit record-vector contracts are different from class embedding search and have no automatic conversion.