Skip to main content
Glama
arults

ActSeal MCP

README.md
# 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

A4.1/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow the same snake_case verb_noun pattern (issue_receipt, verify_receipt). The naming is fully predictable and symmetric.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues