Agent Workbench Pack

Raven is a signed evidence-and-receipt layer for AI agents before they touch a Solana token. This pack makes Raven usable from YOUR workbench — Codex, Claude, Cursor, Gemini, any MCP client or framework — with no human browsing required. Copy the pieces below into your agent.

1. Load context

https://ravenattest.com/raven-agent-context.md

https://ravenattest.com/raven-agent-skill.md

https://ravenattest.com/prompt-recipes.json

2. Call Raven

npx -y raven-verify-mcp

curl -s -X POST https://raven-hosted-verifier.onrender.com/receipt/v1 \
  -H "x-api-key: $RAVEN_KEY" -H "content-type: application/json" \
  -d '{"mintAddress":"...","tokenProgramAddress":"..."}'

curl -s https://raven-hosted-verifier.onrender.com/pubkey

The local MCP output is unsigned and is not a signed receipt-v1 deliverable or a substitute for POST /receipt/v1. POST /verify is legacy v2 compatibility only. For current receipt verification, use the reviewed raven-receipt-verifier package supplied through an authenticated pilot/release handoff; it is not yet published on npm.

Raven's ACP offering solana_verify_token (0.1 USDC/job, escrowed) is sandbox-only and not publicly listed, so it cannot be hired agent-to-agent today. Request a key for the hosted API. Contract: /openapi.json.

3. Verify & store the receipt

1. Pin the signer key independently -> match signerPublicKey against your pin; GET /pubkey is a cross-check
2. Recompute payloadHash over the receipt-v1 body (canonical JSON; /receipt-v1-test-vector.json)
3. Check receiptId and verify the ed25519 signature over canonicalJson({domain:"raven-receipt",version:"v1",payloadHash})
4. Store the FULL receipt with the action it gates (key policy: /key-policy.json)

3b. Store per the memory policy

For receipt-v1, store the exact response object and the separate local verification result; the current wire example is /receipt-v1-test-vector.json. The older /receipt-schema.json and /receipt-wire-schema.json describe legacy v2 storage compatibility. Policy: /receipt-memory-policy.md. Check stored receipts before re-calling; verify before use; storage failure never changes signed evidence.

4. Decide: proceed / block / escalate

risk        -> block, or human review
warning     -> human review unless policy explicitly allows
unknowable  -> do not proceed
no listed finding triggered + coverageGaps -> "not enough evidence for a full pass";
               proceed only if policy accepts those exact gaps
never call a token safe while gaps remain
store every receipt; escalate verification MISMATCH as an incident

False confidence is the failure mode. coverageGaps is normative — anything listed was NOT evaluated. Test us first: /evals.