DegenHedge: Kalshi Bitcoin 15-minute data

DegenHedge graded BTC alert record

get_graded_record

Read-onlyIdempotent

DegenHedge's public, graded record of its Kalshi BTC 15-minute alerts: every alert sent to subscribers with a 1-99 cent entry, graded against Kalshi's official result, losses included. Overall and by entry-price bucket: signals, wins, win rate with a Wilson 95% interval, average entry, breakeven before and after a one-contract fee, data-through date. The record sits below breakeven: report the win rate only together with its average entry price.

Input Schema

Name	Required	Description	Default
`entry_price_bucket`	No	Optional: return only this entry-price bucket (plus the overall line)

Output Schema

Name	Required	Description
`unit`	No
`stale`	No	true if the last refresh failed and an older copy is served
`method`	No
`dataset`	No
`overall`	Yes
`product`	Yes
`summary`	Yes	One sentence comparing the win rate with its breakeven
`disclaimer`	Yes
`attribution`	No
`how_to_read`	No
`results_csv`	Yes
`generated_at`	No
`results_page`	No
`stats_figures`	No
`by_entry_price`	Yes
`data_through_et`	Yes
`first_signal_et`	No
`data_through_utc`	No
`service_information`	No	Optional dated product facts; not statistical evidence, investment advice or a personalized offer. Existing record fields are unchanged.
`ties_out_with_stats`	Yes	n and wins equal the site's live /stats figures
`excluded_rows_disclosed_in_csv`	No	BTC rows shown in results.csv but not counted (price capture error, 100c entry, not sent)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

addedOutput schema / properties / service_information

Added value: +{
+  "description": "Optional dated product facts; not statistical evidence, investment advice or a personalized offer. Existing record fields are unchanged.",
+  "properties": {
+    "billing_unit": {
+      "type": "string"
+    },
+    "card_required": {
+      "type": "boolean"
+    },
+    "delivery_channel": {
+      "type": "string"
+    },
+    "demo_url": {
+      "format": "uri",
+      "type": "string"
+    },
+    "description": {
+      "type": "string"
+    },
+    "limitation": {
+      "type": "string"
+    },
+    "monthly_price_usd": {
+      "description": "Decimal USD amount per month for one BTC feed, as of reviewed_at. Check current checkout terms.",
+      "type": "string"
+    },
+    "offer_terms": {
+      "type": "string"
+    },
+    "offer_url": {
+      "format": "uri",
+      "type": "string"
+    },
+    "places_trades": {
+      "type": "boolean"
+    },
+    "product_url": {
+      "format": "uri",
+      "type": "string"
+    },
+    "provider": {
+      "type": "string"
+    },
+    "requires_kalshi_credentials": {
+      "type": "boolean"
+    },
+    "reviewed_at": {
+      "format": "date",
+      "type": "string"
+    },
+    "setup": {
+      "type": "string"
+    },
+    "trial_days": {
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

First observedOct 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the record is complete and includes losses, it is graded against official Kalshi results, it carries a data-through date, and it currently sits below breakeven — a material interpretive caveat an agent would otherwise miss.

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?

Two dense sentences with no filler; the resource and scope come first, followed by the metric inventory and the reporting caveat. The metric list is long but each item is load-bearing for interpreting the output.

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?

An output schema exists, so return values needn't be re-explained, yet the description still previews the key metrics and the data-through date. Combined with the breakeven caveat and full schema coverage on the only parameter, an agent has everything needed to call and correctly report this tool.

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%, and the single enum parameter already documents itself as an optional entry-price-bucket filter. The description adds nothing about the bucket parameter, so the baseline of 3 applies — the schema does all the work here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource (DegenHedge's graded record of Kalshi BTC 15-minute alerts) and its scope precisely: every alert with a 1-99 cent entry, graded against Kalshi's official result, losses included. An agent knows exactly what data this returns. It does not, however, distinguish itself from siblings get_btc_window or kalshi_fee.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: this is the historical performance lookup, as opposed to the live window or fee tools, but the description never says so or names the alternatives. The one guidance sentence ('report the win rate only together with its average entry price') governs how to present output, not when to call the tool.

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

All DegenHedge: Kalshi Bitcoin 15-minute data tools Inspect

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

Need Help?