Caper Wiki
REMOTE · CAPER.NETWORK · 2 COMPONENTS · SCANNED AUG 20
Read Caper's wiki and DAO on-chain data; launch a DAO, trade, propose and vote on Radix testnet.
Available components
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. How we score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- 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. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability67
- AI-judged instruction clarity (excellent).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management27
- Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Capabilities40
- Spec-recency check failed: implements MCP spec 2025-03-26; the latest is 2026-07-28. See how to fix → Fail
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
remote · caper.network
claude mcp add --transport http network-caper-caper-wiki https://caper.network/api/mcp
[mcp_servers.network-caper-caper-wiki] url = "https://caper.network/api/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"network-caper-caper-wiki": {
"type": "remote",
"url": "https://caper.network/api/mcp",
"enabled": true
}
}
} openclaw mcp add network-caper-caper-wiki --url https://caper.network/api/mcp --transport streamable-http
mcp_servers:
network-caper-caper-wiki:
url: "https://caper.network/api/mcp" {
"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.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 20 Aug 26 +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.
- 18 Aug 26 +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.
- 16 Aug 26 0
- 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 security
- Schema quality: 231 → 256 ▼ functional
- Server version: 2.2.1 → 2.3.0 functional
- “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 cosmetic
- 15 Aug 26 +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.
- 14 Aug 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Schema quality: 1793 → 3015 ▼ functional
- 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” functional
- 13 Aug 26 +1
- Stability: unverified → 0.03 ▲ functional
- 12 Aug 26 61
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Aug 2026 · Probed https://caper.network/api/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=caper.network | CN=YR1,O=Let's Encrypt,C=US | 4 Jul 2026 | 2 Oct 2026 | RSA 2048 | SHA256-RSA | 50255183510124462b094f20942d833f7bd |
| SANs: caper.network | ||||||
| CN=YR1,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | a20253f15f2691c05dc1ce13b9bcca4e |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
DNSSEC insecure
Validation of caper.network. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| network. | present | 40414 | 8 | Verified |
| caper.network. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000; includeSubDomains; preload |
| content-security-policy | default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https://*.supabase.co https://arweave.net https://*.radixdlt.com https://*.public.blob.vercel-storage.com; font-src 'self' data:; frame-src https://www.youtube.com https://www.youtube-nocookie.com https://platform.twitter.com https://www.google.com https://maps.google.com https://embed.apple.com https://maps.apple.com; connect-src 'self' https://*.radixdlt.com |
| x-content-type-options | nosniff |
| x-frame-options | DENY |
| referrer-policy | strict-origin-when-cross-origin |
| permissions-policy | camera=(), microphone=(), geolocation=() |
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://caper.network/api/mcp | Verified | 200 | |
| http (plaintext) | http://caper.network/api/mcp | HTTPS enforced | 308 | https://caper.network/api/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
get_categories ~94
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_challenge ~76
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_full_corpus ~270
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No output schema declared.
No examples provided.
get_manifest ~498
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.
| Name | Type | Req | Description |
|---|---|---|---|
| account | string | yes | 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 | yes | 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 |
No output schema declared.
No examples provided.
get_page ~208
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No output schema declared.
No examples provided.
get_pages ~227
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.
| Name | Type | Req | Description |
|---|---|---|---|
| maxChars | number | – | Total character budget across returned pages (default 250000, max 1000000) |
| paths | array | yes | Page paths, e.g. ["economics/token-valuation", "desci/desci-funding"]. 1-20 per call. |
No output schema declared.
No examples provided.
get_recent_changes ~153
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.
| Name | Type | Req | Description |
|---|---|---|---|
| days | number | – | Look back this many days (default 7, max 30) |
| limit | number | – | Max pages returned (default 20, max 50) |
No output schema declared.
No examples provided.
list_daos ~183
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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | number | – | Max DAOs returned (default 50, max 200) |
| query | string | – | Filter by cashtag, name or description (case-insensitive substring). Omit for all. |
No output schema declared.
No examples provided.
list_pages ~241
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No output schema declared.
No examples provided.
login ~141
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.
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | Your account address (virtual account of the signing key) |
| challenge | string | yes | The challenge from get_challenge |
| curve | string | yes | Signing curve (Ed25519 = "curve25519") |
| publicKey | string | yes | Ed25519 public key, hex |
| signature | string | yes | Signature over the ROLA message, hex |
No output schema declared.
No examples provided.
save_wiki_page ~181
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.
| Name | Type | Req | Description |
|---|---|---|---|
| daoId | string | yes | Cashtag of the DAO whose wiki to edit |
| html | string | yes | Page body as HTML, e.g. <h2>…</h2><p>…</p> |
| slug | string | yes | Page slug |
| tagPath | string | – | Optional tag path, e.g. "updates" ("" = top level) |
| title | string | yes | Page title |
No output schema declared.
No examples provided.
search_wiki ~215
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.
| Name | Type | Req | Description |
|---|---|---|---|
| page | number | – | 1-based page number (default 1) |
| pageSize | number | – | Results per page (default 20, max 50) |
| query | string | yes | Search term. One distinctive word or short phrase beats a sentence. |
No output schema declared.
No examples provided.
submit_tx ~330
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.
| Name | Type | Req | Description |
|---|---|---|---|
| cashtag | string | – | create-caper: the cashtag, so the response can confirm the row |
| kind | string | yes | 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 |
No output schema declared.
No examples provided.