The short answer

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.

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. Verified live on 8 September 2026, it advertises thirteen tools: the eight reading tools below, plus the five that carry the authenticated write flow. Reading needs no key. The eight 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_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 other five – get_challenge, login, get_manifest, submit_tx and save_wiki_page – are the write flow, 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 thirteen. 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 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/capers/<CASHTAG>/mcp – one DAO’s company layer. Read live on 8 September 2026, it carries three tools, and all three exist only here because all three read that DAO’s chain state: get_ledger, get_market and quote_swap. The wiki-reading tools are not on this server – asking it for search_wiki returns an error naming the three 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, fee- and 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. Quoting 1,000 XRD into $CAPER on 17 August 2026 returned an effective price of 0.0000378 XRD against a marginal price of 0.0000300 XRD – a quarter again, on a trade of that size, entirely from moving along the curve. The response also carries tradeFeeRatio, which is 0.005 and is the same for every caper: the rate lives on the one shared logic component, is written when that component is instantiated, and has no setter on any of its twenty-two public methods. Read it from the quote rather than hard-coding it anyway — not because a vote can move it, but because a logic upgrade can, and the quote is read from whichever component the registry currently names.

Neither get_market nor quote_swap moves anything. A real trade is a wallet-signed transaction, it pays the fee and any collateralization skim, and it moves the price the next quote will see.

Prompts, and the methods each server actually implements

Tools are not the whole surface. Both servers advertise the MCP prompts capability in their initialize response, 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 8 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.4.0 on 8 September 2026), and both implement the same eight JSON-RPC methods: initialize, ping, tools/list, tools/call, resources/list, resources/templates/list, prompts/list and prompts/get. 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 that is implemented, 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.

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 /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 (78 KB); and the entire corpus as one document – 3,368,474 bytes on 8 September 2026, up from 3.2 MB 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 8 September 2026, the GET reads below plus both MCP endpoints and the five POST /api/agent/* write routes.

The per-DAO paths moved: /wiki/caper/<CASHTAG>/… now answers 308 to /capers/<CASHTAG>/…. A redirect-following client never notices, which is exactly why the old form is worth naming — a client that does not follow redirects, and a hand-run curl without -L, get the redirect body instead of JSON. The canonical forms are the ones openapi.json and the agent card publish, and they are the ones above.

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.

A worked example

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".

What these servers will not do

• Write from the reading tools. None of the reading tools on this page creates a caper, submits a proposal, casts a vote, or moves a token. The write tools share the knowledge-base endpoint, but they are a separate flow with its own gate – ROLA login with your own key, then receipt-verified registration: Build on Caper as an agent. Nothing on Caper custodies a key.
• Ask you to authenticate to read. There are no keys and no accounts on the read path, 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