How do I use @pokerai/mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@pokerai/mcp what's GTO for AKs on the button facing a UTG open?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@pokerai/mcp

by pokerai-bet

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

@pokerai/mcp

MCP server for the Pokerai API — solver-grade GTO strategy for 6-max No-Limit Hold'em, exposed as tools your LLM agent (Claude, Cursor, Claude Code, …) can call.

Ask "what's GTO for AKs on the button facing a UTG open?" and the agent gets real presolved frequencies, not a guess.

Setup

You need a Pokerai API key — get one free at https://pokerai.bet/login.

The server runs over stdio via npx, so there's nothing to install globally.

Claude Desktop

Add to claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "pokerai": {
      "command": "npx",
      "args": ["-y", "@pokerai/mcp"],
      "env": { "POKERAI_API_KEY": "gto_your_key_here" }
    }
  }
}

Claude Code

claude mcp add pokerai -e POKERAI_API_KEY=gto_your_key_here -- npx -y @pokerai/mcp

Cursor

~/.cursor/mcp.json (or Settings → MCP), same shape as the Claude Desktop block above.

Related MCP server: agentforge

Tools

Presolved lookups (spend your presolved quota — 1000/mo on the free tier):

Tool	What it returns
`preflop_versions`	selectable strategy chart sets (free)
`preflop_strategy`	fold/call/raise frequencies for a hand vs an action line
`preflop_range`	the whole 169-hand-type range for a position + line
`flop_tree`	flop decision tree (nodes carry tokens)
`flop_node`	strategy at one flop node (with or without a hero hand)

Real-time solver (turn/river) — off by default because it spends the scarce solve quota (25/mo on the free tier). Enable with POKERAI_ENABLE_SOLVE=1:

Tool	What it returns
`solve_schedule`	trigger an on-demand solve (costs 1 solve quota)
`solve_tree`	poll the solve + get its nodes
`solve_node`	strategy at one solved node
`node_evs`	per-hand, per-action EVs at a node

Environment

Var	Purpose
`POKERAI_API_KEY`	required — your key from https://pokerai.bet/login
`POKERAI_ENABLE_SOLVE`	set to `1` to expose the real-time solver tools
`POKERAI_API_BASE`	override the API base (default `https://pokerai.bet`)

Notes

The server authenticates with your key and spends your quota — it holds no shared credential and has no abuse surface of its own.
stdout is the MCP protocol channel; the server logs only to stderr.

MIT licensed. Docs: https://pokerai.bet/docs.en · Reference: https://pokerai.bet/reference

Available Tools

5 tools

flop_nodeFlop node strategyA

Strategy at one flop decision-tree node. Pass a node token minted by flop_tree. With hole_cards → that hand's mixed strategy at the node; omit → the node's whole-range strategy. Free (token-gated).

ParametersJSON Schema

Name	Required	Description	Default
`node`	Yes	node token from flop_tree
`hole_cards`	No	optional hero hand, e.g. 'AdKd'

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, description carries full burden. Discloses token gating and two operational modes. No mention of side effects or errors, but acceptable for a read-like strategy query.

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

Conciseness5/5

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

Three short sentences, front-loaded with purpose, no unnecessary words. Every sentence adds essential information.

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 2 params, no output schema, and simple behavior, description fully covers usage scenarios and prerequisites. No gaps.

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 has 100% coverage. Description adds meaning: 'node' must come from flop_tree, hole_cards is optional with example format 'AdKd'. Adds value beyond schema.

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?

Clearly states it returns a strategy for one flop decision-tree node. Distinguishes two modes: with hole_cards (hand-specific mixed strategy) or without (whole-range strategy).

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?

Explicitly references prerequisite (node token from flop_tree) and explains optional hole_cards parameter. Does not explicitly contrast with sibling tools, but context implies this is for flop nodes only.

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

flop_treeFlop decision treeA

Starting ranges + every decision node for a flop spot. Each node carries a node token to pass to flop_node. Charges 1 presolved quota. Single-street (for turn/river use the solver tools).

ParametersJSON Schema

