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

TableJSON 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), "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.
`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

Output Schema

TableJSON 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.

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.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioral context: EV values are small blinds relative to fold, compact mode returns action totals, and full=true yields all 169 hands with explicit 0 and no invented EVs — meaningful disclosures about what is and isn't synthesized.

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?

Purpose is front-loaded in the first clause, then it moves through parameter and mode semantics economically. The 'full=true is full=1' fragment is cryptic and some sentences are dense, but there is little waste.

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, return values need not be described, yet the description still clarifies mode differences and EV units for a complex 7-parameter solver tool. Together with full schema coverage, an agent has enough to call it correctly.

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?

Schema coverage is 100% (baseline 3), and the description goes further by explaining the `history` string format with a concrete example ('UTG_60%_HJ'), sizeBb as raise-to in big blinds with a worked number, and the rationale behind full=true's 0-weight hands.

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 — 'Actions available at a decision node' — which clearly separates it from the sibling get_postflop_node via the 'preflop' scope in the title. It never names the alternative sibling explicitly, so an agent must infer preflop-vs-postflop routing rather than being told.

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?

'add `hand` for its exact mixed strategy' and the detail schema's 'use "full" only when exact complete data is required' give implied usage conditions. However, there is no explicit when-to-use / when-not-to-use guidance or routing to siblings like get_postflop_node or get_range.

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.

Resources

Need Help?