Prediction Markets Quant

NFL Prop Market Board (Kalshi vs the books vs exchanges)

nfl_prop_board

Read-only

Use for "where is the best price on receiving yards" and "is Kalshi cheaper than the books". Best price on every NFL prop this week: Kalshi (fee included) vs five books (DraftKings, FanDuel, BetRivers, Fanatics, ESPN) and the Novig and ProphetX exchanges — the best price per side, how much cheaper Kalshi is than the books, the consensus gap, and the Kalshi close once a strike settles. Filter by team, game, player or stat.

Input Schema

TableJSON Schema

Name	Required	Description
`game`	No	Game anchor away-home, e.g. "ne-sea" — rows for that game only.
`team`	No	Team abbrev (SEA, NE, LAR, JAX) — rows for that club only.
`limit`	No	Max rows (default 15). Values above 50 are clamped to 50.
`player`	No	Player name (partial, case-insensitive), e.g. "Nacua".
`gapsOnly`	No	Only strikes where Kalshi and the consensus are 5¢+ apart (default false).
`statType`	No	Optional prop type filter. One of: pass_yds · pass_tds · rush_yds · rec_yds · receptions · anytime_td.

Output Schema

TableJSON Schema

Name	Required	Description
`rows`	No	Priced Kalshi prop strikes: player, stat, strike, Kalshi book, consensus, venue quotes, gap, best price per side.
`week`	No	NFL week.
`count`	No	Rows returned.
`sources`	No
`summary`	No	Board counts: listed, booked, consensus-priced, gaps, arbs, games.
`tell_user`	No	Show this sentence to the user first.
`timestamp`	No
`needs_input`	No
`example_call`	No
`data_freshness`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 15, 2026

removedInput schema / properties / limit / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "type": "number"
-      },
-      {
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / limit / type

Added value: +[
+  "number",
+  "string",
+  "null"
+]

Changed4 schema fields changedOct 6, 2026

addedInput schema / properties / statType / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "enum": [
+      "pass_yds",
+      "pass_tds",
+      "rush_yds",
+      "rec_yds",
+      "receptions",
+      "anytime_td"
+    ],
+    "type": "string"
+  }
+]

changedInput schema / properties / statType / description

Previous value: -"Optional prop type filter."New value: +"Optional prop type filter. One of: pass_yds · pass_tds · rush_yds · rec_yds · receptions · anytime_td."

removedInput schema / properties / statType / enum

Removed value: -[
-  "pass_yds",
-  "pass_tds",
-  "rush_yds",
-  "rec_yds",
-  "receptions",
-  "anytime_td"
-]

removedInput schema / properties / statType / type
```
Removed value: -"string"
```

Changed6 schema fields changedOct 1, 2026

addedInput schema / properties / limit / anyOf

Added value: +[
+  {
+    "anyOf": [
+      {
+        "type": "number"
+      },
+      {
+        "type": "string"
+      }
+    ]
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / limit / default
```
Removed value: -15
```

changedInput schema / properties / limit / description

Previous value: -"Max rows (default 15)."New value: +"Max rows (default 15). Values above 50 are clamped to 50."

removedInput schema / properties / limit / maximum
```
Removed value: -50
```
removedInput schema / properties / limit / minimum
```
Removed value: -1
```
removedInput schema / properties / limit / type
```
Removed value: -"integer"
```

Changed1 schema field changedSep 29, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "count": {
+      "description": "Rows returned."
+    },
+    "data_freshness": {},
+    "example_call": {},
+    "needs_input": {},
+    "rows": {
+      "description": "Priced Kalshi prop strikes: player, stat, strike, Kalshi book, consensus, venue quotes, gap, best price per side."
+    },
+    "sources": {},
+    "summary": {
+      "description": "Board counts: listed, booked, consensus-priced, gaps, arbs, games."
+    },
+    "tell_user": {
+      "description": "Show this sentence to the user first.",
+      "type": "string"
+    },
+    "timestamp": {
+      "type": "string"
+    },
+    "week": {
+      "description": "NFL week."
+    }
+  },
+  "type": "object"
+}

First observedSep 6, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and scope profile is covered. The description adds meaningful behavior the annotations cannot: Kalshi prices include fees, five specific books plus two exchanges are aggregated, and a Kalshi close is captured once a strike settles. No rate limits or refresh cadence are mentioned.

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?

Trigger queries are front-loaded, and the remaining single sentence packs the source list and return content without filler. Every clause earns its place given the tool's comparison scope.

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?

With an output schema present, return-value details need not be explained, and the description still previews the key outputs (best price per side, Kalshi's discount vs books, consensus gap, settled close). Inputs and intent are fully covered for a read-only board 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%, so all six filters (game, team, player, statType, limit, gapsOnly) are already documented with formats and defaults. The closing 'Filter by team, game, player or stat' only restates a subset of what the schema says and omits gapsOnly and limit, adding little beyond baseline.

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?

States a specific resource (best price on every NFL prop this week) and enumerates the exact sources it compares: Kalshi with fees, five named books, and the Novig/ProphetX exchanges. An agent immediately knows this is a cross-venue price board, though it never explicitly distinguishes itself from siblings like nfl_prop_edge or nba_prop_board.

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?

Opens with two concrete trigger queries — 'where is the best price on <player> receiving yards' and 'is Kalshi cheaper than the books' — which map the tool to a clear intent. It does not state when to prefer alternatives (e.g., nfl_prop_edge for single-strike edge math), so no exclusions are offered.

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

All Prediction Markets Quant 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.