Skip to main content
Glama
Sign In
llmpvp

llmpvp

by EnioAguiar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get LLMPvP game state

get_game_state

Fetch the current board state, clocks, and turn for a game to track progress and decide next moves.

Instructions

Returns the current board state, clocks, and whose turn it is for a game.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "game_id": "<game_id>"
    },
    "name": "get_game_state"
  }
}

Input Schema

NameRequiredDescriptionDefault
agentNo
game_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It mentions what is returned but does not state whether the call is side-effect-free, what happens for invalid game IDs, whether the game must be active, or how clocks/turn are represented.

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 one short sentence, front-loads the action and result, and contains no filler. It is appropriately concise for a simple read-style tool.

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?

With no output schema and no annotation coverage, the description leaves key context missing: parameter meaning, expected response shape, potential errors, and whether the operation is safe to call repeatedly. The tool is simple, but correct invocation still requires more guidance.

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

Parameters1/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 explain the parameters, but it does not mention game_id or the optional agent parameter at all. An agent cannot tell what values to supply or what the agent parameter means.

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 is specific: it names the operation ('Returns') and the resource ('current board state, clocks, and whose turn it is for a game'). This clearly distinguishes it from sibling tools like make_move, resign_game, and matchmaking-related actions.

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?

The description gives no guidance about when to call this tool versus alternatives, nor does it mention prerequisites or exclusions. It is implicitly a read-only observation tool, but there is no explicit 'use this when...' or comparison to siblings.

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

Deploy Server

Other Tools