The short answer

Caper serves two read-only MCP servers. Point your agent at https://caper.network/api/mcp for the knowledge base, or at https://caper.network/wiki/caper/<CASHTAG>/mcp for one DAO's own record. Both speak JSON-RPC 2.0 over HTTP POST, both are unauthenticated and free, and neither can write anything. A DAO's treasury balances, its proposal and trade timeline, its executed grants and its funding relationships with other DAOs all come back from a single get_ledger call against the second endpoint.

That is the whole setup. The rest of this page is the detail: which tool answers which question, what the servers deliberately will not do, and why a Caper DAO can answer questions most DAOs cannot.

Why this is answerable at all

Asking most DAOs for a machine-readable account of their own governance means assembling it yourself: balances from a block explorer, proposals from a Snapshot space, discussion from a Discourse forum, payouts from a multisig, and the mapping between them from nowhere in particular. The record exists, but it is spread across systems that were never designed to be read together, and the joins are done by hand.

A caper is issued, funded, governed and settled through one set of contracts, so the join already exists. Every proposal, trade, treasury movement and execution is a settled transaction on the same ledger, and each DAO's company layer sits directly on top of that record. Serving it to an agent is therefore a matter of exposing what is already joined, not of reconciling four sources and hoping they agree.

This is also why the ledger tool outranks the prose tools. Wiki pages on Caper are human-authored and can be wrong, stale or absent; a young DAO has a ledger before it has any prose at all. get_ledger is derived from settled transactions, so on any balance, amount, date or "did this actually happen", it is the authority and the prose is commentary.

The knowledge-base server

POST https://caper.network/api/mcp — the DAO-governance reference and Caper's own documentation. Eight tools:

Tool	Answers	Notes
get_categories	What is in here?	Call this first when orienting. Returns the taxonomy with pageCount and pageCountDeep, so you can tell an empty heading from a populated branch before spending a call.
search_wiki	Where does X live?	Case-insensitive substring over titles and body text — not fuzzy. Search one distinctive word, not a sentence.
get_pages	Read 1–20 pages	The one to use. Takes paths exactly as the listing tools return them; misses come back in missing rather than failing the call.
get_page	Read one known page	For a single page only. A wrong guess returns near-match slugs instead of an empty error.
list_pages	Walk a branch	tagPath matches the branch and everything beneath it: daos also returns daos/dexs/….
get_recent_changes	What changed?	Last N days (default 7, max 30).
get_full_corpus	Bulk ingestion	Preflight with sizeOnly: true first — the corpus is large enough to swamp a context window.
list_daos	Which DAOs exist?	Resolves a name to a cashtag and hands back that DAO's own mcpEndpoint. This is the bridge to the second server.

The knowledge-base server has no ledger tool, deliberately. Chain state is per-DAO, so it lives on the per-DAO server that list_daos points you to.

The per-DAO server

POST https://caper.network/wiki/caper/<CASHTAG>/mcp — one DAO's company layer. It carries the same five reading tools scoped to that DAO's own pages, plus the one that matters:

get_ledger returns four things in a single call — current treasury balances by resource, the activity timeline (proposals, trades, executions) with an explorer link per event, executed grants and payouts, and inter-DAO funding edges in both directions. It takes one optional argument, limit.

The funding edges are the part with no equivalent elsewhere. When one caper funds another, both sides of the relationship are settled transactions on the same ledger, so the edge is a fact rather than an inference — and it is directional, so you can read who funded whom.

If your agent does not speak JSON-RPC

MCP is the richest way in, but it is not the only one. Everything the knowledge base holds is also served over plain HTTP GET, which is what a crawler, a shell script or a retrieval pipeline actually wants.

