PokerData

Get preflop decision node

get_node

Read-onlyIdempotent

Actions available at a decision node. history is an action path ending in the position about to act, e.g. "UTG_60%_HJ". sizeBb is the raise-to in big blinds and sizePctPot is the percent of the pot after calling (nlmtt8 40bb Open 40034 is 2.19bb; the pack label is 2.2x). evs are small blinds relative to fold. Compact mode returns action totals; add hand for its exact mixed strategy. full=true is full=1: all 169 hold'em hands with explicit 0, and no invented EVs.

Input Schema

Name	Required	Description
`full`	No	Hold'em only. When true, each action includes all 169 hands with weight 0 where the bundle omitted the hand. EVs stay only where the bundle scored them.
`game`	Yes	"nl" = no-limit hold'em 6-max cash (169-grid hands, per-hand EV in small blinds), "nl9" = no-limit hold'em 9-max cash, "nlmtt8" = no-limit hold'em 8-max MTT chip-EV (10–300bb, 1bb BB-ante; Fold/Call/Limp/AI/Open/3B tokens), "nlh8-hydra" = no-limit hold'em 8-max MTT chip-EV with a classic 0.1bb ante from every seat (10, 20, 30, 60bb; same tokens as nlmtt8), "nlh8-icm" = no-limit hold'em 8-max MTT with ICM: one stack table per scenario (near the money, 33 or 35 left of 200, 30 paid; final table, 8 left), uneven stacks, 0.125bb ante from every seat, EVs in tournament dollars; pass scenario (list_games lists them; stack alone works only where one table has that depth); get_node only, "nlhu" = no-limit hold'em heads-up for the title, chip-EV, both players at the stack (1–40bb), 0.125bb ante each, SB on the button; get_node only, "plo" = pot-limit Omaha 6-max cash (4-card), "plo5" = pot-limit Omaha 5-card 6-max (100bb, 1.2bb ante), "plo9" = pot-limit Omaha 9-max cash, "plo6hu" = 6-card Omaha heads-up (BTN vs BB, 100bb). Cash trees are not tournament, ICM, PKO, or satellite solves. nlmtt8, nlh8-hydra and nlhu are chip-EV; only nlh8-icm is ICM.
`hand`	No	Optional hand/class
`stack`	Yes	Stack depth in big blinds
`detail`	No	Response detail. "compact" is the default and removes bulk maps; use "full" only when exact complete data is required.
`history`	Yes	Action path ending in a position
`minFreq`	No	Trim per-action ranges
`scenario`	No	nlh8-icm only: the stack table, e.g. "33left-avg40-big-btn" (list_games lists them). Needed when several tables share the stack.

Output Schema

Name	Required	Description
`game`	No	Preflop game id, e.g. "nl" or "nlmtt8".
`hand`	No	The requested hand, when one was asked for.
`hint`	No	How to narrow, page, or widen the same query.
`spot`	No	Action path ending in an action, echoed from the request.
`actor`	No	Position to act at this node.
`stack`	No	Stack depth in big blinds.
`units`	No	Unit labels: stack and sizeBb in bb, evs in sb.
`evUnit`	No	EV unit, "sb".
`actions`	No	Actions at the node.
`history`	No	Action path ending in the acting position.
`version`	No	Dataset version where the bundle publishes one.
`evBaseline`	No	What EV is measured against, "fold".
`schemaVersion`	No	Payload version, 1.
`continuingHands`	No	Hand classes that continue past this node.
`continuingCombos`	No	Combos that continue past this node.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 30, 2026

changedInput schema / properties / game / description

Previous value: -"\"nl\" = no-limit hold'em 6-max cash (169-grid hands, per-hand EV in small blinds), \"nl9\" = no-limit hold'em 9-max cash, \"nlmtt8\" = no-limit hold'em 8-max MTT chip-EV (10–300bb, 1bb BB-ante; Fold/Call/Limp/AI/Open/3B tokens), \"nlh8-hydra\" = no-limit hold'em 8-max MTT chip-EV with a classic 0.1bb ante from every seat (10, 20, 30, 60bb; same tokens as nlmtt8), \"plo\" = pot-limit Omaha 6-max cash (4-card), \"plo5\" = pot-limit Omaha 5-card 6-max (100bb, 1.2bb ante), \"plo9\" = pot-limit Omaha 9-max cash, \"plo6hu\" = 6-card Omaha heads-up (BTN vs BB, 100bb). Cash trees are not tournament, ICM, PKO, or satellite solves. nlmtt8 is chip-EV only."New value: +"\"nl\" = no-limit hold'em 6-max cash (169-grid hands, per-hand EV in small blinds), \"nl9\" = no-limit hold'em 9-max cash, \"nlmtt8\" = no-limit hold'em 8-max MTT chip-EV (10–300bb, 1bb BB-ante; Fold/Call/Limp/AI/Open/3B tokens), \"nlh8-hydra\" = no-limit hold'em 8-max MTT chip-EV with a classic 0.1bb ante from every seat (10, 20, 30, 60bb; same tokens as nlmtt8), \"nlh8-icm\" = no-limit hold'em 8-max MTT with ICM: one stack table per scenario (near the money, 33 or 35 left of 200, 30 paid; final table, 8 left), uneven stacks, 0.125bb ante from every seat, EVs in tournament dollars; pass scenario (list_games lists them; stack alone works only where one table has that depth); get_node only, \"nlhu\" = no-limit hold'em heads-up for the title, chip-EV, both players at the stack (1–40bb), 0.125bb ante each, SB on the button; get_node only, \"plo\" = pot-limit Omaha 6-max cash (4-card), \"plo5\" = pot-limit Omaha 5-card 6-max (100bb, 1.2bb ante), \"plo9\" = pot-limit Omaha 9-max cash, \"plo6hu\" = 6-card Omaha heads-up (BTN vs BB, 100bb). Cash trees are not tournament, ICM, PKO, or satellite solves. nlmtt8, nlh8-hydra and nlhu are chip-EV; only nlh8-icm is ICM."

