# Caper Wiki

> Read Caper's wiki and DAO on-chain data; launch a DAO, trade, and propose on Radix testnet.

- name: network.caper/caper-wiki
- version: 2.5.0
- connection class: R0 (autonomous)
- trust: 83/100 flags: no-repository
- quality: 82/100 (good)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/network.caper%2Fcaper-wiki
- tools: https://api.protogrid.dev/v1/servers/network.caper%2Fcaper-wiki/tools

**An agent can connect right now, no human step.** Remote endpoint, no authentication, reachable on the last probe.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "caper-wiki": {
      "type": "http",
      "url": "https://caper.network/api/mcp"
    }
  }
}
```


## Trust

- hygiene: 80
- liveness: 100
- freshness: 100
- provenance: 55
- drivers: +dns-namespace +website +reachable +uptime-99% +updated-7d-ago -no-repository
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 82/100 (good)

### protocol: 100 (weight 25)

- pass `protocol.modern`: supports 2026-07-28 (server/discover)
- pass `protocol.stateless`: answers without a session
- pass `protocol.transport`: streamable HTTP
- pass `protocol.list_ttl`: tool list is cacheable (ttlMs 300000)

### authorization: 100 (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- pass `auth.secret_in_url`: URL variables carry no secret

### tool hygiene: 86 (weight 30)

- pass `tools.descriptions`: every tool has a description
- warn `tools.description_length`: 1 tools have descriptions over 1,024 characters, which crowds the context
- pass `tools.schemas`: every tool has an object input schema
- pass `tools.annotations`: 13 of 13 tools declare readOnlyHint or destructiveHint
- warn `tools.directory_hints`: 5 of 13 tools declare all four hints; missing: search_wiki (destructiveHint); get_page (destructiveHint); get_recent_changes (destructiveHint); …
- pass `tools.token_cost`: about 3,272 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 25 (weight 15)

- warn `stability.changes`: 10 tool changes in 30 days
- fail `stability.rug_pull`: 4 tools kept their name but changed most of their description in 30 days; review before trusting them

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 13, about 3,272 tokens to load them all
- tool set hash: b851acf8e1943d82c9f642929d8fa1a0
- tools last changed: 2026-10-20T01:12:10.403Z
- badge: [![protogrid quality](https://protogrid.dev/badge/network.caper/caper-wiki.svg)](https://protogrid.dev/servers/network.caper/caper-wiki)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

- 2026-10-20 `submit_tx` changed (description, inputSchema)
  - before: Step 4: register a committed transaction by txHash. Kinds: create-caper, buy, sell, proposal, vote, trigger. The server verifies before mirroring anything: receipts are re-read on-ledger (forged or foreign txHashes are refused, replays are idempotent). Context per kind: create-caper takes cashtag; proposal takes proposalId. Requires the Bearer token from the `login` tool, sent as an HTTP `Authorization: Bearer <token>` header on the POST carrying this call.
  - after: Step 4: register a committed transaction by txHash. Kinds: create-caper, buy, sell, proposal, vote, trigger. The server verifies before mirroring anything: receipts are re-read on-ledger (forged or foreign txHashes are refused, replays are idempotent). Context per kind: create-caper takes cashtag; proposal takes proposalId; trigger takes code (the P-… code). Requires the Bearer token from the `login` tool, sent as an HTTP `Authorization: Bearer <token>` header on the POST carrying this call.
- 2026-10-20 `get_manifest` changed (inputSchema)
- 2026-10-19 `get_full_corpus` changed (description, inputSchema)
  - before: The whole Caper knowledge base as one text document, for bulk ingestion. PREFLIGHT FIRST: call it with sizeOnly=true to get the exact character count, a token estimate, the per-branch breakdown and the largest pages – the corpus is big enough to swamp a context window and one operational page exceeds 500 KB on its own. Then pull it with `maxChars` (default 200000, max 1000000), or narrow it with `tagPath` to take one branch at a time. Truncation is page-aligned and honest: `truncated`, `omittedPages` and `nextSkip` say exactly where to resume (pass skip=nextSkip). If you only need a handful of pages, get_pages is cheaper.
  - after: The whole of the Caper knowledge base as one text document, for bulk ingestion. Preflight first: sizeOnly=true returns the character count, a token estimate, the per-branch breakdown and the largest pages. Then pull it with `maxChars` (default 200000, max 1000000), or one branch at a time with `tagPath`. Truncation is page-aligned: `truncated`, `omittedPages` and `nextSkip` say where to resume (pass skip=nextSkip). For a handful of pages get_pages is cheaper.
- 2026-10-19 `get_categories` changed (description) **meaning changed**
  - before: Curated taxonomy of the Caper knowledge base with page counts – call this FIRST when you are orienting rather than searching. Each node returns `path` (a tagPath you can hand straight to list_pages), `pageCount` (pages sitting directly at that path) and `pageCountDeep` (including every descendant), so you can tell an empty heading from a populated branch before spending a call. Takes no parameters.
  - after: The category tree of the Caper knowledge base, the cheapest way to orient before searching. Each node carries its `path` (a tagPath list_pages and search_wiki take), name, description, `pageCount` (pages filed at that path) and `pageCountDeep` (with every descendant). `tagPaths` lists every tag path that holds pages, including any the tree does not name.
- 2026-10-19 `get_recent_changes` changed (description, inputSchema) **meaning changed**
  - before: Pages in the Caper knowledge base edited within the last N days, newest first – for "what changed?", not for finding a topic (search_wiki) or reading a branch (list_pages). Defaults: days 7 (max 30), limit 20 (max 50). `truncated: true` means the limit cut the list, not that the window is exhausted – raise `limit`, or page through list_pages sorted by updatedAt. Returns summaries only; feed the `path` values to get_pages.
  - after: Pages of the Caper knowledge base edited within the last N days, newest first: what to poll when you are watching the wiki rather than reading it. Same rows as list_pages. Defaults: days 7 (max 30), limit 20 (max 50). `truncated: true` means the limit cut the list; raise it, or page through list_pages.
- 2026-10-19 `list_pages` changed (description, inputSchema) **meaning changed**
  - before: Enumerate pages in the Caper knowledge base, newest first, optionally under one tag path. Use it to walk a branch you have already located (via get_categories, or the `tagPath` on a search hit); use search_wiki when you are hunting a keyword. `tagPath` matches the branch and everything beneath it – "daos" also returns "daos/dexs/...". Omit it to list the whole scope. Defaults: sort "updatedAt", page 1, pageSize 20 (max 100). Returns summaries only – pass the `path` values to get_pages for full text. `hasMore`/`nextPage` are the only truncation; nothing else is cut.
  - after: Browse the Caper knowledge base by tag path rather than by keyword: every page under a branch, newest first by default. `tagPath` matches the branch and everything beneath it; omit it to walk the whole wiki. Sort by title for an A–Z pass. Same rows as search_wiki, with `totalPages`, `hasMore` and `nextPage`. Defaults: page 1, pageSize 20 (max 100).
- 2026-10-19 `get_pages` changed (description, inputSchema) **meaning changed**
  - before: Batch read: full text of 1 to 20 pages in the Caper knowledge base in a single call. This is how you read search or listing results – calling get_page in a loop is the main way to waste round trips against this server. Pass `paths` exactly as the listing tools return them. Paths that do not exist come back in `missing` instead of failing the call, and anything past the 20-path cap comes back in `remaining` for a follow-up. Output is capped by `maxChars` (default 250000): pages past the cap are listed in `omitted` with their sizes, never silently dropped. Check the `chars` field in a listing first if your context budget is tight – a single operational page here can exceed 500 KB.
  - after: Batch read: 1 to 20 pages of the Caper knowledge base in full in one call, which is how to read search or listing results. Pass `paths` as the listings return them. Paths that do not exist come back in `missing` rather than failing the call, anything past 20 in `remaining`, and pages past `maxChars` (default 250000) in `omitted` with their sizes.
- 2026-10-19 `get_page` changed (description, inputSchema)
  - before: Full text of ONE page in the Caper knowledge base. Address it by `path` ("dao-governance/concepts/voting/quadratic-voting" – exactly the `path` field the listing tools return), or by `tagPath` + `slug`. Use this only for a single known page: for 2 to 20 pages call get_pages instead, which is one round trip rather than N. Pass the path, not a page title. A miss returns near-match slugs so a wrong guess is recoverable in one retry.
  - after: One page of the Caper knowledge base in full: its text, version, update date and metadata. Address it by `path` ("tag/path/slug", exactly the `path` or `url` a listing returns), or by `tagPath` + `slug`; a category's own path reads its hub article. Not a title. For 2 to 20 pages call get_pages, one round trip rather than N. A miss names the nearest pages, so a wrong guess is fixed in one retry. A page's URL with `.md` appended is its markdown.
- 2026-10-19 `search_wiki` changed (description, inputSchema)
  - before: Keyword search across the Caper knowledge base – the first call when you know what you are looking for but not where it lives. Matches page titles and body prose. A distinctive keyword is still the best query, but a whole question now works too: if the literal text is not found anywhere, it falls back to English full-text matching, which stems words and drops stopwords. NOT semantic – it reduces your question to its keywords, so it will not find a page that says "fee" when you asked about "cost". Ranked in four tiers: titles starting with the term, then titles containing it, then literal body hits, then full-text hits by relevance. Returns summaries only, each with a `path`, a `chars` size, and a 200-char snippet WINDOWED ON THE MATCH – the snippet shows you the passage that matched, so you can judge a result without opening it. Feed those `path` values to get_pages in one batched call – do NOT loop get_page over the results. If you want structure rather than a keyword, call get_categories (taxonomy) or list_pages (a whole branch). Defaults: page 1, pageSize 20 (max 50). Keep paging while `hasMore` is true.
  - after: Keyword search across the Caper knowledge base: the first call when you know what you are looking for but not where it lives. Matches titles and body prose, ranked in four tiers: titles starting with the term, titles containing it, literal body hits, then English full-text hits by relevance, which stem words and drop stopwords. Not semantic: one distinctive word beats a sentence. Each row carries a `path`, its size in `chars` and a snippet windowed on the match. Feed the paths to get_pages in one call rather than looping get_page. Narrow with tagPath when a term is common. Defaults: page 1, pageSize 20 (max 50); keep paging while `hasMore` is true.
- 2026-10-06 `get_manifest` changed (description)
  - before: Step 3: a ready-to-sign transaction manifest. Kinds: create-caper, buy, sell, create-proposal, vote, trigger. Per-kind parameters: create-caper needs name + cashtag + description (infoUrl/iconUrl/originToken optional); buy needs cashtag + xrd; sell needs cashtag + tokens; create-proposal needs cashtag + title + description + actionJson (one action object, or an ARRAY of up to 4 for a ranked ballot, as a JSON string — e.g. '{"kind":"PAYOUT","title":"Grant","currency":"<resource>","amount":100,"recipient":"<account>"}'). Governance is two-phase: 'vote' casts a ranked ballot (sequence = on-chain option indexes incl. the trailing Do-nothing, best first; proposerPaysFee answers who funds the execution fee) during the voting window; a supermajority pass arms 'trigger', which locks the trailing TWAP as the baseline and opens the market window: the winner executes unless the TWAP over that window is below the baseline. You sign and submit the manifest yourself with your own key, then register the txHash with submit_tx. Requires the Bearer token from the `login` tool, sent as an HTTP `Authorization: Bearer <token>` header on the POST carrying this call.
  - after: Step 3: a ready-to-sign transaction manifest. Kinds: create-caper, buy, sell, create-proposal, vote, trigger. Per-kind parameters: create-caper needs name + cashtag + description (infoUrl/iconUrl/originToken optional); buy needs cashtag + xrd; sell needs cashtag + tokens; create-proposal needs cashtag + title + description + actionJson (one action object, or an ARRAY of up to 4 for a ranked ballot, as a JSON string — e.g. '{"kind":"PAYOUT","title":"Grant","currency":"<resource>","amount":100,"recipient":"<account>"}'). Governance is two-phase: 'vote' casts a ranked ballot (sequence = on-chain option indexes incl. the trailing Do-nothing, best first) during the voting window; a supermajority pass arms 'trigger' (free, anyone can call it), which locks the trailing TWAP as the baseline and opens the market window: the winner executes unless the TWAP over that window is below the baseline. You sign and submit the manifest yourself with your own key, then register the txHash with submit_tx. Requires the Bearer token from the `login` tool, sent as an HTTP `Authorization: Bearer <token>` header on the POST carrying this call.

Full history: https://api.protogrid.dev/v1/servers/network.caper%2Fcaper-wiki/changes

## Remotes

- https://caper.network/api/mcp (streamable-http, auth none, reachable true, uptime30d 0.99159664)
- https://caper.network/capers/{cashtag}/mcp (streamable-http, auth unknown, reachable unknown, uptime30d –)

## Packages

_none_

## Tools (13)

- `get_categories`: The category tree of the Caper knowledge base, the cheapest way to orient before searching. Each node carries its `path` (a tagPath list_pages and search_wiki take), name, description, `pageCount` (pages filed at that path) and `pageCountDeep` (with every descendant). `tagPaths` lists every tag path that holds pages, including any the tree does not name.
- `get_challenge`: Step 1 of writing to Caper: a single-use ROLA challenge (5-minute expiry). The response includes the exact recipe for the message your Ed25519 key must sign. Writes are Stokenet-testnet only for now, and you always sign with your OWN key – nothing here custodies anything. Takes no parameters.
- `get_full_corpus`: The whole of the Caper knowledge base as one text document, for bulk ingestion. Preflight first: sizeOnly=true returns the character count, a token estimate, the per-branch breakdown and the largest pages. Then pull it with `maxChars` (default 200000, max 1000000), or one branch at a time with `tagPath`. Truncation is page-aligned: `truncated`, `omittedPages` and `nextSkip` say where to resume (pass skip=nextSkip). For a handful of pages get_pages is cheaper.
- `get_manifest`: Step 3: a ready-to-sign transaction manifest. Kinds: create-caper, buy, sell, create-proposal, vote, trigger. Per-kind parameters: create-caper needs name + cashtag + description (infoUrl/iconUrl/originToken optional); buy needs cashtag + xrd; sell needs cashtag + tokens; create-proposal needs cashtag + title + description + actionJson (one action object, or an ARRAY of up to 4 for a ranked ballot, as a JSON string — e.g. '{"kind":"PAYOUT","title":"Grant","currency":"<resource>","amount":100,"recipient":"<account>"}'). Governance is two-phase: 'vote' casts a ranked ballot (sequence = on-chain option indexes incl. the trailing Do-nothing, best first) during the voting window; a supermajority pass arms 'trigger' (free, anyone can call it), which locks the trailing TWAP as the baseline and opens the market window: the winner executes unless the TWAP over that window is below the baseline. You sign and submit the manifest yourself with your own key, then register the txHash with submit_tx. Requires the Bearer token from the `login` tool, sent as an HTTP `Authorization: Bearer <token>` header on the POST carrying this call.
- `get_page`: One page of the Caper knowledge base in full: its text, version, update date and metadata. Address it by `path` ("tag/path/slug", exactly the `path` or `url` a listing returns), or by `tagPath` + `slug`; a category's own path reads its hub article. Not a title. For 2 to 20 pages call get_pages, one round trip rather than N. A miss names the nearest pages, so a wrong guess is fixed in one retry. A page's URL with `.md` appended is its markdown.
- `get_pages`: Batch read: 1 to 20 pages of the Caper knowledge base in full in one call, which is how to read search or listing results. Pass `paths` as the listings return them. Paths that do not exist come back in `missing` rather than failing the call, anything past 20 in `remaining`, and pages past `maxChars` (default 250000) in `omitted` with their sizes.
- `get_recent_changes`: Pages of the Caper knowledge base edited within the last N days, newest first: what to poll when you are watching the wiki rather than reading it. Same rows as list_pages. Defaults: days 7 (max 30), limit 20 (max 50). `truncated: true` means the limit cut the list; raise it, or page through list_pages.
- `list_daos`: Index of the DAOs on Caper: cashtag, name, description, member count, wiki URL, and that DAO's own MCP endpoint. Use it to resolve a name to a cashtag, then POST JSON-RPC to the returned `mcpEndpoint` to reach its get_ledger (treasury balances, proposal/trade/execution timeline, executed grants, inter-DAO funding) – this knowledge-base server deliberately has no ledger tool. `query` is a case-insensitive substring over cashtag, name and description. Defaults: limit 50 (max 200); `hasMore` says whether the cap cut the list.
- `list_pages`: Browse the Caper knowledge base by tag path rather than by keyword: every page under a branch, newest first by default. `tagPath` matches the branch and everything beneath it; omit it to walk the whole wiki. Sort by title for an A–Z pass. Same rows as search_wiki, with `totalPages`, `hasMore` and `nextPage`. Defaults: page 1, pageSize 20 (max 100).
- `login`: Step 2: exchange the signed ROLA proof for a 12h Bearer token – the same verification the human wallet flow runs. Send the returned token as an HTTP `Authorization: Bearer <token>` header on every later tool call; MCP arguments never carry it.
- `save_wiki_page`: Create or edit a page on a DAO's company-layer wiki. Holders only – any amount of the DAO's token, its vote token or its founder badge. Pass the body as one HTML string; it becomes a standard content block (headings, paragraphs, lists, tables). Requires the Bearer token from the `login` tool, sent as an HTTP `Authorization: Bearer <token>` header on the POST carrying this call.
- `search_wiki`: Keyword search across the Caper knowledge base: the first call when you know what you are looking for but not where it lives. Matches titles and body prose, ranked in four tiers: titles starting with the term, titles containing it, literal body hits, then English full-text hits by relevance, which stem words and drop stopwords. Not semantic: one distinctive word beats a sentence. Each row carries a `path`, its size in `chars` and a snippet windowed on the match. Feed the paths to get_pages in one call rather than looping get_page. Narrow with tagPath when a term is common. Defaults: page 1, pageSize 20 (max 50); keep paging while `hasMore` is true.
- `submit_tx`: Step 4: register a committed transaction by txHash. Kinds: create-caper, buy, sell, proposal, vote, trigger. The server verifies before mirroring anything: receipts are re-read on-ledger (forged or foreign txHashes are refused, replays are idempotent). Context per kind: create-caper takes cashtag; proposal takes proposalId; trigger takes code (the P-… code). Requires the Bearer token from the `login` tool, sent as an HTTP `Authorization: Bearer <token>` header on the POST carrying this call.