[ Developers ]
Build on Coconut
Coconut is a shared, living context layer: one backend your agents and your team both read and write, reachable over MCP, the CLI, and the SDK. The quickstart below is the short version — about ten minutes to context written from one runtime and read from another.
[ Quickstart ]
Ten minutes to a context layer two runtimes share
Steps two through four are the part that matters: everything else on this page is a way of doing them at scale. Run them against a throwaway space first if you would rather not think about structure yet.
- 01
Create a workspace
Coconut Context is live and self-serve — sign up, name an org, and you have a space to write into. No invite, no sales call, and nothing to install for this step.
- 02
Point a runtime at it over MCP
Connector is Coconut's MCP server. It gives any MCP-aware client live, permission-aware access to your spaces, and it only ever exposes what the connected user could already see. Claude Code and Claude Desktop have ready-made installs in the reference below; every other MCP client connects the same way. Connection details are in the docs.
- 03
Write one page, and set one field on it
A page carries the prose; metadata makes it queryable. Doing both once, rather than pasting a document, is the difference between a context layer and a folder — the field is what later lets an agent ask for every record of a kind instead of searching for text and hoping.
- 04
Read it back from a second client
Same org, different runtime: the CLI, the SDK, or another MCP client entirely. Nobody re-explains anything, and nothing was copied between them. This is the step worth doing before you decide about the rest of the page.
- 05
Optional: let an agent maintain it
Space agents are permissioned principals in the same corpus, under the same access controls as the people in it. Point one at a space and it keeps the records up to date rather than you doing it by hand.
[ Reference ]
The ways in
Every one of these reaches the same context under the same permissions. Pick whichever fits where your agent already runs — there is no primary client, and nothing here is a different product.
Coconut CLI
Authenticate, query, and push context from the command line or from any CI job and agent runtime that can shell out.
Coconut SDK
A typed client for reading and writing to your context layer from application and agent code, in the language your stack already uses.
Examples
A guided walkthrough of the examples that ship with the SDK: write typed records back to a space, pull them out again, render a dashboard from them, and answer questions grounded in the space itself.
Open ExamplesClaude
Two ready-made recipes for step two of the quickstart. Connect Claude to Coconut and work with your context from there, in the terminal or in the desktop app.
Claude Code Plugin
Read and write your context layer from the terminal, next to your code.
Claude Desktop Connector
Add Coconut to the Claude desktop app from the connector directory.
View connectorAny other MCP client
Coconut is model-, harness- and runtime-agnostic. Cursor, Copilot, Gemini, a custom harness of your own — anything that speaks the Model Context Protocol connects through the same Connector, with the same permissions, to the same context. The two Claude recipes above are shortcuts, not the supported path.
Read the docsThis site, over MCP
Everything coconut.dev publishes — the pages, the FAQ, the blog, the news — served as an MCP server your agent can read instead of scraping. No account and no key: it carries only what is already on the open web. Two tools, search and fetch.
This is the website, not your context layer. Connector, above, is the authenticated server that reaches a Coconut workspace under its own permissions — this one cannot see a workspace at all.
Working out whether context survives a handoff between two runtimes, or want a second pair of eyes on how to structure it? Tell us what you're building — that conversation is more useful to us than a demo.