1F916

Record an instruction and an action

record_mandate

Record a mandate: what you were told (instruction), what you did (action) and optionally what came of it (outcome), each as text or as its sha-256. The fingerprints (two, or three with an outcome) are combined and sealed into your chain as one memory.seal, so every later stamp, witness signature and anchor covers them. public:true stores any text you sent openly for anyone; otherwise only the fingerprints of that text are kept, plus an optional base64 envelope the registry stores without interpreting (encrypt it yourself). A fingerprint is public even for a private mandate, so text short enough to guess can be recognized from it. Recording on behalf of someone else: subject says who the record was made for, and signature proves the record is your own; both are sealed through the commit. Returns the mandate id, its page, the commit payload and how to verify. WRITES: this call changes stored state and is not safe to repeat blindly.

Input Schema

TableJSON Schema

Name	Required	Description
`label`	No	optional, up to 64 of [a-z0-9._-], e.g. the app the action ran in
`action`	No	what you did; or send action_hash
`public`	No	true stores the text openly; default false keeps fingerprints only
`secret`	Yes
`outcome`	No	optional: what came of it (a transaction hash, a receipt, a result)
`subject`	No	optional: who the record was made for, when you record on behalf of someone else. 1 to 128 of [A-Za-z0-9._:-], for example wallet:0x... or user:7f3a. Public and never interpreted; send a fingerprint of an id you would not publish
`envelope`	No	optional base64 bytes, meant to be the text encrypted with a key only your owner holds; stored as sent, never interpreted. The tool at /tools/envelope.mjs makes one on your own machine, in the standard age format
`signature`	No	optional: base64url Ed25519 signature by one of your bound keys over the UTF-8 string 1f916.mandate.sig.v1:<your handle>:<instruction sha-256>:<action sha-256>:<outcome sha-256 or ->:<sha-256 of subject or ->
`action_hash`	No
`instruction`	No	the text you were told, up to 16,000 characters; or send instruction_hash instead
`outcome_hash`	No
`instruction_hash`	No	64 hex chars of sha-256, when you keep the text yourself

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

changedInput schema / properties / envelope / description

Previous value: -"optional base64 bytes, meant to be the text encrypted with a key only you hold; stored as sent, never interpreted"New value: +"optional base64 bytes, meant to be the text encrypted with a key only your owner holds; stored as sent, never interpreted. The tool at /tools/envelope.mjs makes one on your own machine, in the standard age format"

Changed2 schema fields changedSep 28, 2026

addedInput schema / properties / signature

Added value: +{
+  "description": "optional: base64url Ed25519 signature by one of your bound keys over the UTF-8 string 1f916.mandate.sig.v1:<your handle>:<instruction sha-256>:<action sha-256>:<outcome sha-256 or ->:<sha-256 of subject or ->",
+  "type": "string"
+}

addedInput schema / properties / subject

Added value: +{
+  "description": "optional: who the record was made for, when you record on behalf of someone else. 1 to 128 of [A-Za-z0-9._:-], for example wallet:0x... or user:7f3a. Public and never interpreted; send a fingerprint of an id you would not publish",
+  "type": "string"
+}

AddedSep 25, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: it explains that fingerprints are combined and sealed into a chain that later stamps, witnesses and anchors cover; that public:true publishes text openly while private keeps fingerprints only; that fingerprints of guessable short text are still recognizable; that subject/signature are sealed through the commit; and it explicitly warns 'WRITES: this call changes stored state and is not safe to repeat blindly' — adding non-idempotency context not conveyed by destructiveHint=false alone.

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

Conciseness4/5

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

Dense but nearly waste-free, and front-loaded with the core record-a-mandate statement before the sealing/privacy/signature detail. The privacy and signature sentences are long and somewhat run-on, but each carries non-redundant information needed to call the tool safely.

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 12-parameter cryptographic write tool with no output schema, the description covers the sealing model, privacy trade-offs, delegation case, signature format source, and even the return shape ('mandate id, its page, the commit payload and how to verify'). Only the unexplained 'secret' parameter and the absence of explicit sibling routing keep it from complete.

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?

Schema coverage is 75%, so the schema carries much of the load, but the description meaningfully adds semantics: the text-vs-sha256 duality for instruction/action/outcome, the privacy implication of subject fingerprinting, the intent of envelope (never interpreted, encrypt yourself), and the signature's binding role. The 'secret' parameter is left entirely unexplained, keeping this below a 5.

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

Purpose5/5

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

States a specific verb and resource ('Record a mandate') and immediately decomposes it into the three components (instruction, action, optional outcome) in the exact shape the schema expects. An agent can distinguish this from sibling 'mandate'/'mandates' (reads) and 'record_outcome' (outcome-only) without opening any schema.

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 context is implied through the public/private switch, the 'recording on behalf of someone else' case, and the pointer to /tools/envelope.mjs for envelope creation, but there is no explicit when-to-use / when-not-to-use or named alternative among the many siblings (seal, mandate, record_outcome). Guidance is present but inferential.

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

All 1F916 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?