api.brickken.com. They differ in who is driving and which credential they carry.
Start from what you already have
The five surfaces
REST API
Plain HTTP. Everything the platform can do. API key for the Dapp API, x402 or API key for agentic methods.
SDK
brickken-sdk on npm. Typed TypeScript client for the Dapp API, the Agentic API, and RAMS, in your own process.MCP server
Hosted at
https://mcp.brickken.com/mcp. The client to use when an AI agent should drive the full Dapp API with just an API key.CLI
brickken-cli on npm. Dapp API, KYC, the Sandbox/Forge BKN faucet, agentic, and RAMS workflows from your terminal.Skill
Brickken knowledge for AI coding agents, with or without the CLI installed.
What each surface can reach
The CLI reaches the Dapp API with
BRICKKEN_API_KEY: use brickken tx prepare --method <method> for tokenization, STO, and security-token transaction methods, and brickken dapp get for Dapp reads. Multipart file uploads such as /patch-token-docs remain REST-only.For Dapp API work, use the SDK if you write TypeScript, MCP if an agent is driving, or plain HTTP otherwise.SDK or MCP for the Dapp API?
Both reach the full Dapp API with nothing but an API key. The difference is who is holding the credential:- SDK — your code holds the key, and every call is typed and testable. Illegal credential combinations fail locally, before a request leaves your process.
- MCP — a hosted endpoint holds nothing; each session supplies its own credentials, and an AI agent picks the tools. Right when the driver is an agent rather than a program you wrote.
Same backend, same rules
Whichever surface you pick, the mechanics are identical: writes are prepared into unsigned transactions, signed, then sent; preparing a relayed agentic operation is free and only the send costs anything; and your private key never leaves your machine. The surface changes the ergonomics, not the semantics — you can prepare with the CLI and send with curl.Authentication
The credential matrix in full.
Quickstart
A first call on each surface.