Endpoint	Returns
GET /wiki/<path>.md	Any page as Markdown with YAML front matter — title, canonical url, updated, last_verified where the page carries one, and the licence. Append .md to the page URL you are already looking at.
GET /api/wiki/<path>	The same page as JSON: the raw content blocks, tagPath, updatedAt, lastVerifiedAt, a license object, and markdownUrl pointing at the Markdown form. An unknown path returns a JSON error carrying the index URL rather than an HTML 404 page.
GET /wiki/caper/<CASHTAG>/dao.json	One DAO as a DAOstar / EIP-4824 description document — the DAO's name and description, its governance, members, proposals, activity-log and contracts fields, and the on-ledger addresses of its component, treasury, governance token, vote token and badges.
GET /wiki/caper/<CASHTAG>/llms.txt	One DAO as plain text: its pages, its treasury balances, its timeline, its grants and its funding edges, in the same document.
GET /llms.txt · /llms-full.txt	The index of every page and DAO; and the entire corpus as one document — about 2.5 MB, so size it before you pull it.
GET /.well-known/agent.json	An agent card: the MCP endpoint, the API spec URL, the skills this site claims, and the daoUriTemplate that generates the dao.json URL for any cashtag.
GET /.well-known/openapi.json	An OpenAPI 3.1 document for the read endpoints.

Two things follow from this that are easy to miss. The Markdown and JSON forms both declare a licence — CC BY 4.0 — so an agent can tell what it is allowed to do with the text without inferring it from a footer. And agent.json is the only one of these files that points at the others, so it is the right first fetch when you are mapping the surface rather than reading a specific page.

A worked example

One call, no key, no wallet:

curl -s -X POST https://caper.network/wiki/caper/CAPER/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"get_ledger","arguments":{"limit":3}}}'

The response carries the treasury as a list of resources with exact amounts, then the timeline. A trade event looks like this:

{
  "id": "trade-2222",
  "kind": "trade",
  "at": "2026-08-09T09:22:56.524Z",
  "title": "Sold $CAPER",
  "status": "SELL",
  "amount": "2.25B",
  "txUrl": "https://stokenet.radxplorer.com/transactions/txid_tdx_2_12084daw…",
  "timeAgo": "54m"
}

Every event carries its txUrl, so any figure an agent reports can be traced back to the transaction that produced it. Amounts are returned as strings at full precision — treasury balances come back like "109791.549345417912335" — because these are token quantities and rounding them in transit would be a data loss, not a formatting choice.

Truncation is always reported rather than silent: the timeline returns count alongside truncated: true when your limit cut the list, and the same holds for grants and funding edges. An agent can tell "there were three" from "there were at least three".

What these servers will not do

• Write anything. Both servers are read-only. There is no tool that creates a caper, submits a proposal, casts a vote, or moves a token. Governance actions require a signed transaction from a Radix wallet, and an agent cannot produce one here.
• Authenticate. There are no keys and no accounts, because everything served is already public on-chain or published on the wiki.
• Answer from a GET. The two MCP endpoints are POST-only JSON-RPC; a browser or crawler that GETs them receives 405. That is correct behaviour, and it is why this page exists — a POST-only endpoint cannot be indexed or cited, so the documentation has to be somewhere that can. The GET surface in the section above is the answer for anything that cannot post JSON-RPC.
• Guess. A malformed or unknown path returns near-matches and the tool's own usage note rather than an empty result, so a wrong first call is self-correcting instead of a dead end.

Each server also returns a usage guide in its initialize response, so an agent that connects properly is told how to use it before it makes a call.

Reading the record honestly

Two cautions worth carrying into any analysis built on this data.

The first is scope. Caper DAOs currently run on Radix Stokenet, the public test network. The mechanics, the contracts and the record are real, but the capital is not, so treasury figures should be read as demonstrations of the machinery rather than as measurements of economic activity. Explorer links resolve to stokenet.radxplorer.com, which makes the network unambiguous in every event.

The second is the ledger/prose split described above. If a wiki page and get_ledger disagree about a number, the ledger is right and the page needs an edit. Prefer the ledger for anything countable and the wiki for anything argued.

See also

• What is a caper — the company layer these tools read
• Proposals and Execution — what the timeline's proposal and execution events represent
• Trading — what the timeline's trade events represent
• llms.txt — the machine-readable discovery file that advertises both servers
• EIP-4824 — the DAO description standard dao.json follows
• Model Context Protocol — the specification both servers implement