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 operation: create, balance check, pricing, single receipt retrieval, list summaries, and public verification. Overlap between get_evidence and verify_certificate is explicitly clarified by auth scope and use case, leaving no practical ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (create_timestamp, get_balance, get_evidence, get_pricing, list_evidence, verify_certificate). No deviations or mixed conventions.
Six tools neatly cover the core workflow: creation, cost/balance pre-checks, retrieval of individual and list evidence, and public verification. The count is well-scoped with no redundant tools.
The surface covers the full timestamping lifecycle: create, list, get receipt, verify proof, plus pricing and balance checks. No update or delete is needed because timestamps are immutable, and the inclusion of public verification fills the discovery gap.
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, 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.
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.
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.
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.
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.
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.
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 full burden and does disclose the key behavioral trait: the result is asynchronous and the blockchain transaction hash/explorer URL only appear 'once the on-chain job has settled,' so the caller must poll until status is 'submitted'. It does not cover auth requirements, error/not-found behavior, or rate limits on polling, which keeps it short of 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?
Front-loaded with what the tool returns, then the polling workflow, then what to do with the output — a logical ordering with no filler. The text is truncated mid-sentence, so it is efficient but evidently incomplete.
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 the description could have deferred return-value details, yet it helpfully summarizes the payload and, more importantly, explains the async polling lifecycle needed to interpret status. The only shortfall is that the visible text ends mid-sentence, leaving an unknown remainder of the intended guidance.
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?
Only one parameter (pathParams.id) and the schema already describes it as the 'evidence_id returned by create_timestamp or list_evidence.' The description reinforces that this is a single-item lookup but adds no new syntax, format, or lookup detail beyond the schema. Baseline 3 for a single well-documented path parameter.
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 and resource — 'Returns the complete receipt kit for a single evidence item' — and enumerates what the kit contains (hash, file metadata, status, tx hash, explorer URL). It clearly distinguishes itself from list_evidence and create_timestamp by scoping to a single item and naming them as the source of the id, though the truncated sentence ('This is th...') leaves the sibling differentiation against verify_certificate unfinished.
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 explicit sequencing guidance: 'Poll this after create_timestamp until status is submitted' and says what to do with the result ('save the full response alongside the original file'). That is concrete when-to-use direction, though the cut-off final sentence may have carried a when-not/alternative clause that is not visible.
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, the description carries the full burden and does well: it discloses ownership scoping, sort order, and the deliberate truncation of payload (summary only, no full receipt data). It omits auth requirements or pagination/limit behavior, which is a minor gap for a list endpoint.
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?
A single front-loaded sentence delivers the return contract, ordering, and the sibling routing without waste; the parenthetical earns its place by preventing misuse for full receipt retrieval.
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 enumerated, and the description still explains the summary-vs-full distinction. For a no-parameter list tool, nothing needed for correct invocation is missing.
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 the baseline is 4. The description implicitly confirms there is no filtering input, and there is no parameter syntax that needs explaining.
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 and resource ('Returns every evidence item owned by the calling account') plus scope and ordering ('newest first'). It explicitly distinguishes itself from the sibling get_evidence by characterizing its own output as a summary rather than the complete receipt kit.
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 two concrete when-to-use conditions ('find an evidence_id when the caller only knows a file name', 'check on recent timestamping activity') and names the alternative tool to use for full receipt data. Nothing 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.
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.
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
