Choosing an SDK
Every client below speaks the same HTTP API and authenticates with the same
stack API key. They are interchangeable, so you can
load with one and query with another against the same graph. The first-party
SDKs (@littlebigbrain/client, lbb) are generated from one API contract, so
the shapes match across languages.
Comparison
Section titled “Comparison”| 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 read and write the graph |
| HTTP API | n/a | Any language | No SDK for your language, or you want the native SPARQL Protocol |
The same shape everywhere
Section titled “The same shape everywhere”Whatever you pick, the flow is the same: load RDF, wait for the snapshot to publish, query with SPARQL. The Quickstart shows it in TypeScript, Python, and cURL.
Standard SPARQL tools need no SDK. Every stack serves the native
SPARQL 1.1 Protocol at /sparql, so YASGUI, Protégé, and RDFLib’s
SPARQLWrapper connect with the endpoint URL and a bearer token.
Pick one
Section titled “Pick one”TypeScriptDependency-free fetch wrapper; typed request/response shapes.
Python — lbbSync + async, dict or typed Pydantic models.
MCP server — @littlebigbrain/mcpTask-shaped tools for agents; local stdio or hosted OAuth.
HTTP API & SPARQLREST plus the native SPARQL 1.1 Protocol endpoint.