PokerData

List covered games

list_games

Read-onlyIdempotent

Discover covered stack depths and positions. Call this before low-level preflop queries. "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.

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": "list_games"
  }
}

Input Schema

Name	Required	Description	Default
`detail`	No	Response detail. "compact" is the default and removes bulk maps; use "full" only when exact complete data is required.

Output Schema

Name	Required	Description	Default
`_coverage`	No	Formats and objectives this server does and does not answer.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": {
+    "description": "One game id to its covered stacks and positions. Full detail adds the bundle manifest fields.",
+    "properties": {
+      "bundleCount": {
+        "description": "Bundles in the dataset.",
+        "type": "integer"
+      },
+      "error": {
+        "description": "Upstream status code when a game did not answer.",
+        "type": "number"
+      },
+      "game": {
+        "description": "Game id.",
+        "type": "string"
+      },
+      "generatedAt": {
+        "description": "When the dataset was generated.",
+        "type": "string"
+      },
+      "positions": {
+        "description": "Covered positions.",
+        "items": {
+          "description": "Seat label.",
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "stacks": {
+        "description": "Covered stack depths.",
+        "items": {
+          "description": "Stack depth in big blinds.",
+          "type": "number"
+        },
+        "type": "array"
+      },
+      "version": {
+        "description": "Dataset version.",
+        "type": "number"
+      }
+    },
+    "type": "object"
+  },
+  "description": "Coverage for every preflop game, plus what this server does not solve.",
+  "properties": {
+    "_coverage": {
+      "description": "Formats and objectives this server does and does not answer.",
+      "properties": {
+        "format": {
+          "description": "Supported formats: cash and mtt_chip_ev.",
+          "items": {
+            "description": "A supported format.",
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "supportedObjectives": {
+          "description": "Objectives that return data.",
+          "items": {
+            "description": "A supported objective.",
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "supportedTournament": {
+          "description": "The one certified tournament tree.",
+          "properties": {
+            "anteBb": {
+              "description": "BB ante in big blinds, 1.",
+              "type": "number"
+            },
+            "format": {
+              "description": "Always \"mtt\".",
+              "type": "string"
+            },
+            "game": {
+              "description": "Game id, \"nlmtt8\".",
+              "type": "string"
+            },
+            "objective": {
+              "description": "Always \"chip_ev\".",
+              "type": "string"
+            },
+            "tableSize": {
+              "description": "Seats, 8.",
+              "type": "integer"
+            }
+          },
+          "type": "object"
+        },
+        "unsupported": {
+          "description": "ICM, PKO, satellites, 9-max MTT, tournament and multiway postflop.",
+          "items": {
+            "description": "A request type with no published data.",
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

First observedOct 16, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the annotations, which already declare read-only, idempotent, and non-destructive behavior, the description discloses substantive behavioral constraints: which games are chip-EV vs ICM, which variants are get_node only, and what the game codes cover. This is exactly the extra context needed to avoid misinterpretation.

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?

The key instruction is front-loaded, and the extensive game-code enumeration is mostly necessary for disambiguation. However, the long run-on paragraph is dense and could be more structurally organized, which keeps it from a 5.

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?

Given one optional parameter, full schema coverage, rich annotations, and an output schema, the description supplies the coverage matrix and game-mode constraints an agent needs. No important invocation or interpretation detail appears to be missing.

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?

There is only one parameter, detail, and schema description coverage is 100%, so the schema already explains the compact/full enum. The description does not add further parameter semantics, making the baseline 3 appropriate.

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 clearly states a specific verb and resource: discover/list covered games, stack depths, and positions, with detailed game-code meanings. It distinguishes itself from low-level query tools via 'Call this before low-level preflop queries,' but does not explicitly differentiate itself from listing siblings such as list_datasets or list_spots.

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?

It gives explicit usage context: call this before low-level preflop queries, and notes game-specific restrictions such as get_node only for nlh8-icm and nlhu. It also clarifies that cash trees are not tournament/ICM/PKO/satellite solves, though it does not name alternative listing tools directly.

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.