PokerData

Summarize a session

get_session_summary

Read-onlyIdempotent

One uploaded session's headline numbers: hero, game type, start and end times, hands played, net result in big blinds, and HUD rates (VPIP, PFR, 3-bet, open limp) as percentages with the sample size. Use it after list_my_sessions to report how a session went; use get_hand_results for its winnings curve and find_hands for individual hands. Returns an error for an unknown session id. Any key works, free trial included, and it never counts against the allowance. If this account has no hands, offer the hosted upload page from get_upload_link (https://pokerdata.io/upload) instead of asking the user to paste histories into chat.

Input Schema

Name	Required	Description	Default
`session_id`	Yes	Session id from list_my_sessions.

Output Schema

Name	Required	Description
`id`	No	Session id.
`hud`	No	HUD rates over this session, as percentages.
`hero`	No	Hero name in the history.
`error`	No	Present instead of a payload when the request named something that does not exist. No figure is estimated in its place.
`hands`	No	Hands in the session.
`netBb`	No	Session result in big blinds.
`endedAt`	No	Last hand timestamp.
`game_type`	No	Game type: "NLHE", "PLO", "PLO5", or "PLO6".
`startedAt`	No	First hand timestamp.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 16, 2026

addedInput schema / properties / session_id / description
```
Added value: +"Session id from list_my_sessions."
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Headline numbers and HUD rates for one uploaded session.",
+  "properties": {
+    "endedAt": {
+      "description": "Last hand timestamp.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Present instead of a payload when the request named something that does not exist. No figure is estimated in its place.",
+      "type": "string"
+    },
+    "game_type": {
+      "description": "Game type: \"NLHE\", \"PLO\", \"PLO5\", or \"PLO6\".",
+      "type": "string"
+    },
+    "hands": {
+      "description": "Hands in the session.",
+      "type": "integer"
+    },
+    "hero": {
+      "description": "Hero name in the history.",
+      "type": "string"
+    },
+    "hud": {
+      "description": "HUD rates over this session, as percentages.",
+      "properties": {
+        "limp": {
+          "description": "Open limp, percent.",
+          "type": "number"
+        },
+        "pfr": {
+          "description": "Preflop raise, percent.",
+          "type": "number"
+        },
+        "sample": {
+          "description": "Hands the rates are computed over.",
+          "type": "integer"
+        },
+        "threeBet": {
+          "description": "3-bet, percent.",
+          "type": "number"
+        },
+        "vpip": {
+          "description": "Voluntarily put money in pot, percent.",
+          "type": "number"
+        }
+      },
+      "type": "object"
+    },
+    "id": {
+      "description": "Session id.",
+      "type": "string"
+    },
+    "netBb": {
+      "description": "Session result in big blinds.",
+      "type": "number"
+    },
+    "startedAt": {
+      "description": "First hand timestamp.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedOct 16, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, but the description adds genuinely non-obvious behavior: it errors on an unknown session id, it never counts against the allowance, and free-trial keys work. The upload-page fallback is a useful behavioral cue, though the quota/free-trial remark is slightly promotional rather than operational.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core sentence is well front-loaded, but enumerating every returned field is redundant given the output schema exists, and the 'Any key works, free trial included' clause plus the upload-page paragraph drift toward product messaging rather than invocation guidance.

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 return values needn't be explained, yet the description helpfully covers the error path for an unknown id and the empty-account fallback. It is nearly complete for a single-parameter read tool; only minor padding weakens it.

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?

The single session_id parameter is already fully documented in the schema (100% coverage, uuid format with pattern) and points back to list_my_sessions. The description adds nothing about the parameter itself, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('One uploaded session's headline numbers') and enumerates the exact fields returned (hero, game type, times, hands, net bb, HUD rates). It explicitly distinguishes itself from get_hand_results and find_hands, which cover the winnings curve and individual hands respectively.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the sequencing ('Use it after list_my_sessions to report how a session went') and routes the agent to the correct alternatives for adjacent needs (get_hand_results for winnings curve, find_hands for individual hands). It also gives an explicit fallback when the account has no hands.

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.