pulse-verity

Submit Verity Feedback

submit_verity_feedback

Idempotent

Submit reproducible Verity API or MCP bugs, missing capabilities, or data-quality issues for human review and get a tracking receipt once stored privately.

Instructions

Submit a reproducible Verity API or MCP bug, missing capability or data-quality report for human review. Requires a developer key (PULSE_API_KEY) or the hosted server, and an enabled feedback service. Include the failed call's requestId when available. Do not send secrets, personal information or conversation transcripts. Saves a private report; does not change prices, start trades or open or merge a PR. Returns a tracking receipt only after storage succeeds.

Input Schema

Name	Required	Description	Default
`actual`	Yes
`symbol`	No
`surface`	Yes
`category`	Yes
`expected`	Yes
`requestId`	No
`observedAt`	No
`reproduction`	Yes

Output Schema

Name	Required	Description
`error`	No
`success`	No
`feedback`	No
`duplicate`	No
`requestId`	Yes	Identifier for this MCP call; not a signed price field.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.3.6Oct 22, 2026

changedInput schema / properties / surface / enum

Previous value: -[
-  "get_index_price",
-  "get_index_batch",
-  "list_index_assets",
-  "get_settlement_print",
-  "verify_print",
-  "/api/index/v1/price",
-  "/api/index/v1/batch",
-  "/api/index/v1/print",
-  "/api/index/v1/verity/catalog",
-  "/api/index/v1/pubkey",
-  "/api/index/v1/sample",
-  "/api/index/v1/history",
-  "/api/index/v1/metadata",
-  "/api/index/v1/research/compare",
-  "/api/index/v1/source-health",
-  "/api/index/v1/verity/price",
-  "/api/index/v1/verity/batch",
-  "/api/index/mcp"
-]New value: +[
+  "get_index_price",
+  "get_index_batch",
+  "list_index_assets",
+  "get_recorded_print",
+  "get_settlement_print",
+  "verify_print",
+  "/api/index/v1/price",
+  "/api/index/v1/batch",
+  "/api/index/v1/print",
+  "/api/index/v1/verity/catalog",
+  "/api/index/v1/pubkey",
+  "/api/index/v1/sample",
+  "/api/index/v1/history",
+  "/api/index/v1/metadata",
+  "/api/index/v1/research/compare",
+  "/api/index/v1/source-health",
+  "/api/index/v1/verity/price",
+  "/api/index/v1/verity/batch",
+  "/api/index/mcp"
+]

addedOutput schema / properties / error / properties / batchLimit

Added value: +{
+  "maximum": 100000,
+  "minimum": 1,
+  "type": "integer"
+}

addedOutput schema / properties / error / properties / plan

Added value: +{
+  "enum": [
+    "Developer",
+    "Basic",
+    "Builder",
+    "Commercial",
+    "Enterprise"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / error / properties / requested

Added value: +{
+  "maximum": 100000,
+  "minimum": 1,
+  "type": "integer"
+}

Changed6 schema fields changedv1.3.3Oct 18, 2026

addedOutput schema / properties / error / properties / capacityAction

Added value: +{
+  "enum": [
+    "review_plans",
+    "contact_support"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / error / properties / getKeyUrl

Added value: +{
+  "maxLength": 256,
+  "pattern": "^https:\\/\\/thepulse\\.markets\\/developers(?:[/?#][^\\s]*)?$",
+  "type": "string"
+}

addedOutput schema / properties / error / properties / hostedServerUrl

Added value: +{
+  "const": "https://mcp.thepulse.markets/api/index/mcp",
+  "type": "string"
+}

changedOutput schema / properties / error / properties / nextAction / enum

Previous value: -[
-  "wait",
-  "review_access",
-  "check_limits",
-  "reconnect",
-  "check_input",
-  "choose_another_symbol",
-  "report_issue"
-]New value: +[
+  "wait",
+  "review_access",
+  "check_limits",
+  "reconnect",
+  "check_input",
+  "choose_another_symbol",
+  "report_issue",
+  "get_key"
+]

addedOutput schema / properties / error / properties / resetAt

Added value: +{
+  "pattern": "^\\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\\d|3[01])T([01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d\\.\\d{3}Z$",
+  "type": "string"
+}

addedOutput schema / properties / error / properties / upgradeUrl

Added value: +{
+  "const": "https://thepulse.markets/developers#/portal/pricing",
+  "type": "string"
+}

Addedv1.3.0Sep 30, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations declare a non-read-only, non-destructive, idempotent, open-world write, and the description adds real context beyond them: auth prerequisites, that the saved report is private, an explicit statement of side-effect boundaries (does not change prices, start trades, or open/merge a PR), and that a tracking receipt is returned only after storage succeeds. That last point is genuine atomicity/response semantics an agent could not infer from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four compact sentences, front-loaded with what the tool does, then prerequisites, then data-handling constraints, then a receipt/side-effect guarantee. No sentence is redundant and none restates the tool title.

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

Completeness4/5

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

With an output schema present and annotations covering the safety profile, the description need not explain return shape, yet it still names the receipt and its post-storage timing. The main remaining gap is per-field guidance for the five required fields (expected, actual, reproduction), which an agent must guess from field names alone.

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

Parameters2/5

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

Schema description coverage is 0% across 8 parameters, so the description carries the full burden. It only adds meaning for two of them: the requestId (include the failed call's requestId when available) and, indirectly, the category via the report types; it says nothing about how to choose the 19-value surface enum, the expected-vs-actual distinction, or the structure of the reproduction array.

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 opening sentence gives a specific verb (submit) and resource (a Verity API/MCP bug, missing-capability or data-quality report for human review), and the three report categories match the schema enum. It is unmistakably distinct from every sibling, which are all read/index-price retrieval tools.

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 states the trigger conditions (a reproducible bug, missing capability, or data-quality problem) and prerequisites (developer key PULSE_API_KEY or hosted server, enabled feedback service), and adds a negative rule about excluding secrets, personal information and transcripts. It does not explicitly point to a sibling for cases that are not feedback-worthy, which keeps it below a 5.

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

Deploy Server