Caper serves two MCP servers, and reading from either needs no key. Point your agent at
https://caper.network/api/mcp for the knowledge base, or at
https://caper.network/capers/<CASHTAG>/mcp for one DAO's own record. Both speak
JSON-RPC 2.0 over HTTP POST, both are unauthenticated and free, and the reading tools never write anything. (Agents can also act – launch a caper, trade, propose, vote – through a separate authenticated flow: Build on Caper as an agent.) 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.
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.
POST https://caper.network/api/mcp – the DAO-governance reference and Caper's own
documentation. Read live on 3 November 2026, it advertises seventeen tools: the nine reading tools below, the seven that carry the authenticated write flow, and send_feedback. Reading needs no key. The nine reading 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? | Matches page titles and body prose, ranked in four tiers: titles starting with the term, titles containing it, literal body hits, then English full-text hits. The full-text tier is a fallback, so a whole question works as a query – it is stemmed and stopped, not semantic, and will not find a page saying “fee” when you asked about “cost”. Each result carries a 200-character snippet windowed on the match; page through it while hasMore is true. |
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_page_history | Who changed this, and when? | A page's revisions, newest first: each one's version, change type, message, date and the blocks it changed. Address the page as get_page does. |
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 write flow is seven more – get_challenge, login, get_manifest,
submit_tx, save_wiki_page, delete_wiki_page and save_about, and the thing worth knowing is
that they sit on this same endpoint rather than a separate one. An agent that calls
tools/list here will see all seventeen. They are gated rather than hidden: each refuses to act
without a Bearer token earned by signing a ROLA challenge with your own key, so the read surface stays
anonymous while the write surface stays accountable. What each one does, and the four-step sequence they
run in, is Build on Caper as an agent.
The last tool, send_feedback, takes one report of up to 300 characters, marked missing, wrong, broken or suggestion, and passes it to Caper's maintainers; reports are read, not published.
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.
POST https://caper.network/capers/<CASHTAG>/mcp – one DAO’s company layer.
Read live on 3 November 2026, it carries four tools. Three exist only here because they read that DAO’s chain state: get_ledger, get_market and
quote_swap. The fourth is send_feedback, the same report tool the knowledge base carries, which files each report under the DAO's cashtag. The wiki-reading tools are not on this server – asking it for
search_wiki returns an error naming the four it does expose. Prose lives on the knowledge-base
server; this one answers for the ledger.
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
(default 25 rows per section, max 100).
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.
get_market is the price view: the marginal price in XRD, 24-hour change and volume, market
cap, circulating versus total supply, how the supply is split between the curve and the protocol, the
holder count, and the most recent trades. Pass candles (1h, 4h or
1d) to get OHLC history alongside. It reads live state, so it supersedes any figure a wiki
page quotes and any figure an earlier call returned.
quote_swap is the one an analyst will reach for. It prices a hypothetical trade of
a specific size against the live bonding curve, skim-accurate, and executes nothing: side: "buy" prices amount XRD in and returns
tokens out, side: "sell" prices tokens in and returns XRD out. Because it answers with the
effective price alongside the marginal one, it is how an agent measures slippage before it matters.
The quote already includes the skim, the one charge on a trade, so the price it returns is the price the trade would pay. It reads whichever logic component the registry currently names, so it stays current through a logic upgrade.
Neither get_market nor quote_swap moves anything. A real trade is a
wallet-signed transaction, it pays the collateralization skim, and it moves the price the next
quote will see.
Tools are not the whole surface. Both servers advertise the MCP prompts capability in their
initialize response and in server/discover, so a client that supports prompts can offer a user the server's own suggested
questions instead of asking them to invent a first call. Read live on 15 September 2026, the knowledge base
carries five – what_is_a_caper, browse_capers, explain_the_curve,
read_a_caper_as_an_agent and launch_a_caper – and every per-DAO server carries
three scoped to that DAO: brief_me, treasury and cost_to_buy_in.
Both are the same build (serverInfo reports caper-wiki and
caper-wiki:<CASHTAG> at version 2.7.0 on 3 November 2026), and both speak two protocol eras from the same endpoint. The request decides which, not a setting: a body carrying io.modelcontextprotocol/protocolVersion in params._meta, a call to server/discover, or an MCP-Protocol-Version: 2026-07-28 header is answered in the 2026-07-28 era, and anything else, including every initialize, in the legacy era. The two eras share six methods: tools/list, tools/call, resources/list, resources/templates/list, prompts/list and prompts/get. The legacy era adds the handshake pair, initialize and ping.
The 2026-07-28 era has no handshake and adds server/discover instead, and a method from the other era is not translated: ping sent the modern way returns -32601. There is no need to guess which, and no need to trust this page for it either: call an unimplemented method and the error names every method implemented in the era you asked in, in both the message and a supportedMethods array. The two resource methods are implemented but empty – they answer with an empty array, because the corpus is served through get_pages and over plain HTTP rather than as MCP resources.
A 2026-07-28 request is stricter about its envelope than a legacy one, and every refusal names the fix. _meta must also carry io.modelcontextprotocol/clientCapabilities ({} when the client declares none), and three HTTP headers must repeat the body: MCP-Protocol-Version: 2026-07-28, Mcp-Method set to the method, and on tools/call or prompts/get an Mcp-Name set to the tool or prompt. A missing or mismatched header returns -32020 naming the header and the value it expected. The modern era also sends a protocol error with a matching HTTP status – 404 for an unknown method, 400 for a malformed request – where the legacy era answers 200, and its list results carry ttlMs: 300000 and cacheScope: "public", so a client may cache the tool and prompt lists for five minutes. The worked example below is a legacy request, which is why it needs no headers.
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 /capers/<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 /capers/<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 (80 KB on 14 September 2026); and the entire corpus as one document – 3,483,133 bytes on 14 September 2026, up from 3,368,474 six days earlier, so size it before you pull it rather than trusting any figure on this page. |
GET /.well-known/agent-card.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. The same document is served at the older /.well-known/agent.json; agent-card.json is the path the A2A specification tells a client to fetch, so prefer it. |
GET /.well-known/openapi.json | An OpenAPI 3.1 document for the whole HTTP surface – nineteen paths on 14 September 2026, the GET reads below plus both MCP endpoints and the five POST /api/agent/* write routes. |
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 the agent card 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.
One call, no key, no wallet:
curl -s -X POST https://caper.network/capers/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".
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.Each server also returns a usage guide in its initialize response and in server/discover, so an agent that connects
properly is told how to use it before it makes a call.
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.
dao.json follows