spArxx.io | Zero-Knowledge Blockchain Timestamping

create_timestamp

Compute the SHA-256 hash of the file locally - the file itself is never uploaded, and spArxx.io never stores it. Call this with that hash plus basic file metadata to register a provenance timestamp. This deducts spArks from the account (dynamic cost. Call get_pricing or get_balance first if you want to pre-check spend; a 402 response here means ins...

Input Schema

TableJSON Schema

Name	Required	Description	Default
`body`	Yes	Exactly one of file_hash/client_hash and exactly one of file_size/file_size_bytes must be present. These are aliases kept for client compatibility, not two different values.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`status`	No
`message`	No
`correlation_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedSep 13, 2026

changedInput schema / properties / body / description

Previous value: -"Exactly one of file_hash/client_hash and exactly one of file_size/file_size_bytes must be present — they are aliases kept for client compatibility, not two different values."New value: +"Exactly one of file_hash/client_hash and exactly one of file_size/file_size_bytes must be present. These are aliases kept for client compatibility, not two different values."

changedInput schema / properties / body / properties / disclose_identity / description

Previous value: -"Whether this certificate's verify page/API/manifest should disclose the account's name and email together, or withhold both. Omit to inherit the account's own disclose_identity_default preference. Ignored for Ghost/unclaimed accounts, which are always anonymous regardless of this value."New value: +"Per-transaction override for whether this certificate's verify page/API/manifest discloses the account's name and email together, or withholds both. Omit to inherit the account's stored disclose_identity_default preference (defaults to true if never set). Ghost/guest accounts always withhold identity regardless of this value ... there is no toggle for them."

addedInput schema / properties / body / properties / file_name / description

Added value: +"The file's name as the caller knows it (e.g., 'final_mix.wav'). Used for display and is included in the receipt kit. Required; not used to derive mime_type or validate the hash."

addedInput schema / properties / body / properties / mime_type / description

Added value: +"Optional MIME type of the file (e.g., 'audio/wav', 'image/png'), if known. Purely informational, and stored with the evidence record, not independently verified against file content."

addedInput schema / properties / body / properties / original_file_name / description

Added value: +"Optional: the file's original name, if different from file_name (e.g., before local renaming). Purely informational, stored with the evidence record."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "correlation_id": {
+      "type": "string"
+    },
+    "data": {
+      "properties": {
+        "action": {
+          "example": "EJECT_REQUIRED",
+          "type": "string"
+        },
+        "cost_deducted": {
+          "description": "Actual spArks deducted for this call. Dynamic. Driven by the TIMESTAMP_COST env var (default 25), not a fixed 1 spark.",
+          "type": "integer"
+        },
+        "custody_status": {
+          "example": "self_custody",
+          "type": "string"
+        },
+        "evidence_id": {
+          "format": "uuid",
+          "type": "string"
+        },
+        "remaining_credits": {
+          "type": "number"
+        },
+        "sparks_remaining": {
+          "type": "number"
+        },
+        "status": {
+          "example": "pending",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "type": "string"
+    },
+    "status": {
+      "example": "success",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 11, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that the file is never uploaded or stored, that the call deducts spArks at a dynamic cost, that spend can be pre-checked with sibling tools, and that a 402 signals insufficient funds. It omits any statement about reversibility, idempotency, or what a successful registration yields, and the 402 clause is truncated.

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 privacy and cost facts are appropriately front-loaded in a small number of sentences with little filler. However, the description terminates mid-sentence ('a 402 response here means ins...'), which is a structural defect that leaves a key error semantic dangling.

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 mutating, cost-incurring tool with a rich output schema and no annotations, the description covers the essentials: privacy model, cost, pre-check path, and failure signal. The truncated 402 clause and the absence of any note on idempotency or re-timestamping keep it short of complete.

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

Parameters3/5

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

Schema description coverage is 100%, and the nested body schema documents every field including the file_hash/client_hash and file_size/file_size_bytes aliases with their mutual-exclusion rule. The description only summarizes this as 'that hash plus basic file metadata' and adds no meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 names a specific verb+resource ('register a provenance timestamp') and clarifies the core mechanic (hash computed locally, file never uploaded). It is clearly distinguishable from siblings like verify_certificate and list_evidence, though it does not explicitly name those siblings. A clear, non-tautological statement of purpose.

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

Usage Guidelines4/5

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

Gives concrete when-to-use context: compute the hash locally first, then call with hash plus metadata, and pre-check spend via get_pricing or get_balance. It also states the 402 condition that indicates insufficient funds. The final sentence is cut off mid-word, so the error-handling guidance is incomplete.

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

All spArxx.io | Zero-Knowledge Blockchain Timestamping tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?