Name	Required	Description
`board`	Yes	the 3 flop cards, e.g. '2c2h2s'
`pot_type`	Yes
`positions`	Yes	roles→positions. SRP: {hero,raiser,caller}; 3BET/4BET: {hero,raiser,three_bettor}; LIMP: {hero,limper} (hero or limper must be BB)

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden. It discloses the quota charge, single-street nature, and that nodes carry a token. But it does not mention side effects, auth needs, or error handling. The behavior is partially transparent.

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

Conciseness5/5

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

The description is three sentences, each serving a distinct purpose: purpose, node token/quota, and street guidance. No filler, front-loaded with core function.

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?

Though there is no output schema, the description mentions the output includes starting ranges and nodes with tokens, which provides sufficient context for a 3-param tool. Minor gaps about output format or errors remain, but overall complete enough.

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 coverage is 67% with board and positions already described meaningfully. Pot_type has enum values. The description adds no parameter-specific details beyond what the schema provides. Baseline 3 is appropriate.

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?

The description clearly states the tool generates 'Starting ranges + every decision node for a flop spot' and distinguishes it from sibling tools like flop_node and solver tools for turn/river. The title 'Flop decision tree' is accurately explained.

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?

The description explicitly indicates this tool is single-street and advises using solver tools for turn/river. It also notes that it charges 1 presolved quota. However, it lacks explicit when-not-to-use guidance compared to preflop tools.

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

preflop_rangeWhole preflop range for a spotA

The full 169-hand-type range (fold/call/raise per hand type: AA, AKs, AKo, ...) for a position + action line. No hole_cards. Charges 1 presolved quota (one call, not 169).

ParametersJSON Schema

Name	Required	Description
`hero`	Yes	the position whose range you want: UTG / MP / CO / BTN / SB / BB
`table_size`	No	defaults to '6max'
`preflop_actions`	Yes	action sequence incl. blinds; the range is for `hero` acting after these actions
`preflop_version`	No	chart-set id from preflop_versions; omit for the default

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description discloses key behavioral traits: it returns an aggregated range (no hole cards) and charges 1 presolved quota. This provides useful context beyond the schema.

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

Conciseness5/5

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

Two sentences with zero waste. The first sentence defines the output; the second adds critical constraints. Every word serves a purpose.

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?

Given no output schema, the description adequately outlines the return format (169 hand types with actions) and mentions quota. Minor gap: doesn't specify exact structure (e.g., dict vs list) but sufficient for an agent.

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 the baseline is 3. The description adds 'No hole_cards' as contextual insight but doesn't enhance individual parameter meanings beyond what's in the schema.

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?

The description clearly states the tool returns the full 169-hand-type range with fold/call/raise actions for a given position and action line, distinguishing it from siblings that deal with versions or flop-specific tools.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., preflop_strategy). The description implies its purpose for aggregated ranges without hole cards, but doesn't specify exclusive scenarios.

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

preflop_strategyPreflop GTO strategy for a handB

GTO mixed strategy (fold/call/raise frequencies + sizes) for a specific hand facing a preflop action line, 6-max 100bb. Charges 1 presolved quota. The situation (RFI/3-bet/4-bet/...) is derived from the actions.

ParametersJSON Schema

Name	Required	Description
`hero`	Yes	hero position: UTG / MP / CO / BTN / SB / BB
`hole_cards`	Yes	hero's two cards, e.g. 'AhKh'
`preflop_actions`	Yes	full action sequence including blinds, e.g. [{position:'SB',action:'small blind',amount:0.5},{position:'BB',action:'big blind',amount:1},{position:'UTG',action:'raise',amount:3}]
`preflop_version`	No	chart-set id from preflop_versions; omit for the default

TDQS

B3.2/5.0

Behavior2/5

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

Minimal behavioral disclosure: notes it charges 1 presolved quota and that the situation is derived from actions. No mention of side effects, permissions, or limitations beyond quota. With no annotations, more detail is expected.

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 sentences with no filler, efficiently conveying core purpose and a key constraint (quota). Some might prefer structured bullet points, but it's acceptably concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the essential purpose and quota, but lacks details on output format, default version behavior, error handling, or prerequisites (e.g., presolved solution availability). Adequate but not thorough for a 4-parameter 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 parameters are well-documented in the schema. The description adds no additional semantics beyond the tool's overall purpose, which meets the baseline.

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?

