ActSeal MCP
# ActSeal MCP
stdio MCP server for [ActSeal](https://actseal.xyz) — Ed25519-signed receipts for agent actions.
| Tool | Purpose |
|------|---------|
| `issue_receipt` | `POST /v1/receipt` — action + inputs_hash + outputs_hash (+ optional policy_id, idempotency_key) |
| `verify_receipt` | `GET /v1/verify/:id` — public verify |
**Honesty:** best-effort signed log. Not legal evidence, not SOC2, not custody, not e-sign. Free 100 receipts/API-key/UTC-day; Starter $19/mo in USDC/USDT/ETH at https://actseal.xyz/pay.
## Env
| Var | Required | Example |
|-----|----------|---------|
| `ACTSEAL_BASE` | yes* | `https://actseal.xyz` |
| `ACTSEAL_API_KEY` | yes* | free key via https://actseal.xyz/get-key |
\* Legacy `ACTIONRECEIPT_BASE` / `ACTIONRECEIPT_API_KEY` still accepted.
## Run
```bash
pnpm install
export ACTSEAL_BASE=https://actseal.xyz
export ACTSEAL_API_KEY=as_…
pnpm start
```
## Cursor / Claude Desktop
```json
{
"mcpServers": {
"actseal": {
"command": "npx",
"args": ["--yes", "tsx", "/ABSOLUTE/PATH/actseal-mcp/src/index.ts"],
"env": {
"ACTSEAL_BASE": "https://actseal.xyz",
"ACTSEAL_API_KEY": "YOUR_KEY"
}
}
}
}
```
## Links
- Site: https://actseal.xyz
- Docs: https://actseal.xyz/docs
- OpenAPI: https://actseal.xyz/openapi.json
- llms.txt: https://actseal.xyz/llms.txt
## Docker / Glama
```bash
docker build -t actseal-mcp .
docker run -i --rm \
-e ACTSEAL_BASE=https://actseal.xyz \
-e ACTSEAL_API_KEY=YOUR_KEY \
actseal-mcp
```
Glama listing: https://glama.ai/mcp/servers/arults/actseal-mcp (after submit + score).
`glama.json` lists maintainer `arults`.
TDQS
Scored across 2 tools
issue_receipt and verify_receipt have clearly opposite, non-overlapping purposes (creation vs. validation), and the descriptions reinforce the distinction. An agent can select between them with no ambiguity.
Both tools follow the same snake_case verb_noun pattern (issue_receipt, verify_receipt). The naming is fully predictable and symmetric.
Two tools is thin for a general-purpose server, but for the narrow domain of issuing and verifying signed receipts the pair is reasonably scoped. It sits just under the typical comfortable range rather than being an extreme mismatch.
The core lifecycle (issue then verify) is fully covered with no dead ends for the primary workflow. Minor gaps exist, such as listing receipts or revoking/invalidating one, which agents would have to work around.