Provides read-only access to signed, verifiable crypto index prices via MCP.
Get the current signed index price for a symbol (BTC, ETH, SOL available keyless)
Batch read 1–100 symbols with individually signed successful rows and per-symbol errors
List index assets with coverage status and cadence (catalog rows are unsigned)
Get the recorded signed print nearest a requested time; check deltaMs before relying on it
Verify signed prints locally using ECDSA P-256/SHA-256 and the published public key ring
No write tools; it only calls the public Pulse Verity Index API
A free API key enables catalog, batch, and settlement-print access; signature verification works without one
Provides signed, verifiable crypto index prices including Bitcoin (BTC) via the Pulse Verity Index, with tools to fetch current signed prices, batch reads, settlement prints, and local ECDSA signature verification.
Supports Windsurf (Codeium's IDE) via mcp_config.json, enabling signed Pulse Verity Index crypto price tools within the editor.
Hosts the source repository and release artifacts (including the Claude Desktop .mcpb bundle) for the pulse-verity MCP server, enabling installation and updates.
Distributes the pulse-verity package and its runtime dependencies, allowing installation and execution via npx for local stdio MCP clients.
pulse-verity connects an AI agent to the Pulse Verity Index: signed,
verifiable crypto index prices through the Model Context Protocol (MCP).
It exposes five read-only tools:
Tool | Purpose |
| Return the current signed index value. |
| Read 1–100 symbols with signed successful rows and per-symbol errors. |
| Discover one catalog page with coverage and measured cadence. |
| Return the recorded signed print nearest a moment. |
| Verify a print locally with ECDSA and the published public key. |
There are no write tools. This package contains no Pulse platform engine code. It only calls the public Pulse Verity Index API.
The server starts and answers with no configuration at all. Keyless, it serves
get_index_price for BTC, ETH and SOL from the free sample:
claude mcp add pulse-verity -- npx -y pulse-verityThen ask your agent for the Bitcoin index price. Successful price receipts are signed and verifiable, exactly like a keyed one.
Related MCP server: openpulsechain
A free key enables catalogue access, batch reads and settlement prints, subject to usage limits. Create a developer account at thepulse.markets/developers, verify your email, then create a key. Keep it in your MCP client's private configuration; do not share it in chat. Signature verification also works without a key.
claude mcp add pulse-verity \
--env PULSE_API_KEY=pidx_your_key_here \
-- npx -y pulse-verityFor any stdio MCP client:
{
"mcpServers": {
"pulse-verity": {
"command": "npx",
"args": ["-y", "pulse-verity"],
"env": { "PULSE_API_KEY": "pidx_your_key_here" }
}
}
}The same five tools run on Pulse's side at https://mcp.thepulse.markets/api/index/mcp.
Claude (web, desktop, mobile): Settings → Connectors → Add custom connector → paste the URL → Connect, then sign in with your developer email and password.
ChatGPT: Settings → Connectors → Create → paste the URL. Same sign-in.
Claude Code: claude mcp add --transport http pulse-verity https://mcp.thepulse.markets/api/index/mcp --header "Authorization: Bearer pidx_your_key"
Any client with remote MCP support: { "url": "https://mcp.thepulse.markets/api/index/mcp", "headers": { "Authorization": "Bearer pidx_your_key" } }
Sign-in is standard OAuth 2.1 (dynamic registration, PKCE). Every hosted call meters against
your key exactly like a REST call. Discovery documents live at /.well-known/oauth-authorization-server
and /.well-known/oauth-protected-resource/api/index/mcp.
For the guided price-check skill, pinned pulse-verity@1.2.6 MCP runtime,
local setup and three example prompts, see the Claude plugin guide.
Keyless samples are available; wider access requires the user's own key and
applicable allowance. Cowork runtime constraints are documented in the guide.
This package is separate from the Desktop MCPB; directory approval is not implied.
This repository includes .cursor-plugin/plugin.json and mcp.json for
Cursor's plugin loader. The plugin starts the released pulse-verity@1.2.6
package with npx; Node.js 18 or newer is required. No platform engine code
or private repository access is included.
The PULSE_API_KEY variable is optional and defaults to an empty string, so
BTC, ETH and SOL samples work without a key. Configure a free key through
Cursor's plugin configuration to enable catalogue, batch and settlement-print
requests. Never put a real key in these repository files.
Marketplace availability is subject to Cursor's review. The configuration below remains available for manual MCP installation.
For a keyless sample task and the distinct Grok Bot / xAI API connection routes, see Use Pulse Verity with Grok.
Install directly from the public repository:
grok plugin install PulseBet/pulse-verity --trustStart a new Grok Build session, then ask for the current Bitcoin index price.
The plugin starts npx -y pulse-verity@1.2.6; Node.js 18 or newer and npm are
required. BTC, ETH and SOL samples work without an API key. To enable
catalogue, batch and settlement-print requests, set PULSE_API_KEY in the
environment that launches Grok Build, then start a new session. Get a free key
at the developer portal; never save it
in these repository files.
The .grok-plugin/plugin.json manifest explicitly selects
.grok-plugin/mcp.json. It exposes the five read-only tools listed above and
adds no hooks, skills, agents, slash commands or filesystem-access tools.
Grok's official marketplace listing is subject to review; this direct GitHub
installation does not depend on listing approval.
The plugin source is fetched from github.com. At startup, npx may fetch
the pinned package and its dependencies from the configured npm registry
(registry.npmjs.org by default). During tool use, the server makes GET
requests only to https://mcp.thepulse.markets for price, batch, recorded-print,
catalogue, sample and public-key endpoints under /api/index/v1/. A configured
PULSE_API_KEY is sent only to that origin for keyed requests; samples and
public-key reads need no credentials. The server does not read project files
or send separate telemetry.
Install the public extension without an API-key prompt:
gemini extensions install https://github.com/PulseBet/pulse-verity --skip-settingsRestart Gemini CLI, then ask for the current Bitcoin index price. The extension
starts the released pulse-verity@1.2.6 package through npx; Node.js and npm
must be available. BTC, ETH and SOL samples work without a key. Gemini may warn
that the optional setting is unset; that does not prevent keyless startup.
To enable catalogue, batch and settlement-print requests, configure a free key using Gemini's sensitive-setting prompt, then restart the CLI:
gemini extensions config pulse-verity PULSE_API_KEYDo not add a real key to this repository or assume an exported shell variable
will pass through Gemini's environment filtering. The extension declares only
PULSE_API_KEY, stored through Gemini's sensitive settings.
The root gemini-extension.json is the gallery manifest. The release includes
separate darwin, linux and win32 archives for Gemini's download selection;
the Claude Desktop .mcpb remains separate. Gallery indexing is handled by
Google and is not immediate or guaranteed. This is a Gemini CLI extension,
not a listing in the consumer Gemini chat app.
All of these run npx -y pulse-verity with PULSE_API_KEY in the environment.
Codex CLI — ~/.codex/config.toml:
[mcp_servers.pulse-verity]
command = "npx"
args = ["-y", "pulse-verity"]
env = { PULSE_API_KEY = "pidx_your_key" }Windsurf — ~/.codeium/windsurf/mcp_config.json, and Cursor — ~/.cursor/mcp.json:
{ "mcpServers": { "pulse-verity": { "command": "npx", "args": ["-y", "pulse-verity"], "env": { "PULSE_API_KEY": "pidx_your_key" } } } }VS Code (Copilot agent mode) — .vscode/mcp.json:
{ "servers": { "pulse-verity": { "type": "stdio", "command": "npx", "args": ["-y", "pulse-verity"], "env": { "PULSE_API_KEY": "pidx_your_key" } } } }Gemini CLI — ~/.gemini/settings.json, same mcpServers block as Cursor.
Download pulse-verity-1.2.6.mcpb,
open it with Claude Desktop (macOS or Windows), and leave the optional key blank
to try BTC, ETH and SOL. Add a free key for catalogue, batch and settlement-print
requests. The bundle contains the same compiled server modules npm ships, with its runtime
dependencies. Existing downloaded bundles must be replaced with the new release.
npm: pulse-verity
Official MCP Registry: io.github.PulseBet/pulse-verity
Cursor: .cursor-plugin/plugin.json packages the MCP for marketplace review; manual MCP configuration is shown above
Grok Build: .grok-plugin/plugin.json packages the MCP for direct GitHub installation and marketplace review
Gemini CLI: gemini-extension.json packages the public MCP for the extension gallery and GitHub installation
Claude Desktop: add the JSON block above to claude_desktop_config.json
Smithery: smithery.yaml in this repo declares the stdio command and the one key it needs
Local installations run the same npm package and send a configured developer key only to the pinned Pulse Verity API. The separate hosted MCP endpoint is documented above.
Read-only MCP tools only.
API origin pinned to the public Pulse Verity Index API.
Developer key read from local configuration and sent only to that API.
Print verification happens locally using ECDSA P-256/SHA-256.
HTTP requests use a 15-second timeout, a 1 MiB response limit and no redirects.
Verification accepts at most 16 published keys; refreshes coalesce and are limited to once per 30 seconds.
API failures retain only allowlisted quota codes and bounded retry delays, never raw remote bodies, headers or transport errors. Returned credentials are redacted.
No wallet, account, platform-engine, venue-level, or private repository code.
See SECURITY.md for reporting instructions.
Price and batch tools use the existing signed /api/index/v1/price and
/api/index/v1/batch endpoints. A successful row can include priceText, kid,
tier, confidence, dispersionBps, interval, sources, engine and
cadence. Preserve priceText and kid when passing it to verify_print.
The immutable pulse-index-v1 signature authenticates only this payload:
pulse-index-v1
<symbol>
<priceText if present, otherwise String(price)>
<at>
<grade>verify_print rejects conflicting price and priceText values. It selects
the published public key matching kid; legacy prints without kid are tried
against the bounded published key ring. The ring is cached for five minutes,
with a bounded refresh after a failed check. Legacy public-key responses
containing only publicKeyPem still work for prints without kid. Verification
is local, but the public keys are initially trusted through Pulse's pinned
HTTPS endpoint. A key that is no longer published cannot verify an old print
through this tool.
valid: true authenticates the canonical price fields. It does not authenticate
kid, quality, confidence, dispersion, interval, source counts, cadence, batch
status or archive deltaMs. Check deltaMs before using a sampled historical
print for a particular moment.
The asset tool calls /api/index/v1/verity/catalog. It defaults to 50 rows,
accepts limit from 1 to 100 and offset from 0 to 100000, and never fetches
additional pages automatically. Its rows and any displayed prices are unsigned.
Use the price or batch tool to obtain signed receipts. Catalog coverage changes;
a listed asset or a catalog total does not guarantee a fresh price. Unavailable
prices are not zero. API tier limits can be lower than the tool's batch limit.
HTTP 429 tool errors include structuredContent.error. RATE_LIMITED means
wait, with retryAfterSeconds when supplied. MONTHLY_LIMIT means the monthly
allowance is exhausted. The response links to
account access and request-limit information
and returns nextAction: "review_access". The allowance resets at the start of
the next UTC month. Creating or replacing a key does not reset the account's
allowance. Unknown limits use REQUEST_LIMIT without assuming a monthly
allowance. No tool automatically retries.
npm ci
npm testnpm run check:cursor checks the Cursor manifest, optional-key configuration,
package-version pin and logo without building or making network requests.
npm run check:grok checks the Grok manifest, explicit MCP path, optional-key
configuration and package-version pin without building or network requests.
npm run check:gemini checks the Gemini manifest, optional sensitive setting,
version pin and release configuration without building or network requests.
The Gemini extension workflow runs the complete suite, installs with Gemini CLI,
and checks the installed manifest's five read-only MCP tools against a local
candidate tarball before npm publication. The package release publishes the
desktop bundle and all three Gemini archives together. A manual Gemini-only
step can add missing archives to an existing release without replacing assets.
The post-release check installs the default public GitHub release, reads one
public BTC sample and verifies its signature.
The offline suite compiles this small MCP package, exercises exact-price and rotated-key verification, tests MCP tool bounds and mocked HTTP limits, and runs the Pulse WORDS vocabulary gate. It needs no API key or live market-data calls.
Use pulse-verity for supported installs and updates. Other similarly named
packages are not a guarantee of availability or release parity.
MIT
Read up to 100 crypto symbols in one /api/index/v1/batch request. Returns observations with individually signed successful rows and per-symbol errors for unavailable rows. Your API tier may allow fewer symbols. Verify each successful row with verify_print; surrounding batch and quality metadata are not signed. No automatic retries.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavioral detail beyond the annotations: individually signed successful rows, per-symbol errors for unavailable rows, unsigned surrounding metadata, and no automatic retries. Describes the partial-success model and verification requirement with no contradiction to readOnlyHint=true.
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?
Five sentences, each carrying distinct information: purpose, return shape, tier limits, verification step, retry policy. No fluff or redundancy, and the core action is front-loaded in the first sentence.
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?
Even without an output schema, the description sketches the return envelope (observations, individually signed rows, per-symbol errors) and the follow-up verification step. A more concrete response-field description would improve completeness, but for a simple one-parameter read tool it is largely sufficient.
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?
With schema description coverage at 0%, the description partially compensates by adding the tier-dependent limit caveat ('Your API tier may allow fewer symbols') that the schema's maxItems=100 does not capture. However, it does not clarify symbol format or normalization expectations beyond what the schema pattern already enforces.
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?
Description states a specific verb ('Read'), a concrete resource ('crypto symbols'), and scope ('up to 100 in one /api/index/v1/batch request'). The batch nature plus per-symbol error handling clearly distinguishes this from siblings like get_index_price and get_settlement_print.
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?
Clear context for when to call it (multi-symbol reads up to 100) with a post-call workflow ('Verify each successful row with verify_print') and a tier-limits caveat. However, it never explicitly names get_index_price as the single-symbol alternative or states when-not to use the batch tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a current signed crypto index price from /api/index/v1/price. Returns symbol, price, optional priceText, at, grade, signature, kid and sig. Preserve priceText exactly for verify_print. Optional tier, confidence, dispersionBps, interval, sources, engine and cadence describe the observation but are not covered by the v1 signature. Coverage changes: use list_index_assets to discover assets. A stale or unavailable response means no current price, never zero.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Crypto ticker symbol, e.g. BTC, ETH, SOL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description explains important behavior: the response is signed, includes a kid and sig, some fields are not covered by the v1 signature, priceText must be preserved exactly, and a stale response should never be interpreted as zero. This significantly helps the agent interpret results correctly.
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 information-dense yet well-structured: purpose and endpoint first, then return fields, then critical caveats about signature coverage and error semantics. Every sentence adds value and nothing is redundant or filler.
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?
With no output schema, the description supplies a full list of return fields and explains the signature boundary. It also covers asset discovery, exact-preservation requirements for verify_print, and stale-response behavior. For a one-parameter read-only tool, nothing essential 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 schema already fully documents the single symbol parameter with a pattern, length constraints, and examples, so the description does not need to compensate. The description adds no parameter-specific formatting guidance, but at 100% schema coverage the baseline of 3 is appropriate.
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 specific verb and resource: 'Get a current signed crypto index price from /api/index/v1/price.' It also distinguishes itself from siblings by pointing to list_index_assets for asset discovery and verify_print for exact priceText preservation, so an agent can tell this tool apart without opening schemas.
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 clear usage context: this tool retrieves a single signed index price, and coverage changes should route the agent to list_index_assets. It also warns that a stale/unavailable response means no current price, never zero. It does not explicitly mention get_index_batch as an alternative for multiple symbols, but the provided guidance is still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the recorded signed index print nearest a requested time from /api/index/v1/print. Accepts ISO-8601 or epoch milliseconds. Check deltaMs: it is the distance between your requested time and the sampled print. Sampling and retention are bounded; a recorded print need not equal a separate live read. Preserve priceText and kid when present for verify_print. deltaMs and other metadata are not signed.
| Name | Required | Description | Default |
|---|---|---|---|
| at | Yes | ||
| symbol | Yes | Crypto ticker symbol, e.g. BTC, ETH, SOL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds genuinely non-obvious details: the result is signed, deltaMs is not part of the signed content, sampling/retention are bounded, and metadata is not signed. No contradiction with annotations.
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?
Compact and front-loaded: the first sentence states the purpose, and each following sentence adds essential operational detail—time formats, deltaMs, sampling limitations, and verify_print preservation. 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?
Even without an output schema, the description covers the relevant response semantics: deltaMs, priceText, kid, and signed vs. non-signed metadata. This is enough for an agent to invoke the tool and correctly feed output into verify_print.
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 describes symbol but not at. The description compensates by explaining the accepted formats for at (ISO-8601 or epoch milliseconds) and the meaning of deltaMs. It adds meaningful semantics beyond the schema, though it does not elaborate on symbol beyond what the schema already provides.
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 plus resource: 'get the recorded signed index print nearest a requested time' from '/api/index/v1/print'. This clearly distinguishes it from live-read siblings while specifying the exact operation.
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?
Provides important usage context: a recorded print may differ from a live read, deltaMs measures distance from the requested time, and priceText/kid should be preserved for verify_print. It does not explicitly name alternatives like get_index_price, but effectively implies when a signed historical print is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one bounded page from /api/index/v1/verity/catalog. Discover crypto symbols and their current coverage status and measured cadence. Catalog rows, prices and metadata are unsigned: use get_index_price or get_index_batch for signed receipts. Availability changes; total is a catalog count, not a count of fresh prices. No automatic pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| band | No | ||
| limit | No | ||
| offset | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description adds significant behavioral context beyond that: catalog rows are unsigned, total is not a count of fresh prices, availability changes, and pagination is bounded and manual. This goes well beyond what the structured annotations alone communicate, with no contradiction.
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 four tight sentences with no filler. The action and endpoint are front-loaded, and every subsequent sentence adds a distinct, decision-relevant fact: unsigned data, alternatives, total semantics, and pagination behavior.
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 read-only paginated list tool with no output schema, the description covers endpoint, purpose, unsigned data caveat, total semantics, pagination behavior, and sibling alternatives. It falls slightly short by not explicitly describing the response structure or stating that limit/offset are the paging controls, though these are implied.
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 burden falls on the description. It provides indirect semantic clues: 'bounded page' implies limit/offset, 'coverage status' maps to status, and 'measured cadence' maps to band. However, it never explicitly defines each parameter or explains how to use the enum values, leaving some ambiguity.
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 specific verb and resource: 'Read one bounded page from /api/index/v1/verity/catalog.' It clearly states what the tool does—discover crypto symbols, coverage status, and cadence—and differentiates it from siblings by explicitly pointing to get_index_price and get_index_batch for signed receipts.
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 concrete guidance on when to prefer alternatives: 'use get_index_price or get_index_batch for signed receipts.' It also warns that there is no automatic pagination, implying the caller must handle paging. It does not explicitly contrast with get_settlement_print or verify_print, but the primary use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a signed print locally with ECDSA P-256/SHA-256. Canonical bytes are pulse-index-v1\n\n<priceText or String(price)>\n\n. The public key ring is fetched from /api/index/v1/pubkey, cached for five minutes and refreshed at most once per 30 seconds on a failed check. A supplied kid selects only that exact key; old prints without kid are tried against the bounded published ring. No API key is sent to the public-key endpoint. valid=true authenticates only the canonical price fields, not kid, sig, quality, cadence, timestamps outside at, or other metadata. An invalid signature can mean an altered print or a key no longer published; it does not by itself prove tampering.
| Name | Required | Description | Default |
|---|---|---|---|
| at | Yes | Timestamp from the print, unchanged | |
| kid | No | Signing key identifier, when provided by the API | |
| sig | No | ||
| grade | Yes | ||
| price | Yes | ||
| symbol | Yes | Crypto ticker symbol, e.g. BTC, ETH, SOL | |
| priceText | No | Exact signed price text, when provided by the API; preserve unchanged | |
| signature | Yes | ECDSA P-256 signature in base64 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description discloses detailed runtime behavior: public key ring fetching with caching and refresh policy, kid-based key selection, no API key sent, and what valid=true does and does not authenticate. This is strong transparency.
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 compact and information-dense, with four sentences covering purpose, canonical bytes, key handling, and validation semantics. No fluff or redundant phrasing is present.
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?
The description covers the core verification flow, key management, and the meaning of valid=true, which is sufficient given the lack of an output schema. It does not explicitly specify error behavior on missing keys or network failures, but those are secondary to the main verification purpose.
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 description clarifies how parameters map to the canonical byte layout: 'pulse-index-v1\n<symbol>\n<priceText or String(price)>\n<at>\n<grade>'. It also explains the optional kid semantics and the role of the signature, adding meaning beyond the schema definitions.
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 clear, specific action: 'Verify a signed print locally with ECDSA P-256/SHA-256.' It identifies both the operation (verify) and the resource (a signed print), and the cryptographic context distinguishes it from the sibling getter 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?
The description explains what the tool does but does not explicitly state when to prefer it over the sibling getter tools, nor does it give an alternative. It implies verification use cases but stops short of clear selection guidance.
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.
v1.1.0get_index_batchget_index_priceget_settlement_printlist_index_assetsverify_printScored across 5 tools
Each tool has a clearly distinct purpose: live single price, live batch prices, asset discovery, historical print lookup, and local signature verification. There is no meaningful overlap among the tool boundaries.
All tool names follow a predictable snake_case action_noun pattern: get_*, list_*, and verify_*. The verbs align with the operation type, and there is no mixing of naming conventions.
Five tools is well-scoped for a focused signed index price service. Each tool serves a necessary function and there is no redundancy or bloat.
The core workflow of discovering assets, fetching current single/batch prices, retrieving historical prints, and verifying signatures is well covered. Minor gaps remain around catalog pagination and direct visibility into key-ring or retention bounds, but these are workable limitations.
Pulse Verity — crypto index prices that come with a PROOF.
Crypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
Five read-only tools: spot prices, observed premiums, price history, Goldback rate, and currencies.
Crypto price-event settlement verdicts and US building-permit data, paid per call in USDC.
