Built for human creators. Register a timestamp on Polygon proving you made something, the moment you did. Your file is never uploaded, watermarked, or altered: only its cryptographic fingerprint ever reaches spArxx.io, zero-knowledge by design. A human still provisions the account behind the connection. This is deliberate, since this registration only means something with a human behind it.
Scored across 6 tools
Each tool targets a distinct action: create_timestamp, get_balance, get_evidence, get_pricing, list_evidence, verify_certificate. No overlaps; even list vs get are clearly separated by summary vs full receipt.
All tool names follow a consistent verb_noun pattern with snake_case (create_timestamp, get_balance, get_evidence, get_pricing, list_evidence, verify_certificate). Predictable and uniform.
6 tools is well within the ideal 3-15 range for a focused timestamping service. Each tool serves a necessary function without redundancy.
Covers the full lifecycle: create, list, retrieve, verify, plus balance and pricing for operational decisions. No missing critical operations for the immutable timestamping domain.
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...
| 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. |
| Name | Required | Description |
|---|---|---|
| data | No | |
| status | No | |
| message | No | |
| correlation_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: the file is "never uploaded, and spArxx.io never stores it," the tool "deducts spArks from the account" with dynamic cost, and a 402 response signals a spending failure. This is precisely the side-effect and privacy context an agent needs beyond what the schema conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded: the crucial privacy property and local-hash workflow lead, followed by cost guidance and error semantics. The visible text contains no filler, though it is a single unbroken paragraph and is truncated mid-sentence at "a 402 response here means ins...".
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating, cost-deducting tool with nested alias parameters and no annotations, the description covers the essentials: local workflow, no-upload guarantee, spend pre-check, and a 402 signal. An output schema is present so return values need no explanation, but the truncated sentence leaves 402 semantics incomplete and auth requirements are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents each parameter's meaning, constraints, and alias relationships (file_hash/client_hash, file_size/file_size_bytes), including the body-level rule that exactly one of each alias pair must be present. The description adds only workflow framing ("that hash plus basic file metadata") rather than new per-parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: "register a provenance timestamp" using a locally-computed hash plus file metadata. It clearly separates the caller's local hash computation from the tool's registration role, and the create_ prefix distinguishes it from the read/verify sibling tools (get_evidence, verify_certificate, list_evidence).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes to siblings: "Call get_pricing or get_balance first if you want to pre-check spend," giving conditional context for using alternatives. It implies when to use the tool (after computing a local SHA-256 hash) but does not spell out when to prefer verify_certificate or get_evidence instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this before create_timestamp if you want to pre-check that the account can afford the operation and explain a likely 402 in advance, rather than reacting to one after the fact. Combine with get_pricing to compare balance against cost.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that calling it helps pre-check affordability and explain 402 errors, which is useful behavioral context. However, it doesn't mention whether this is a read-only operation, if it requires authentication, or any rate limits. An output schema exists, so return format is covered elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the main use case. No wasted words, though it could be slightly more direct in stating what it returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a zero-parameter balance-check tool with an output schema, the description provides sufficient context about when and why to use it. It covers the key integration point with create_timestamp and get_pricing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to describe. Baseline for zero params is 4, and the description appropriately focuses on usage context rather than nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description implies reading an account balance and frames it as a pre-check for affordability, which is a specific enough verb+resource. It doesn't explicitly state 'returns the account balance' but the intent is clear from context. It distinguishes itself from siblings by naming create_timestamp and get_pricing as related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: before create_timestamp to pre-check affordability and explain a likely 402. It also recommends combining with get_pricing. However, it doesn't say when NOT to use it or provide alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the complete receipt kit for a single evidence item: hash, file metadata, status, and, once the on-chain job has settled, the blockchain transaction hash and explorer URL. Poll this after create_timestamp until status is 'submitted', then save the full response alongside the original file as the durable proof-of-timestamp record. This is th...
| Name | Required | Description | Default |
|---|---|---|---|
| pathParams | Yes |
| Name | Required | Description |
|---|---|---|
| data | No | The receipt kit: everything an agent needs to prove a hash was timestamped, without ever holding the original file. Save this alongside the original file, as it is the MCP equivalent of the browser's forced certificate download. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and describes the asynchronous on-chain settlement, the need to poll until 'submitted', and the durable-record purpose. It stops short of documenting failure states, statuses other than 'submitted', or error behavior, and the text appears truncated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The visible text is efficient: a dense first sentence defines the return payload and a second sentence gives the workflow. The mid-word truncation at the end prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter polling tool, the description covers the workflow, the target status, and what to do with the response, and an output schema exists for return details. It is slightly incomplete because it does not address failure/retry handling and ends mid-sentence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate for the required id parameter, but it never mentions the parameter or how to populate it. The schema's own id description is helpful, but the tool description adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: returns the complete receipt kit for a single evidence item, listing hash, file metadata, status, and on-chain transaction details. It is clearly distinguished from list_evidence by the 'single evidence item' framing, though it does not explicitly name the sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit workflow: poll after create_timestamp until status is 'submitted', then save the response as the proof-of-timestamp record. This is strong when-to-use guidance, but it does not state when not to use the tool or name alternatives such as list_evidence for multi-item retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public pricing reference. Does not require a user credential, only the channel Consumer-Token. Returns the current cost (in spArks) of a timestamp operation and the credits-to-USD exchange rate. Both timestamp_register (standard) and timestamp_register_agentic (MCP agent calls) are always returned, regardless of the caller's own auth, so this is a...
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No | |
| meta | No |
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 the auth model (Consumer-Token only, no user credential) and the important quirk that both timestamp_register and timestamp_register_agentic are always returned regardless of caller auth. It falls short of 5 only because the sentence is truncated mid-thought and return shape details remain incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is front-loaded and largely efficient, but the final clause terminates abruptly at 'so this is a...', leaving an unfinished sentence. That truncation is a real structural defect rather than a stylistic nit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be restated, yet the description helpfully summarizes them anyway. Auth context and the always-both-registers behavior are covered; the unfinished trailing sentence is the only meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so schema semantics are not a concern and the baseline is 4. The description appropriately adds no parameter detail because there is nothing to parameterize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (public pricing reference) and spells out exactly what it returns: the spArks cost of a timestamp operation and the credits-to-USD exchange rate. It does not explicitly distinguish itself from sibling tools like get_balance or create_timestamp, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives useful context that no user credential is required, only the channel Consumer-Token, which implies this is a safe public read. However, it never states when to reach for this tool versus siblings such as get_balance, and offers no explicit exclusions or prerequisites beyond auth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every evidence item owned by the calling account, newest first, as a summary (no full receipt data, call get_evidence for the complete receipt kit on a specific item). Use this to find an evidence_id when the caller only knows a file name, or to check on recent timestamping activity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses important behavior: account scoping, sorting, summary-level output, and exclusion of full receipt data. It could additionally mention pagination or limits, but for a zero-parameter listing tool the behavioral disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences accomplish everything: primary behavior, format caveat, sibling alternative, and concrete use cases. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool with an output schema present, the description fully covers scope, ordering, output format, and when to choose an alternative. Nothing essential is missing for an agent to decide whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100%, so the schema carries no hidden burden. The description adds useful context about what the returned evidence_id enables, which is appropriate given there are no params to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and resource ('every evidence item owned by the calling account'), with clear ordering ('newest first') and format ('summary'). It also explicitly contrasts itself with get_evidence, making sibling differentiation immediate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: to find an evidence_id when the caller only knows a file name, or to check recent timestamping activity. It also directs users to get_evidence for full receipt data, providing a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unauthenticated. No Consumer-Token or user credential required. Any agent can verify any spArxx.io timestamp proof this way, which makes it a discovery surface as well as a verification tool: given a tx hash from a certificate or receipt kit, this confirms the proof is real and returns the public receipt data (identity claim redaction now follows t...
| Name | Required | Description | Default |
|---|---|---|---|
| pathParams | Yes | ||
| queryParams | Yes |
| Name | Required | Description |
|---|---|---|
| data | No | Public receipt data, identity_claim redacted per privacy rules above. |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it delivers: unauthenticated access, no Consumer-Token required, what is returned (public receipt data), and redaction behavior. The value is real, though the truncation mid-sentence about redaction and the absence of rate-limit or error behavior keep it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The auth constraint is front-loaded effectively, but the description drifts into marketing framing ('discovery surface as well as a verification tool') and is visibly truncated, ending mid-sentence without completing its point about redaction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, and auth prerequisites are well covered. Still, for a two-required-param tool with nested objects, the cut-off sentence leaves the redaction semantics — the most consequential behavioral detail — unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is reported at 0%, so the description must compensate. It explains the txHash origin (certificate or receipt kit) but says nothing about the cf-turnstile-response token, whose gating conditions are only described in the schema itself. Partial compensation justifies a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (verify) and resource (spArxx.io timestamp proof), and clarifies it both confirms the proof is real and returns public receipt data. It is clearly distinguishable from write-oriented siblings like create_timestamp, though it doesn't explicitly name which sibling to prefer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the triggering input (a tx hash from a certificate or receipt kit) and stresses that any agent can call it, which implies usage context. However, it never contrasts this with siblings such as get_evidence or list_evidence, so the when-not-to-use boundary is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_evidence7 fields changedOutput schema / properties / data / properties / blockchain / anyOfAdded value: +[
+ {
+ "properties": {
+ "block_height": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Decimal block number the transaction was mined in."
+ },
+ "contract_address": {
+ "description": "The TimestampRegistry contract address that storeHash(bytes32) was called on.",
+ "type": "string"
+ },
+ "explorer_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "network": {
+ "type": "string"
+ },
+ "tx_hash": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / properties / blockchain / descriptionPrevious value: -"Present only once status is 'submitted' and a transaction hash exists."New value: +"Present only once status is 'submitted' and a transaction hash exists; null otherwise."Output schema / properties / data / properties / blockchain / propertiesRemoved value: -{
- "block_height": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Decimal block number the transaction was mined in."
- },
- "contract_address": {
- "description": "The TimestampRegistry contract address that storeHash(bytes32) was called on.",
- "type": "string"
- },
- "explorer_url": {
- "format": "uri",
- "type": "string"
- },
- "network": {
- "type": "string"
- },
- "tx_hash": {
- "type": "string"
- }
-}Output schema / properties / data / properties / blockchain / typeRemoved value: -"object"Output schema / properties / data / properties / receipt_data / anyOfAdded value: +[
+ {
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / properties / receipt_data / descriptionPrevious value: -"Structured receipt payload (shape varies: includes identity_claim block also surfaced publicly via verify_certificate)."New value: +"Structured receipt payload (shape varies: includes identity_claim block also surfaced publicly via verify_certificate). Null until status is 'submitted'."Output schema / properties / data / properties / receipt_data / typeRemoved value: -"object"create_timestamp8 fields changedInput schema / properties / body / properties / codename / anyOfAdded value: +[
+ {
+ "maxLength": 100,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / body / properties / codename / descriptionRemoved value: -"Optional human-friendly label for the timestamped item."Input schema / properties / body / properties / disclose_identity / anyOfAdded value: +[
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / body / properties / disclose_identity / descriptionRemoved 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."Input schema / properties / body / properties / mime_type / anyOfAdded value: +[
+ {
+ "maxLength": 100,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / body / properties / mime_type / descriptionRemoved 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."Input schema / properties / body / properties / original_file_name / anyOfAdded value: +[
+ {
+ "maxLength": 255,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / body / properties / original_file_name / descriptionRemoved value: -"Optional: the file's original name, if different from file_name (e.g., before local renaming). Purely informational, stored with the evidence record."get_evidence14 fields changedOutput schema / properties / data / properties / blockchain / properties / block_height / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / properties / blockchain / properties / block_height / typeRemoved value: -[
- "integer",
- "null"
-]Output schema / properties / data / properties / file / properties / original_name / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / properties / file / properties / original_name / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / data / properties / file / properties / size / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / properties / file / properties / size / typeRemoved value: -[
- "integer",
- "null"
-]Output schema / properties / data / properties / origin_channel / anyOfAdded value: +[
+ {
+ "enum": [
+ "mcp_agent"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / properties / origin_channel / enumRemoved value: -[
- "mcp_agent",
- null
-]Output schema / properties / data / properties / origin_channel / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / data / properties / public_verify_url / anyOfAdded value: +[
+ {
+ "format": "uri",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / properties / public_verify_url / formatRemoved value: -"uri"Output schema / properties / data / properties / public_verify_url / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / data / properties / verification_instructions / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / properties / verification_instructions / typeRemoved value: -[
- "string",
- "null"
-]list_evidence14 fields changedOutput schema / properties / data / items / properties / blockchain_tx_hash / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / items / properties / blockchain_tx_hash / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / data / items / properties / explorer_url / anyOfAdded value: +[
+ {
+ "format": "uri",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / items / properties / explorer_url / formatRemoved value: -"uri"Output schema / properties / data / items / properties / explorer_url / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / data / items / properties / file_size / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / items / properties / file_size / typeRemoved value: -[
- "integer",
- "null"
-]Output schema / properties / data / items / properties / mime_type / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / items / properties / mime_type / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / data / items / properties / origin_channel / anyOfAdded value: +[
+ {
+ "enum": [
+ "mcp_agent"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / items / properties / origin_channel / enumRemoved value: -[
- "mcp_agent",
- null
-]Output schema / properties / data / items / properties / origin_channel / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / data / items / properties / original_file_name / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / items / properties / original_file_name / typeRemoved value: -[
- "string",
- "null"
-]create_timestamp6 fields changedInput schema / properties / body / descriptionPrevious 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."Input schema / properties / body / properties / disclose_identity / descriptionPrevious 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."Input schema / properties / body / properties / file_name / descriptionAdded 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."Input schema / properties / body / properties / mime_type / descriptionAdded 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."Input schema / properties / body / properties / original_file_name / descriptionAdded value: +"Optional: the file's original name, if different from file_name (e.g., before local renaming). Purely informational, stored with the evidence record."Output 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"
+}get_balance1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "properties": {
+ "credits": {
+ "description": "spArks balance.",
+ "type": "number"
+ },
+ "formatted": {
+ "example": "1,250.00",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+}get_evidence1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "The receipt kit: everything an agent needs to prove a hash was timestamped, without ever holding the original file. Save this alongside the original file, as it is the MCP equivalent of the browser's forced certificate download.",
+ "properties": {
+ "blockchain": {
+ "description": "Present only once status is 'submitted' and a transaction hash exists.",
+ "properties": {
+ "block_height": {
+ "description": "Decimal block number the transaction was mined in.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "contract_address": {
+ "description": "The TimestampRegistry contract address that storeHash(bytes32) was called on.",
+ "type": "string"
+ },
+ "explorer_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "network": {
+ "type": "string"
+ },
+ "tx_hash": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "created_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "custody_status": {
+ "description": "Custody tier (BLUEPRINT.md). MVP is self-custody only. The client is responsible for keeping this receipt with the original file.",
+ "enum": [
+ "self_custody"
+ ],
+ "type": "string"
+ },
+ "disclose_identity": {
+ "description": "Whether this specific timestamp's certificate/manifest/verify page discloses the account's name and email together, or withholds both. Frozen at creation time. Does not change retroactively if the account's default preference changes later.",
+ "type": "boolean"
+ },
+ "file": {
+ "properties": {
+ "hash": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "original_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "size": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "id": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "origin_channel": {
+ "description": "Set to 'mcp_agent' when this item was created via an MCP agent key.",
+ "enum": [
+ "mcp_agent",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "public_verify_url": {
+ "description": "Human-viewable, Cloudflare Turnstile-protected confirmation page. Hand this to the human to open in their own browser. Do not fetch it programmatically, as it is not meant for agent traffic and will likely be blocked.",
+ "format": "uri",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "receipt_data": {
+ "description": "Structured receipt payload (shape varies: includes identity_claim block also surfaced publicly via verify_certificate).",
+ "type": "object"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "submitted",
+ "failed"
+ ],
+ "type": "string"
+ },
+ "verification_instructions": {
+ "description": "Step-by-step instructions for an agent to independently confirm the timestamp using only public blockchain data (recompute the hash locally, fetch the transaction, decode its calldata). Requires no trust in spArxx.io beyond the public chain itself. Present only once blockchain data is available.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+}get_pricing1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "properties": {
+ "currency": {
+ "example": "credits",
+ "type": "string"
+ },
+ "exchange_rate": {
+ "properties": {
+ "credits_per_usd": {
+ "type": "number"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "service_costs": {
+ "properties": {
+ "timestamp_register": {
+ "description": "Standard spArks cost of a create_timestamp call (TIMESTAMP_COST env var, default 25).",
+ "type": "integer"
+ },
+ "timestamp_register_agentic": {
+ "description": "spArks cost of a create_timestamp call made via an MCP agent key (AGENTIC_TIMESTAMP_COST env var, default 20). This is a flat service rate for this channel, not a discount on spArks themselves.",
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "meta": {
+ "properties": {
+ "api_version": {
+ "type": "string"
+ },
+ "environment": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+}list_evidence1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "items": {
+ "properties": {
+ "blockchain_tx_hash": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "explorer_url": {
+ "description": "Public block-explorer link for blockchain_tx_hash. Null until the timestamp job has settled on-chain.",
+ "format": "uri",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "file_hash": {
+ "description": "SHA-256 hex digest, 64 characters.",
+ "type": "string"
+ },
+ "file_name": {
+ "type": "string"
+ },
+ "file_size": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "id": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "mime_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "origin_channel": {
+ "description": "Set to 'mcp_agent' when this item was created via an MCP agent key; null otherwise (web/mobile channel tracking is not yet implemented. See EVIDENCE_CUSTODY_TRACKING_BLUEPRINT.md).",
+ "enum": [
+ "mcp_agent",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "original_file_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "submitted",
+ "failed"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}verify_certificate2 fields changedInput schema / properties / queryParams / properties / cf-turnstile-response / descriptionPrevious value: -"Cloudflare Turnstile CAPTCHA token. Required for anonymous callers in any environment with a Turnstile secret key configured — in practice, always in production. Skipped only in an unconfigured local dev environment, or when the request is already authenticated via the MCP agent guard (Claude Code / Custom Connector)."New value: +"Cloudflare Turnstile CAPTCHA token. Required for anonymous callers in any environment with a Turnstile secret key configured. In practice, always in production. Skipped only in an unconfigured local dev environment, or when the request is already authenticated via the MCP agent guard (Claude Code / Custom Connector)."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "Public receipt data, identity_claim redacted per privacy rules above.",
+ "type": "object"
+ },
+ "status": {
+ "example": "success",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}create_timestampget_balanceget_evidenceget_pricinglist_evidenceverify_certificate
Add one secure layer between your agents and this server.