Clearly states it provides GTO mixed strategy (fold/call/raise frequencies and sizes) for a specific hand and preflop action line, distinguishing it from sibling tools like preflop_range or flop_node.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like preflop_range, flop_node, or preflop_versions. The description only implies usage for any preflop situation, but lacks comparison or exclusions.

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

preflop_versionsList preflop strategy versionsA

The selectable preflop_version values (id + human label) and which is the default. Free (no quota). Call this before assuming a version id.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

No annotations exist, so the description must disclose behavior. It states the tool is free and lists what it returns (id, human label, default). However, it does not mention whether the list is sorted, paginated, or if there are any side effects. For a read-only listing, this is mostly transparent but lacks minor details.

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

Conciseness5/5

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

Two concise sentences. The first states the core functionality, and the second gives usage advice. No filler or repetition. Every word earns its place.

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?

The tool has no parameters and no output schema. The description summarizes the return values (id, label, default) which is sufficient for a version listing. It could mention the format or any ordering, but it's largely complete given the tool's simplicity.

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?

The input schema has zero parameters, so schema coverage is 100%. The description correctly adds no redundant parameter information. The baseline for zero parameters is 4, and the description meets it without needing to elaborate.

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?

The description clearly states the tool lists 'preflop_version values (id + human label)' and identifies the default. This is a specific verb-resource combination, and it distinguishes from sibling tools like preflop_strategy or flop_node which deal with different aspects of poker strategy.

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?

Explicitly advises 'Call this before assuming a version id', providing a clear when-to-use directive. Also mentions 'Free (no quota)', which informs about cost/limitations. This is comprehensive guidance for a simple listing tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Jul 29, 2026
- First observedflop_node
- First observedflop_tree
- First observedpreflop_range
- First observedpreflop_strategy
- First observedpreflop_versions

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored 2026-07-29 12:40 across 5 tools

Disambiguation5/5

Each tool targets a distinct aspect: preflop_versions for metadata, preflop_strategy for a single hand's preflop strategy, preflop_range for full range, flop_tree for generating flop decision nodes, and flop_node for querying a specific node. Their descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with a street prefix (preflop_ or flop_) and a descriptive suffix (versions, strategy, node, range, tree). The naming is predictable and uniform.

Tool Count5/5

5 tools is well-scoped for a poker GTO solver covering preflop and flop analysis. Each tool serves a specific purpose without redundancy or unnecessary complexity.

Completeness3/5

The set covers preflop and flop strategies comprehensively, but notably lacks turn/river analysis, as acknowledged in flop_tree's description. This leaves a significant gap for full hand analysis, but within its intended scope it is reasonably complete.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

bluffnetOAuth
gg.bluffnet
Live Texas Hold'em for AI agents. The tools teach the rules; the bluffing is up to your model.
Games & Gamification Autonomous Agents
2
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
openmm-mcp A
io.github.QBT-Labs
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Finance
1513
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

MCP-toolhouse
Agent Orchestration Command Line Developer Tools
SecretiveShell
A
license
Not graded
quality
D
maintenance
MCP server for toolhouse.ai. This does not rely on an external llm unlike the official server.
Updated 2 years ago (2025-02-08 13:21 UTC)
4
MIT
agentforge
Agent Orchestration AI & Machine Learning
doggychip
F
license
A
quality
F
maintenance
MCP server that exposes 300+ AI agents as tools via a single API key. Supports listing agents, invoking any agent with chat-completion style messages, checking agent health, and retrieving platform statistics.
Updated 5 months ago (2026-04-21 17:13 UTC)
5
3
-
Moleculer MCP Bridge
Developer Tools Autonomous Agents
alvaroinckot
A
license
Not graded
quality
D
maintenance
MCP server that exposes Moleculer.js microservice actions as AI tools, enabling AI agents to interact with Moleculer services.
Updated a year ago (2025-09-22 21:45 UTC)
7
4
MIT
mcp_sdk_eyra_accelerator_v15
Developer Tools
Vaishnavi-jagan
F
license
Not graded
quality
D
maintenance
A standalone MCP server that exposes API endpoints as tools for AI assistants, using SSE transport.
Updated 6 months ago (2026-03-25 17:50 UTC)
-