changedInput schema / properties / game / enum

Previous value: -[
-  "nl",
-  "nl9",
-  "nlmtt8",
-  "nlh8-hydra",
-  "plo",
-  "plo5",
-  "plo9",
-  "plo6hu"
-]New value: +[
+  "nl",
+  "nl9",
+  "nlmtt8",
+  "nlh8-hydra",
+  "nlh8-icm",
+  "nlhu",
+  "plo",
+  "plo5",
+  "plo9",
+  "plo6hu"
+]

addedInput schema / properties / scenario

Added value: +{
+  "description": "nlh8-icm only: the stack table, e.g. \"33left-avg40-big-btn\" (list_games lists them). Needed when several tables share the stack.",
+  "type": "string"
+}

Changed1 schema field changedOct 16, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Every action at one preflop decision node.",
+  "properties": {
+    "actions": {
+      "description": "Actions at the node.",
+      "items": {
+        "description": "One action available at a preflop node.",
+        "properties": {
+          "action": {
+            "description": "Action token, e.g. \"Fold\", \"Open\", \"3B\".",
+            "type": "string"
+          },
+          "combos": {
+            "description": "Combos that take this action.",
+            "type": "number"
+          },
+          "evSb": {
+            "description": "EV in small blinds for the requested hand, if scored.",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "evs": {
+            "additionalProperties": {
+              "description": "EV in small blinds relative to folding.",
+              "type": "number"
+            },
+            "description": "Hand class to EV, only where the solved bundle scored the hand.",
+            "type": "object"
+          },
+          "frequency": {
+            "description": "Frequency for the requested hand, or the action total.",
+            "type": "number"
+          },
+          "kind": {
+            "description": "Action family, e.g. \"fold\", \"call\", \"raise\".",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "sizeBb": {
+            "description": "Raise-to size in big blinds, for raising actions.",
+            "type": "number"
+          },
+          "sizePctPot": {
+            "description": "Raise size as a percent of the pot after calling.",
+            "type": "number"
+          },
+          "weights": {
+            "additionalProperties": {
+              "description": "Action frequency from 0 to 1.",
+              "type": "number"
+            },
+            "description": "Hand class to frequency. An omitted class has weight 0.",
+            "type": "object"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "actor": {
+      "description": "Position to act at this node.",
+      "type": "string"
+    },
+    "continuingCombos": {
+      "description": "Combos that continue past this node.",
+      "type": "number"
+    },
+    "continuingHands": {
+      "description": "Hand classes that continue past this node.",
+      "type": "number"
+    },
+    "evBaseline": {
+      "description": "What EV is measured against, \"fold\".",
+      "type": "string"
+    },
+    "evUnit": {
+      "description": "EV unit, \"sb\".",
+      "type": "string"
+    },
+    "game": {
+      "description": "Preflop game id, e.g. \"nl\" or \"nlmtt8\".",
+      "type": "string"
+    },
+    "hand": {
+      "description": "The requested hand, when one was asked for.",
+      "type": "string"
+    },
+    "hint": {
+      "description": "How to narrow, page, or widen the same query.",
+      "type": "string"
+    },
+    "history": {
+      "description": "Action path ending in the acting position.",
+      "type": "string"
+    },
+    "schemaVersion": {
+      "description": "Payload version, 1.",
+      "type": "number"
+    },
+    "spot": {
+      "description": "Action path ending in an action, echoed from the request.",
+      "type": "string"
+    },
+    "stack": {
+      "description": "Stack depth in big blinds.",
+      "type": "number"
+    },
+    "units": {
+      "description": "Unit labels: stack and sizeBb in bb, evs in sb.",
+      "type": "object"
+    },
+    "version": {
+      "description": "Dataset version where the bundle publishes one.",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

First observedOct 16, 2026

TDQS

A3.7/5.0

Behavior3/5

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

The readOnly/idempotent annotations already cover the safety profile, so the description's added value is the return-shape disclosure: compact returns action totals, adding `hand` yields the exact mixed strategy, and full=true fills in all 169 hands with weight 0 rather than fabricated EVs. That is useful, but the prose is terse and partly restates the schema's own `full` description rather than adding new behavioral context.

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?

It is front-loaded with the core purpose and is dense rather than padded, which suits a domain-heavy tool. Some clauses are cryptic without external context ('nlmtt8 40bb Open 40034 is 2.19bb', 'full=true is full=1') and read as notes rather than explanation.

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 8 params, 100% schema coverage, and an output schema, the description covers the remaining burden well: action-path format, EV units (small blinds relative to fold), sizing units, and the compact-vs-hand-vs-full distinction. An agent can call this correctly without further guessing.

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

Parameters4/5

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

Coverage is already 100%, so baseline is 3, but the description genuinely adds meaning the schema lacks: the `history` format is illustrated ('UTG_60%_HJ'), sizeBb is defined as raise-to in big blinds, and sizePctPot as percent of pot after calling with a worked example. The `hand` and `minFreq` parameters, however, get no such elaboration.

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?

Opens with a specific verb+resource: 'Actions available at a decision node,' which tells an agent exactly what is returned. It does not, however, name the sibling get_postflop_node or otherwise state that this covers preflop only (that distinction lives only in the title), so an agent must infer the boundary itself.

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: 'add `hand` for its exact mixed strategy' and 'full=true is full=1' hint at when to escalate detail, but there is no explicit when-to-use/when-not and no routing to siblings like get_postflop_node, get_range, or compare_strategies.

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

All PokerData 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.