PokerData

Explain a postflop combo

explain_combo

Read-onlyIdempotent

Preferred tool for exact NLHE postflop hand questions. Returns a canonical context, exact action mix, action EV/loss when available, made-hand and draw classification, blocker facts, and same-rank-class suit comparisons. The server computes evidence; the agent should phrase causality as interpretation.

Input Schema

TableJSON Schema

Name	Required	Description
`pack`	Yes	Pack id from list_postflop_packs. Use a sizingTrees packId to pick the tree: the pack id for 75% pot on the flop, or "<pack>-flop33" for 33%.
`path`	No	Exact childSegment path from get_postflop_node, e.g. ["Check", "Bet 5.5"]. Empty for the root.
`board`	Yes	Board in spaced form, e.g. "6s 4h 2s"
`combo`	Yes	Required exact two-card combo, e.g. As5s
`anteBb`	No	Requested ante in bb. nlmtt8 models a 1bb BB-ante; other positive antes return unsupported coverage.
`format`	No	Requested poker format. "cash" uses the cash trees. "mtt" is supported only for preflop chip-EV against game nlmtt8; ICM, PKO, and satellite remain unsupported.
`objective`	No	Requested optimization objective. chip_ev is supported for nlmtt8 preflop. ICM, PKO, and satellite return unsupported coverage.
`comparisonLimit`	No	Maximum same-rank-class suit comparisons (default 6, maximum 12)

Output Schema

TableJSON Schema

Name	Required	Description
`result`	No	Recommendation, made-hand and draw classification, blockers, the exact action mix with EV, and same-rank-class suit comparisons. Null when the request is unsupported.
`context`	No	Canonical context the answer belongs to (variant, format, stacks, positions, board, path). Null when the request is unsupported.
`coverage`	No	Whether the request was answered exactly, aggregated, or refused as out of coverage.
`warnings`	No	Caveats that must survive into any answer built on this result.
`schemaVersion`	No	Envelope version, currently "1.0".

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Coverage-first envelope: coverage and context describe the answer, result carries it.",
+  "properties": {
+    "context": {
+      "description": "Canonical context the answer belongs to (variant, format, stacks, positions, board, path). Null when the request is unsupported.",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "coverage": {
+      "description": "Whether the request was answered exactly, aggregated, or refused as out of coverage.",
+      "properties": {
+        "analyzedBoards": {
+          "description": "Boards actually read at the requested path.",
+          "type": "integer"
+        },
+        "available": {
+          "description": "What is published instead.",
+          "type": "string"
+        },
+        "dataClass": {
+          "description": "\"solver\", \"solver_aggregate\", or \"solver_comparison\".",
+          "type": "string"
+        },
+        "generatedAt": {
+          "description": "When the pack was generated.",
+          "type": "string"
+        },
+        "hasEv": {
+          "description": "Whether the pack ships per-combo EV.",
+          "type": "boolean"
+        },
+        "matchingBoards": {
+          "description": "Boards matching the texture filters.",
+          "type": "integer"
+        },
+        "objective": {
+          "description": "\"solver_ev\", \"cash_game_ev\", or \"chip_ev\".",
+          "type": "string"
+        },
+        "omittedByLimit": {
+          "description": "Matching boards dropped by boardLimit.",
+          "type": "integer"
+        },
+        "reason": {
+          "description": "Why the request is out of coverage.",
+          "type": "string"
+        },
+        "requested": {
+          "description": "The format, objective, ante, or pack that was asked for.",
+          "type": "object"
+        },
+        "solveQuality": {
+          "description": "Published exploitability and iteration counts. Omitted, never estimated, when the pack does not publish them.",
+          "type": "object"
+        },
+        "source": {
+          "description": "Pack, board, path, generation time, and solve quality.",
+          "type": "object"
+        },
+        "status": {
+          "description": "\"exact\", \"aggregated_report\", or \"unsupported\". Treat \"unsupported\" as a hard stop.",
+          "type": "string"
+        },
+        "unavailableAtPath": {
+          "description": "Selected boards with no node at the path.",
+          "type": "integer"
+        }
+      },
+      "type": "object"
+    },
+    "result": {
+      "description": "Recommendation, made-hand and draw classification, blockers, the exact action mix with EV, and same-rank-class suit comparisons. Null when the request is unsupported.",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "schemaVersion": {
+      "description": "Envelope version, currently \"1.0\".",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Caveats that must survive into any answer built on this result.",
+      "items": {
+        "description": "One caveat about how the result may be used.",
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

First observedOct 16, 2026

TDQS

A3.7/5.0

Behavior4/5

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

The annotations already declare a safe, idempotent, read-only, closed-world read. Beyond that, the description adds real behavioral guidance: EV/loss is only returned 'when available,' and the explicit instruction that the server computes evidence while the agent should phrase causality as interpretation is a meaningful guardrail not captured by structured fields.

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 tight sentences, front-loaded with the primary use case, followed by the return payload and a behavioral caveat. No filler, though the enumerated return list is somewhat dense.

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, the description needn't restate return values, and the parameter-level guidance lives in a fully described schema. The added note on framing causality as interpretation rounds out an otherwise complete definition for this domain-specific analysis 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 eight parameters — including the pack/path/board/combo mechanics and the anteBb/format/objective coverage caveats — are already documented in the schema. The description adds no additional parameter-level detail, so the baseline 3 applies.

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 states a specific verb and resource ('explain' a 'postflop combo') and lists exactly what the tool returns (action mix, EV/loss, hand and draw classification, blocker facts, suit comparisons). It is clearly a per-combo solver explanation, but it never names a sibling (e.g. get_hand_results, get_postflop_node, compare_strategies) to differentiate 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?

It positions itself as the 'preferred tool for exact NLHE postflop hand questions,' which implies the usage context, and the schema notes tie parameters back to list_postflop_packs and get_postflop_node. However, there is no explicit when-not and no named alternative for adjacent tasks such as comparing strategies or fetching a whole node.

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?