# Caper Wiki (remote · caper.network)

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

- Trust score: 65/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-20

## Components

- remote · `caper.network`: 65/100 (this document), [markdown](https://verifymcp.io/servers/network-caper-caper-wiki/api-mcp.md), [page](https://verifymcp.io/servers/network-caper-caper-wiki/api-mcp)
- remote · `caper.network`: 25/100, [markdown](https://verifymcp.io/servers/network-caper-caper-wiki/wiki-caper-cashtag-mcp.md), [page](https://verifymcp.io/servers/network-caper-caper-wiki/wiki-caper-cashtag-mcp)

## Channel facts

- Endpoint: `https://caper.network/api/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `2.3.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-20.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 13 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 67/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 3340 tokens (~256/item across 13 items; 13 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 40/100
  - Spec-recency check failed: implements MCP spec 2025-03-26; the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http network-caper-caper-wiki https://caper.network/api/mcp
```

### Codex

```toml
[mcp_servers.network-caper-caper-wiki]
url = "https://caper.network/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "network-caper-caper-wiki": {
      "type": "remote",
      "url": "https://caper.network/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add network-caper-caper-wiki --url https://caper.network/api/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  network-caper-caper-wiki:
    url: "https://caper.network/api/mcp"
```

### Other

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

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-20 (score 65, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-18 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-16 (score 63, 0)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “get_manifest” rewrote its description, which is the text the model reads
- [security] Tool “submit_tx” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 231 → 256
- [functional] Server version: 2.2.1 → 2.3.0
- [cosmetic] “submit_tx” added an optional parameter “signedPartialTransaction”
- [cosmetic] “submit_tx” added an optional parameter “subintentHash”
- [cosmetic] “submit_tx” reworded the description of “proposalCode”
- [cosmetic] “submit_tx” reworded the description of “sequence”
- [cosmetic] “submit_tx” reworded the description of “txHash”
- [cosmetic] “submit_tx” made “txHash” optional

### 2026-08-15 (score 63, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-14 (score 62, 0)

- [security] The server rewrote its instructions, which are the text every model session reads
- [functional regression] Schema quality: 1793 → 3015
- [functional regression] Schema quality: 1793 → 2967
- [functional] The server no longer declares the “resources” capability
- [functional] Server version: 2.2.0 → 2.2.1
- [functional] Server version: 2.0.0 → 2.2.0
- [functional] New tool “get_challenge”
- [functional] New tool “get_manifest”
- [functional] New tool “login”
- [functional] New tool “save_wiki_page”
- [functional] New tool “submit_tx”

### 2026-08-13 (score 62, +1)

- [functional improvement] Stability: unverified → 0.03

### 2026-08-12 (score 61)

First indexed and scored.

## MCP tools (13)

### `search_wiki` (~215 tokens)

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 full body text (case-insensitive substring, not fuzzy: search one distinctive word like "quadratic", not a sentence). Returns summaries only, newest first, each with a `path`, a `chars` size and a 200-char snippet. 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.

Input parameters:

- `page` (number): 1-based page number (default 1)
- `pageSize` (number): Results per page (default 20, max 50)
- `query` (string, required): Search term. One distinctive word or short phrase beats a sentence.

### `get_page` (~208 tokens)

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.

Input parameters:

- `path` (string): Full page path, e.g. "governance/voting". Preferred over tagPath+slug.
- `slug` (string): Page slug, e.g. "voting". Ignored when `path` is set.
- `tagPath` (string): Tag path only, e.g. "governance" ("" for a top-level page). Ignored when `path` is set.

### `get_pages` (~227 tokens)

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.

Input parameters:

- `maxChars` (number): Total character budget across returned pages (default 250000, max 1000000)
- `paths` (array, required): Page paths, e.g. ["economics/token-valuation", "desci/desci-funding"]. 1-20 per call.

### `list_pages` (~241 tokens)

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.

Input parameters:

- `page` (number): 1-based page number (default 1)
- `pageSize` (number): Results per page (default 20, max 100)
- `sort` (string): Sort order (default "updatedAt", newest first)
- `tagPath` (string): Branch to list, e.g. "daos" or "dao-governance/concepts". Prefix match, includes descendants.

### `get_recent_changes` (~153 tokens)

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.

Input parameters:

- `days` (number): Look back this many days (default 7, max 30)
- `limit` (number): Max pages returned (default 20, max 50)

### `get_categories` (~94 tokens)

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.

### `get_full_corpus` (~270 tokens)

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.

Input parameters:

- `maxChars` (number): Character budget for `document` (default 200000, max 1000000)
- `sizeOnly` (boolean): Return sizes and breakdowns only, no document. Do this before the first real pull.
- `skip` (number): Resume from this page index – pass the `nextSkip` from the previous truncated call (default 0)
- `tagPath` (string): Restrict to one branch and its descendants, e.g. "desci". Omit for everything.

### `list_daos` (~183 tokens)

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.

Input parameters:

- `limit` (number): Max DAOs returned (default 50, max 200)
- `query` (string): Filter by cashtag, name or description (case-insensitive substring). Omit for all.

### `get_challenge` (~76 tokens)

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.

### `login` (~141 tokens)

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.

Input parameters:

- `address` (string, required): Your account address (virtual account of the signing key)
- `challenge` (string, required): The challenge from get_challenge
- `curve` (string, required): Signing curve (Ed25519 = "curve25519")
- `publicKey` (string, required): Ed25519 public key, hex
- `signature` (string, required): Signature over the ROLA message, hex

### `get_manifest` (~498 tokens)

Step 3: a ready-to-sign transaction manifest. Kinds: create-caper, buy, sell, create-proposal, vote. 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 + optionsJson (a JSON array string, e.g. '[{"title":"Yes","description":"","isNo":false}]'); vote needs proposalCode + sequence. You sign and submit the manifest yourself with your own key, then register the txHash with submit_tx. Kind vote is the exception: it returns a SUBINTENT package ({ subintentManifest, governanceVault, header, expiration, feeXrd }), not a transaction – sign it as a SignedPartialTransactionV2 and register the blob with submit_tx kind "ballot"; nothing hits the ledger until the settlement batch after voting closes. Requires the Bearer token from the `login` tool, sent as an HTTP `Authorization: Bearer <token>` header on the POST carrying this call.

Input parameters:

- `account` (string, required): Your account address (pays fees, receives tokens)
- `cashtag` (string): Target caper's cashtag (all kinds except vote)
- `description` (string): create-caper / create-proposal: description text
- `governanceType` (string): create-proposal: "legislative" (signal, default) or "executive"
- `iconUrl` (string): create-caper: optional icon URL (defaults to a generated one)
- `infoUrl` (string): create-caper: optional https project URL
- `kind` (string, required): What the transaction does
- `name` (string): create-caper: the caper's name
- `optionsJson` (string): create-proposal: JSON array of option drafts
- `originToken` (string): create-caper: optional origin-token resource address (vampire launch)
- `proposalCode` (string): vote: the proposal's P-… code
- `sequence` (array): vote: ranked 0-based option indexes, best first, EVERY option exactly once
- `title` (string): create-proposal: proposal title
- `tokens` (number): sell: caper tokens to sell
- `xrd` (number): buy: XRD to spend

### `submit_tx` (~330 tokens)

Step 4: register a committed transaction by txHash – or, for kind ballot, a signed vote subintent (nothing is on-ledger yet). Kinds: create-caper, buy, sell, proposal, ballot. The server verifies before mirroring anything: receipts are re-read on-ledger (forged or foreign txHashes are refused, replays are idempotent), and ballot blobs are decompiled and matched against the exact vote they claim. Context per kind: create-caper takes cashtag; proposal takes proposalId; ballot takes proposalCode + sequence + subintentHash + signedPartialTransaction, and NO txHash. Requires the Bearer token from the `login` tool, sent as an HTTP `Authorization: Bearer <token>` header on the POST carrying this call.

Input parameters:

- `cashtag` (string): create-caper: the cashtag, so the response can confirm the row
- `kind` (string, required): What the transaction did
- `proposalCode` (string): ballot: the proposal's P-… code
- `proposalId` (number): proposal: the id from the create-proposal manifest response
- `sequence` (array): ballot: the ranked option indexes you signed into the subintent
- `signedPartialTransaction` (string): ballot: the hex-compiled SignedPartialTransactionV2 blob
- `subintentHash` (string): ballot: the subintent hash (subtxid_…) of the signed ballot
- `txHash` (string): The committed transaction intent hash (txid_…) – required for every kind EXCEPT ballot

### `save_wiki_page` (~181 tokens)

Create or edit a page on a DAO's company-layer wiki. Members only – any buy of the DAO's token makes you a member. 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.

Input parameters:

- `daoId` (string, required): Cashtag of the DAO whose wiki to edit
- `html` (string, required): Page body as HTML, e.g. <h2>…</h2><p>…</p>
- `slug` (string, required): Page slug
- `tagPath` (string): Optional tag path, e.g. "updates" ("" = top level)
- `title` (string, required): Page title

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/network-caper-caper-wiki/api-mcp#diagnostics

## Score history

- 2026-08-20: 65
- 2026-08-19: 64
- 2026-08-18: 64
- 2026-08-17: 63
- 2026-08-16: 63
- 2026-08-15: 63
- 2026-08-14: 62
- 2026-08-13: 62
- 2026-08-12: 61

## Links

- Remote endpoint: https://caper.network/api/mcp
- Website: https://caper.network/
- Changelog RSS feed: https://verifymcp.io/servers/network-caper-caper-wiki/api-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/network-caper-caper-wiki/api-mcp.json
- HTML version of this page: https://verifymcp.io/servers/network-caper-caper-wiki/api-mcp