Prediction Markets Quant

Kelly Position Size

kelly_size

Read-only

Compute the optimal Kelly position size for a Kalshi, Polymarket US or Novig contract. Given your win probability, the market price (which sets the payout), your bankroll, and a Kelly fraction (full / half / quarter / eighth), returns the dollar stake and a risk rating. Use for "how much should I stake", "what is my position size", "Kelly sizing for this trade".

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "kelly_size"
  }
}

Input Schema

Name	Required	Description
`venue`	No	Where you would trade it: kalshi, polymarket-us or novig. Default kalshi. One of: kalshi · polymarket-us · novig.
`bankroll`	No	Total bankroll in dollars (e.g. 1000). Optional — omit it and the result is the % of bankroll to stake, without a dollar figure.
`fraction`	No	Kelly fraction to apply. Half-Kelly is the common sharp-money default. One of: full · half · quarter · eighth.
`marketPrice`	No	Contract price in cents (1–99). Sets the payout ratio. Omit both this and winProbability for the inputs and a worked example. Accepts 55, "55%", "55¢", "$0.55", 0.55 or American odds (+120 / -150) — all read as 55%.
`novigMarket`	No	With venue novig: pregame (default), live or futures. Sets the fee. One of: pregame · live · futures.
`winProbability`	No	Your probability the contract resolves YES, in % (0–100). Omit both this and marketPrice for the inputs and a worked example. Accepts 55, "55%", "55¢", "$0.55", 0.55 or American odds (+120 / -150) — all read as 55%.

Output Schema

Name	Required	Description
`rating`	No	Qualitative read of the sizing.
`sources`	No
`tell_user`	No	Show this sentence to the user first.
`timestamp`	No
`needs_input`	No
`example_call`	No
`stake_dollars`	No	Suggested stake in dollars (when a bankroll was given).
`data_freshness`	No
`full_kelly_pct`	No	Full-Kelly fraction of bankroll, %.
`applied_fraction_pct`	No	The fraction applied, %.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

addedInput schema / properties / novigMarket

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "enum": [
+        "pregame",
+        "live",
+        "futures"
+      ],
+      "type": "string"
+    }
+  ],
+  "description": "With venue novig: pregame (default), live or futures. Sets the fee. One of: pregame · live · futures."
+}

addedInput schema / properties / venue

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "enum": [
+        "kalshi",
+        "polymarket-us",
+        "novig"
+      ],
+      "type": "string"
+    }
+  ],
+  "description": "Where you would trade it: kalshi, polymarket-us or novig. Default kalshi. One of: kalshi · polymarket-us · novig."
+}

Changed3 schema fields changedNov 4, 2026

changedInput schema / properties / marketPrice / description

Previous value: -"Contract price in cents (1–99). Sets the payout ratio. Accepts 55, \"55%\", \"55¢\", \"$0.55\", 0.55 or American odds (+120 / -150) — all read as 55%."New value: +"Contract price in cents (1–99). Sets the payout ratio. Omit both this and winProbability for the inputs and a worked example. Accepts 55, \"55%\", \"55¢\", \"$0.55\", 0.55 or American odds (+120 / -150) — all read as 55%."

changedInput schema / properties / winProbability / description

Previous value: -"Your probability the contract resolves YES, in % (0–100). Accepts 55, \"55%\", \"55¢\", \"$0.55\", 0.55 or American odds (+120 / -150) — all read as 55%."New value: +"Your probability the contract resolves YES, in % (0–100). Omit both this and marketPrice for the inputs and a worked example. Accepts 55, \"55%\", \"55¢\", \"$0.55\", 0.55 or American odds (+120 / -150) — all read as 55%."

removedInput schema / required

Removed value: -[
-  "winProbability",
-  "marketPrice"
-]

Changed3 schema fields changedOct 23, 2026

removedInput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / bankroll / description

Previous value: -"Total bankroll in dollars (e.g. 1000). Optional — omit it and the result is the % of bankroll to stake, without a dollar figure. Accepts a number or a numeric string (\"1000\", \"$1,000\")."New value: +"Total bankroll in dollars (e.g. 1000). Optional — omit it and the result is the % of bankroll to stake, without a dollar figure."

removedOutput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

Changed6 schema fields changedOct 15, 2026

removedInput schema / properties / bankroll / anyOf

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

addedInput schema / properties / bankroll / type
```
Added value: +[
+  "number",
+  "string"
+]
```

removedInput schema / properties / marketPrice / anyOf

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

addedInput schema / properties / marketPrice / type
```
Added value: +[
+  "number",
+  "string"
+]
```

removedInput schema / properties / winProbability / anyOf

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

addedInput schema / properties / winProbability / type
```
Added value: +[
+  "number",
+  "string"
+]
```

Changed5 schema fields changedOct 6, 2026

addedInput schema / properties / fraction / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "enum": [
+      "full",
+      "half",
+      "quarter",
+      "eighth"
+    ],
+    "type": "string"
+  }
+]

removedInput schema / properties / fraction / default
```
Removed value: -"half"
```

changedInput schema / properties / fraction / description

Previous value: -"Kelly fraction to apply. Half-Kelly is the common sharp-money default."New value: +"Kelly fraction to apply. Half-Kelly is the common sharp-money default. One of: full · half · quarter · eighth."

removedInput schema / properties / fraction / enum

Removed value: -[
-  "full",
-  "half",
-  "quarter",
-  "eighth"
-]

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

Changed1 schema field changedSep 29, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "applied_fraction_pct": {
+      "description": "The fraction applied, %."
+    },
+    "data_freshness": {},
+    "example_call": {},
+    "full_kelly_pct": {
+      "description": "Full-Kelly fraction of bankroll, %."
+    },
+    "needs_input": {},
+    "rating": {
+      "description": "Qualitative read of the sizing."
+    },
+    "sources": {},
+    "stake_dollars": {
+      "description": "Suggested stake in dollars (when a bankroll was given)."
+    },
+    "tell_user": {
+      "description": "Show this sentence to the user first.",
+      "type": "string"
+    },
+    "timestamp": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 6, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds value beyond them: it names the outputs (dollar stake plus a risk rating) and discloses a non-obvious fallback — omitting both marketPrice and winProbability returns the input reference and a worked example rather than an error. That fallback is the kind of behavior an agent cannot guess from the schema.

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?

Three sentences, front-loaded with the core verb and resource, followed by the required inputs and then intent triggers. The quoted example queries are slightly repetitive but each maps to a distinct user phrasing, so little is wasted.

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?

An output schema exists, so the description needn't explain return values, and it still briefly names the stake and risk rating. Combined with 100% schema coverage and clear read-only annotations, an agent has enough to call this correctly; only the sibling boundary with calculate_ev is left implicit.

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 coverage is 100%, and the schema descriptions are unusually rich (accepted formats like "55%", "$0.55", American odds; default venue; what omitting bankroll yields). The description's restatement of win probability, market price, bankroll and Kelly fraction adds no meaning beyond that, and it never mentions the venue or novigMarket parameters. Baseline 3 applies when the schema carries the semantics.

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 verb and resource ("Compute the optimal Kelly position size") and scopes it to three named venues, so the agent knows exactly what it produces. It does not differentiate from the sibling calculate_ev, which is the most likely confusion point when an agent is choosing between an EV calculation and a staking calculation.

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?

Gives concrete trigger phrasings ("how much should I stake", "what is my position size", "Kelly sizing for this trade") that map user intent to this tool. It stops short of explicit exclusions or naming calculate_ev as the alternative for edge/EV questions, so the agent must infer the boundary itself.

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.