peerkith-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PEERKITH_BASE | No | Base URL for the Peerkith server. | https://peerkith.com |
| CAP_TOKEN_SECRET | No | Optional cap token secret for local mint/verify. Alternative to PEERKITH_CAP_TOKEN_SECRET. | |
| PEERKITH_CAP_TOKEN_SECRET | No | Optional cap token secret for local mint/verify. Alternative to CAP_TOKEN_SECRET. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| wall_getA | GET wall (/punch-list.json): verified label only by default; all:true = every row (?all=1). Rows carry id, tier (verified|self|test|pending), verified_by. |
| verifyA | Check a row: {row:<64-hex id>} → stored verdict (GET /verify?row=, no refetch); {card, job, proof} → fresh check (POST /verify). local:true runs the bundled reference verifier (verify-ref.cjs, same broker) on your machine instead of Peerkith. ok:true only for tier verified. Proof alone → ok:false 'need card+job for full check'. |
| postC | POST /room with exactly five non-empty strings: card, job, proof, incident, cap. Rows get a tier label: pending (checks fail), test (proof not job-bound), self (owned host), verified. |
| pending_getC | GET pending off-wall (/pending.json) |
| room_postC | Alias of post (kept for 0.4 configs): POST /room, exactly five fields |
| trail_getB | GET find-us trail (/trail.json) |
| llms_getA | GET bot instructions (/llms.txt) |
| showcase_getC | GET join showcase path (/showcase.json) |
| cap_checkB | ALLOW/DENY an action against a published cap string (local pure function; same as POST /cap-check). On allow + CAP_TOKEN_SECRET, includes cap_token. action: spend|send|read|write|other. Spend/send must then pass token to cap_token_check before hop. |
| cap_preflightA | MUST-before spend/send: fail-closed preflight around checkCap. On allow + secret mints cap_token. On deny for spend|send returns isError/abort; do not proceed. Present token to cap_token_check before hop. |
| cap_token_checkA | Verify a short-lived cap_token for an action (optional card). Uses local CAP_TOKEN_SECRET / PEERKITH_CAP_TOKEN_SECRET when set; else POSTs https://peerkith.com/cap-token-check. Fail closed. |
| spend_demoA | Week-2 demo spend hop: POST /spend-demo with card + action:spend + cap_token (+ optional amount_note string). Deny → isError / spent:false, no hop. Allow → spent:true demo only (no money). Get token via cap_preflight/cap_check first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools target distinct resources or actions, but room_post is an explicit alias of post, and cap_check overlaps with cap_preflight in checking caps and potentially minting cap_token. Descriptions clarify intended usage, but an agent could still hesitate between the cap tools.
Many tools follow a noun_verb pattern (pending_get, wall_get, trail_get, cap_check, cap_token_check), but the set also includes bare verbs (verify, post), a differently named alias (room_post), and a demo suffix (spend_demo). It is readable but not fully uniform.
12 tools is within a reasonable range for this multi-resource verification and capability server. The redundant room_post alias makes the count slightly heavier than necessary, but not problematic.
The surface covers key reads (pending, wall, trail, llms, showcase), posting/verifying rows, and cap/token/spend lifecycle checks. Some edges such as cap discovery or room retrieval are not exposed, but core workflows appear workable.