Screwtape.ai

Action Receipts

action_receipt

Idempotent

Action Receipts: Ed25519-signed, hash-chained attestation of an agent-reported action and status; not evidence the action happened or a legal compliance certification. Per caller and agent chain; concurrent appends serialize with compare-and-set. Raw action/reference are hashed, not stored. event_id per agent is the authoritative idempotency key; a custom HTTP key cannot override it. Same event_id/body returns the same receipt; changed body conflicts. Optional children (1-64 receipt UUIDs) closes a run: the signed children_root digests ordered child receipt_hash values so any added, dropped or swapped step fails verification. GET /v1/receipt/verify?id=<receipt_id> is free and returns the receipt to anyone who knows its unguessable ID; children_root_valid is set when children are present. A receipt proves the record is unchanged since issued, not that a payment was correct or an outside action happened. Or pass receipt= to verify a portable receipt. Keep IDs private if your agent IDs/status are sensitive. Records persist until the API key is deleted; keyless records have no automatic expiry. $0.003 per call; shared 3 free calls per UTC day without a key (daily private IP namespace), plus 10/day with a free key. Anonymous scopes rotate daily; use a key for a persistent ledger/chain. Send the same Bearer key plus a payment header to keep the same ledger/chain after the allowance runs out.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "agent_id": "<agent_id>",
      "event_id": "<event_id>",
      "action": "<action>",
      "status": "<status>"
    },
    "name": "action_receipt"
  }
}

Input Schema

Name	Required	Description
`action`	Yes
`status`	Yes
`agent_id`	Yes
`children`	No	Ordered child receipt ids. Signs children_root over their receipt_hash values so any added, dropped or swapped step fails verification.
`event_id`	Yes
`reference`	No
`action_sha256`	No

Output Schema

Name	Required	Description	Default
`receipt`	Yes
`keys_url`	Yes
`replayed`	No
`request_id`	No
`verify_url`	Yes
`receipt_hash`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 9, 2026

addedInput schema / properties / children

Added value: +{
+  "description": "Ordered child receipt ids. Signs children_root over their receipt_hash values so any added, dropped or swapped step fails verification.",
+  "items": {
+    "pattern": "^[0-9a-f-]{36}$",
+    "type": "string"
+  },
+  "maxItems": 64,
+  "minItems": 1,
+  "type": "array",
+  "uniqueItems": true
+}

addedOutput schema / properties / receipt / properties / children

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / receipt / properties / children_root

Added value: +{
+  "description": "SHA-256 of canonical JSON of ordered child receipt_hash values.",
+  "type": "string"
+}

AddedNov 7, 2026

TDQS

A3.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (idempotentHint=true, destructiveHint=false), the description discloses a great deal: raw action/reference are hashed and never stored, concurrent appends serialize via compare-and-set, records persist until the API key is deleted with no expiry for keyless records, receipts are publicly readable by anyone with the unguessable ID, and rate/price limits are spelled out. The idempotency semantics (same event_id/body returns the same receipt, changed body conflicts, HTTP key cannot override event_id) directly enrich the annotation rather than merely restating it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the key caveats are front-loaded, but the body degenerates into a long semicolon-chained run-on mixing semantics, pricing, free-tier allowances, and privacy advice. Almost every clause is informative, yet the lack of paragraphing or ordering makes it harder to scan than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a metered, signed-ledger write tool with an output schema and annotations, the description covers the important agent-facing questions: what is stored vs hashed, idempotency, chaining, persistence, cost, and verification. Remaining gaps are the undocumented action_sha256 parameter and the verify/portable-receipt modes that the schema does not accept.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 14% schema description coverage, the description carries most of the burden, and it does: event_id is named the authoritative idempotency key, children are explained as an ordered set digesting receipt_hash values into children_root (and the schema's own children description covers this too), and action/reference are explained as hashed rather than stored. The 'action_sha256' parameter is never mentioned, leaving one gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description defines the resource precisely: an 'Ed25519-signed, hash-chained attestation of an agent-reported action and status', including what it is not (not proof the action happened, not legal certification). It is clear what is produced, but it never distinguishes itself from the sibling 'publish_receipt', which an agent could easily confuse with this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: 'Optional children (1-64 receipt UUIDs) closes a run' tells the agent when to supply children, and the verify endpoint and the portable-receipt path are described as alternatives. However, there is no explicit when-to-use/when-not-to-use guidance against siblings, and 'pass receipt=<JSON>' describes a mode that the input schema does not expose, which could mislead an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Screwtape.ai tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?