Skip to main content
Glama
Sign In

Pulse Verity

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Pulse Verify Print

pulse_verify_print
Read-onlyIdempotent

Check whether a Pulse signed price print is authentic and unaltered — pass a print back exactly as a Pulse tool returned it and this recomputes the ECDSA P-256 / SHA-256 signature over the canonical string, entirely OFFLINE with no network call to Pulse. WHAT A valid:true RESULT PROVES: that Pulse asserted this exact price, for this symbol, at this timestamp, at this grade, and that nobody altered any of those fields in transit — it detects a single changed digit of price or a one-millisecond shift in the timestamp. WHAT IT DOES NOT PROVE: that the price is CORRECT or reflects the true market — this checks Pulse's signature, not the world, so a print can verify perfectly and still be a price Pulse itself got wrong. The verification is computed here, not asked of Pulse, so Pulse cannot vouch for a print it never signed and an offline or compromised source cannot turn an invalid print into a valid one. Needs NO API key. Example: pulse_verify_print({ symbol: "BTC", priceText: "76051.0676303142", price: 76051.0676303142, at: "2026-09-16T23:39:30.524Z", grade: "consensus", signature: "wiD005d9...", kid: "pvi-Sl40p5Gj2t_-JyKUhxyg" }).

Input Schema

NameRequiredDescriptionDefault
atYesFrom the print, unchanged. A 1ms difference invalidates the signature.
kidNoKey id from the print; selects which public key to check against.
sigNoScheme tag from the print (pulse-index-v1).
gradeYesFrom the print: consensus, blended or indicative.
priceNoFrom the print. Used only if priceText is absent.
symbolYesFrom the print, unchanged.
priceTextNoThe price EXACTLY as Pulse served it. This is what was signed — prefer it always.
signatureYesBase64 signature from the print.

Output Schema

