ActSeal MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ACTSEAL_BASE | No | Base URL for ActSeal. Required unless using legacy ACTIONRECEIPT_BASE. | |
| ACTSEAL_API_KEY | No | ActSeal API key. Free key via https://actseal.xyz/get-key. Required unless using legacy ACTIONRECEIPT_API_KEY. | |
| ACTIONRECEIPT_BASE | No | Legacy base URL for ActSeal. Accepted as an alternative to ACTSEAL_BASE. | |
| ACTIONRECEIPT_API_KEY | No | Legacy ActSeal API key. Accepted as an alternative to ACTSEAL_API_KEY. |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| issue_receiptA | Issue an Ed25519-signed ActSeal receipt for a tool action. Pass SHA-256 hex hashes of inputs/outputs — never raw secrets. Optional Idempotency-Key. Free tier only; x402 not live. |
| verify_receiptA | Verify a receipt by id (public). Returns valid/invalid, receipt payload, and issuer public key. |
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 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.