Skip to main content
Glama
freshlife001

Texas Holdem MCP Server

by freshlife001

get_table_status

Retrieve the real-time status of a Texas Holdem poker table by providing the player ID and table ID, enabling AI agents to monitor and manage gameplay effectively.

Instructions

Get the current status of a poker table

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
player_idYes
table_idYes

Implementation Reference

  • src/mcpServer.ts:54-65 (registration)
    Tool registration in the listTools response, including name, description, and input schema.
    {
      name: "get_table_status",
      description: "Get the current status of a poker table",
      inputSchema: {
        type: "object",
        properties: {
          player_id: { type: "string" },
          table_id: { type: "string" },
        },
        required: ["player_id", "table_id"],
      },
    },
  • Input schema definition for get_table_status tool: requires player_id and table_id as strings.
    inputSchema: {
      type: "object",
      properties: {
        player_id: { type: "string" },
        table_id: { type: "string" },
      },
      required: ["player_id", "table_id"],
    },
  • Handler logic: Fetches table state using sendPokerRequest('getTableState') with player_id and table_id, formats it using formatTableState, and sets view_text.
    else if (request.params.name === "get_table_status") {
      // Get the current state of the table
      const tableState = await sendPokerRequest('getTableState', {
        playerId: args?.player_id,
        tableId: args?.table_id
      });
      
      view_text = `Current status for table ${args?.table_id}:\n`;
      view_text += formatTableState(tableState);
    }
  • Helper function to format the table state into a readable string, used in the handler.
    function formatTableState(tableState: any): string {
      if (!tableState) return "No table state available.";
      
      let result = `Table: ${tableState.name} (ID: ${tableState.id})\n`;
      result += `Stage: ${tableState.stage}\n`;
      result += `Pot: $${tableState.pot}\n`;
      result += `Current Bet: $${tableState.currentBet}\n`;
      
      // Find the current active player
      const currentPlayer = tableState.players.find((p: any) => p.isActive);
      if (currentPlayer) {
        result += `Current Player: ${currentPlayer.name} (ID: ${currentPlayer.id})\n`;
      }
      
      // Community cards
      result += `Community Cards: ${tableState.communityCards.join(', ') || 'None'}\n\n`;
      
      // Players
      result += "Players:\n";
      tableState.players.forEach((player: any) => {
        result += `- ${player.name}: $${player.chips} chips`;
        
        if (player.isDealer) result += " (Dealer)";
        if (player.isSmallBlind) result += " (Small Blind)";
        if (player.isBigBlind) result += " (Big Blind)";
        if (player.isActive) result += " (Active)";
        if (player.folded) result += " (Folded)";
        if (player.isAllIn) result += " (All-In)";
        
        result += ` - Bet: $${player.bet}\n`;
        
        // Show hand if available
        if (player.hand && player.hand.length > 0) {
          result += `  Hand: ${player.hand.join(', ')}\n`;
        }
      });
      
      return result;
    }
  • Helper function to send requests to the poker server via socket.io, called by the handler.
    function sendPokerRequest(method: string, params: any): Promise<any> {
      return new Promise((resolve, reject) => {
        const request = {
          method,
          params,
          id: Date.now()
        };
        
        //console.log(`[Client] Sending request: ${method}`, params);
        
        socket.emit('action', request, (response: any) => {
          //console.log(`[Client] Received response for ${method}:`, response);
          
          if (response.error) {
            console.error(`[Client] Error in ${method}:`, response.error);
            reject(response.error);
          } else {
            resolve(response.result);
          }
        });
      });
    }
Behavior2/5

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

With no annotations, the description carries full burden but provides minimal behavioral insight. It implies a read-only operation but doesn't disclose whether it requires authentication, affects game state, has rate limits, or what the output format might be. This is inadequate for a tool with potential side effects.

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 a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse.

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

Completeness2/5

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

Given no annotations, 0% schema coverage, and no output schema, the description is insufficient. It doesn't cover authentication needs, error conditions, return values, or how it fits with sibling tools like 'login' or 'join_table', leaving critical gaps for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'player_id' and 'table_id' represent, their formats, or how they relate to getting table status, leaving parameters entirely undocumented.

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 the verb ('Get') and resource ('current status of a poker table'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'join_table' or 'leave_table', but the action is specific enough to infer differentiation.

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 guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to be logged in or at a table) or contrast with other status-checking tools, leaving the agent to infer usage from context alone.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/freshlife001/mcp_poker'

If you have feedback or need assistance with the MCP directory API, please join our Discord server