NameRequiredDescriptionDefault
atYesEchoed from the input print, 4th field of the canonical string
gradeYesEchoed from the input print, 5th field of the canonical string
validYesTrue only if the signature matches the canonical string exactly
sourceYesConstant: Pulse Verity Index (thepulse.markets)
symbolYesEchoed from the input print, 2nd field of the canonical string
kid_usedYesKey id actually used to verify, resolved from input or the ring
grade_noteNoPlain-language explanation of what the returned grade means for settlement.
key_sourceYesWhether the verification key came from cache or a fresh ring fetch
settleableYesTrue only for consensus/blended grades
invalid_noteNoPresent only when valid is false — explains that the signature does not match the print and it must not be settled against.
verificationYesStates the algorithm and that Pulse is never asked to vouch for a print
signature_bytesYesLength of the decoded signature, for sanity-checking the input
canonical_stringYesThe exact bytes checked: pulse-index-v1\n{symbol}\n{priceText}\n{at}\n{grade}
fallback_warningNoPresent only when priceText was omitted and price was used instead — flags that JS float formatting could diverge from the signed wire text.
price_field_usedYesWhether priceText (signed) or a String(price) fallback was used

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "at": "2026-09-22T22:04:06.151Z",
+    "grade": "consensus",
+    "kid": "pvi-Sl40p5Gj2t_-JyKUhxyg",
+    "price": 86163.21518729837,
+    "priceText": "86163.21518729837",
+    "signature": "vI57zfSrNW13+kBdRlhLpxsv0pKHVStIRWvXNofS6lgMDl3QaJuxB987ap8nOph3mD/QXNQw1H1YXXDfCXqcxA==",
+    "symbol": "BTC"
+  }
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "at": {
+      "description": "Echoed from the input print, 4th field of the canonical string",
+      "type": "string"
+    },
+    "canonical_string": {
+      "description": "The exact bytes checked: pulse-index-v1\\n{symbol}\\n{priceText}\\n{at}\\n{grade}",
+      "type": "string"
+    },
+    "fallback_warning": {
+      "description": "Present only when priceText was omitted and price was used instead — flags that JS float formatting could diverge from the signed wire text.",
+      "type": "string"
+    },
+    "grade": {
+      "description": "Echoed from the input print, 5th field of the canonical string",
+      "type": "string"
+    },
+    "grade_note": {
+      "description": "Plain-language explanation of what the returned grade means for settlement.",
+      "type": "string"
+    },
+    "invalid_note": {
+      "description": "Present only when valid is false — explains that the signature does not match the print and it must not be settled against.",
+      "type": "string"
+    },
+    "key_source": {
+      "description": "Whether the verification key came from cache or a fresh ring fetch",
+      "type": "string"
+    },
+    "kid_used": {
+      "description": "Key id actually used to verify, resolved from input or the ring",
+      "type": "string"
+    },
+    "price_field_used": {
+      "description": "Whether priceText (signed) or a String(price) fallback was used",
+      "type": "string"
+    },
+    "settleable": {
+      "description": "True only for consensus/blended grades",
+      "type": "boolean"
+    },
+    "signature_bytes": {
+      "description": "Length of the decoded signature, for sanity-checking the input",
+      "type": "number"
+    },
+    "source": {
+      "description": "Constant: Pulse Verity Index (thepulse.markets)",
+      "type": "string"
+    },
+    "symbol": {
+      "description": "Echoed from the input print, 2nd field of the canonical string",
+      "type": "string"
+    },
+    "valid": {
+      "description": "True only if the signature matches the canonical string exactly",
+      "type": "boolean"
+    },
+    "verification": {
+      "description": "States the algorithm and that Pulse is never asked to vouch for a print",
+      "type": "string"
+    }
+  },
+  "required": [
+    "valid",
+    "symbol",
+    "at",
+    "grade",
+    "settleable",
+    "kid_used",
+    "key_source",
+    "signature_bytes",
+    "canonical_string",
+    "price_field_used",
+    "verification",
+    "source"
+  ],
+  "type": "object"
+}
  2. Changed2 schema fields changed
    • removedInput schema / examples
      Removed value: -[
-  {
-    "at": "2026-09-22T22:04:06.151Z",
-    "grade": "consensus",
-    "kid": "pvi-Sl40p5Gj2t_-JyKUhxyg",
-    "price": 86163.21518729837,
-    "priceText": "86163.21518729837",
-    "signature": "vI57zfSrNW13+kBdRlhLpxsv0pKHVStIRWvXNofS6lgMDl3QaJuxB987ap8nOph3mD/QXNQw1H1YXXDfCXqcxA==",
-    "symbol": "BTC"
-  }
-]
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "at": {
-      "description": "Echoed from the input print, 4th field of the canonical string",
-      "type": "string"
-    },
-    "canonical_string": {
-      "description": "The exact bytes checked: pulse-index-v1\\n{symbol}\\n{priceText}\\n{at}\\n{grade}",
-      "type": "string"
-    },
-    "fallback_warning": {
-      "description": "Present only when priceText was omitted and price was used instead — flags that JS float formatting could diverge from the signed wire text.",
-      "type": "string"
-    },
-    "grade": {
-      "description": "Echoed from the input print, 5th field of the canonical string",
-      "type": "string"
-    },
-    "grade_note": {
-      "description": "Plain-language explanation of what the returned grade means for settlement.",
-      "type": "string"
-    },
-    "invalid_note": {
-      "description": "Present only when valid is false — explains that the signature does not match the print and it must not be settled against.",
-      "type": "string"
-    },
-    "key_source": {
-      "description": "Whether the verification key came from cache or a fresh ring fetch",
-      "type": "string"
-    },
-    "kid_used": {
-      "description": "Key id actually used to verify, resolved from input or the ring",
-      "type": "string"
-    },
-    "price_field_used": {
-      "description": "Whether priceText (signed) or a String(price) fallback was used",
-      "type": "string"
-    },
-    "settleable": {
-      "description": "True only for consensus/blended grades",
-      "type": "boolean"
-    },
-    "signature_bytes": {
-      "description": "Length of the decoded signature, for sanity-checking the input",
-      "type": "number"
-    },
-    "source": {
-      "description": "Constant: Pulse Verity Index (thepulse.markets)",
-      "type": "string"
-    },
-    "symbol": {
-      "description": "Echoed from the input print, 2nd field of the canonical string",
-      "type": "string"
-    },
-    "valid": {
-      "description": "True only if the signature matches the canonical string exactly",
-      "type": "boolean"
-    },
-    "verification": {
-      "description": "States the algorithm and that Pulse is never asked to vouch for a print",
-      "type": "string"
-    }
-  },
-  "required": [
-    "valid",
-    "symbol",
-    "at",
-    "grade",
-    "settleable",
-    "kid_used",
-    "key_source",
-    "signature_bytes",
-    "canonical_string",
-    "price_field_used",
-    "verification",
-    "source"
-  ],
-  "type": "object"
-}New value: +null
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the readOnlyHint/idempotentHint annotations: it is fully offline, makes no network call, requires no API key, detects even a single changed digit or 1ms timestamp shift, and cannot validate prints Pulse never signed. It also clearly discloses limitations, such as the price still being potentially wrong even when the signature verifies.

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?

The description is longer than average but well-structured and front-loaded with the core operation. It uses clearly marked sections for what the result proves and does not prove, which earns its length. There is minor redundancy around being offline / not asking Pulse, but it is not excessive.

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

Completeness5/5

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

Given the presence of an output schema, annotations, and 100% schema coverage, the description is complete for correct invocation. It covers authentication requirements (none), network behavior (offline), verification semantics, failure sensitivity, limitations, and gives a concrete example. Nothing essential for an agent to call this tool correctly is missing.

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%, so the baseline is 3. The description adds a realistic example and the blanket instruction to pass the print back exactly as returned, but it does not provide much per-parameter meaning beyond what the schema already documents. This is acceptable because the schema is already rich.

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?

The description names a specific action ('Check whether a Pulse signed price print is authentic and unaltered'), identifies the exact resource (Pulse signed price print), and explains the mechanism (recomputes ECDSA P-256 / SHA-256 signature over the canonical string). This clearly differentiates it from siblings like pulse_signed_price or pulse_signed_batch, which fetch or create prints rather than verify them.

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?

It gives clear context: pass back a print exactly as a Pulse tool returned it, verification is offline, no API key is needed, and it meaningfully explains what the tool does NOT prove (price correctness). It does not explicitly name alternatives or state 'use X instead for fetching signed prices', but the usage boundary is otherwise very clear.

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

All Pulse Verity toolsInspect
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