Moddable Games Tools
Server Details
15 tools for chess variant analysis, hex map generation, and board game utilities
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 15 of 15 tools scored. Lowest: 3.1/5.
Each tool is clearly distinguished by a prefix indicating its domain (chess_, dice_, hex_, ti4_). Within each domain, tools have distinct purposes (e.g., analyze vs puzzle vs legal moves) with no functional overlap.
All tool names follow a consistent snake_case pattern with a domain prefix and a verb_noun structure (e.g., chess_analyze_position, hex_generate_map). No mixing of conventions.
15 tools is a reasonable number for a diverse set of game utilities. The count is slightly on the higher side but still well-scoped per domain, with each tool serving a specific function.
While chess and hex sub-domains are fairly complete (covering analysis, generation, pathfinding, etc.), the overall game tools surface has notable gaps—missing card games, dice macros, or other common moddable game features. The set feels like a collection of utilities rather than a comprehensive suite.
Available Tools
15 toolschess_analyze_positionAInspect
Evaluate a chess position using the engine. Returns a score (centipawns from the side to move), best move, and the principal variation.
| Name | Required | Description | Default |
|---|---|---|---|
| fen | No | FEN string. Omit for starting position. | |
| depth | No | Search depth (1-6). Higher is slower but more accurate. Defaults to 4. | |
| variant | No | Variant key. Defaults to "standard". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions that depth affects accuracy and speed, but does not disclose whether the engine is local or remote, any side effects, or rate limits. It implies read-only behavior but does not explicitly state idempotency or safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and output, with no extraneous words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clearly explains the return values (score in centipawns, best move, principal variation). For a tool with 3 simple parameters, this is nearly complete. Minor omission: whether the operation is asynchronous or persistent side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds minimal value beyond the schema. It repeats the fen description, adds a note on depth performance, and leaves variant as is. Given high schema coverage, baseline is 3, and the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates a chess position using an engine, and specifies the return values (score, best move, principal variation). It distinguishes itself from sibling tools like chess_get_legal_moves and chess_validate_move by focusing on evaluation rather than listing or validating moves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. The sibling tools are listed in context but the description itself offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chess_generate_puzzleAInspect
Generate a chess puzzle (mate-in-N or tactical sequence). Returns a FEN position and the solution moves.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Puzzle type. Defaults to "mate-in-1". | |
| variant | No | Variant key. Defaults to "standard". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool generates a puzzle and returns FEN and moves, but lacks details on randomness, constraints, or side effects. It is accurate but minimal for a generative tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the tool's purpose and output without any fluff. It is concise and front-loaded, making it easy for an AI agent to quickly understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional parameters, no output schema), the description adequately states what the tool does and what it returns. However, it does not explain the format of the FEN or solution moves, which could be helpful for a generation tool. It meets basic needs but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters. The description adds marginal value by mentioning 'mate-in-N or tactical sequence' which loosely maps to the type enum, but does not provide additional semantic detail beyond what the schema's descriptions already offer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating chess puzzles (mate-in-N or tactical sequence) and specifies the output (FEN position and solution moves). This distinguishes it from sibling tools like chess_analyze_position or chess_get_legal_moves, which serve different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for generating puzzles, but it does not provide explicit guidance on when to prefer this tool over alternatives (e.g., when to choose a tactical puzzle vs. mate-in-2). No 'when not to use' or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chess_get_legal_movesAInspect
Get all legal moves for the current position. Returns moves in algebraic notation with annotations (capture, promotion, castling, etc).
| Name | Required | Description | Default |
|---|---|---|---|
| fen | No | FEN string of the position. Omit to use the variant starting position. | |
| variant | No | Variant key (e.g. "standard", "atomic", "capablanca"). Defaults to "standard". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It discloses the output format (algebraic notation with annotations for capture, promotion, castling) and implies a read-only operation. It could add mention of variant support but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no unnecessary words. It front-loads the primary action and then specifies the return format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description is largely complete. It explains what the tool does and what it returns. It could briefly mention that the variant parameter affects legal moves, but the schema already covers this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds no additional meaning beyond the schema; it does not reference the parameters at all. The schema already adequately describes 'fen' and 'variant'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all legal moves for a chess position, using verb+resource format. It distinguishes itself from sibling tools like chess_validate_move (which checks a specific move) and chess_analyze_position (which analyzes the position), but does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 does not mention when to use chess_validate_move or chess_analyze_position, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chess_get_opening_bookAInspect
Look up opening book moves for a position. Returns known good continuations from the variant opening book.
| Name | Required | Description | Default |
|---|---|---|---|
| fen | No | FEN string. Omit for starting position. | |
| variant | No | Variant key. Defaults to "standard". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only implies a read operation but does not disclose any behavioral traits like performance, permissions, or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple lookup tool, but lacks output structure description and any caveats. Gaps remain due to missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters (100% coverage). Description adds value by explaining default behavior for FEN ('Omit for starting position') and variant default ('standard').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool looks up opening book moves for a position and returns known good continuations, distinguishing it from siblings like chess_get_legal_moves or chess_analyze_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to prefer opening book over legal moves or analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chess_list_variantsAInspect
List all available chess variants with their descriptions, board sizes, and rules.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Filter by group name (Classic, Tactical, Alternate Rules, Asymmetric, Small Boards, Large Boards). Omit for all. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool lists variants without side effects, which is appropriate for a read-only operation. However, it does not mention any potential limitations (e.g., pagination, rate limiting) or confirm nondestructive intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, directly communicates purpose. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (one optional parameter, no output schema), the description is largely complete. It explains what is returned (variants with board sizes, rules). Minor gap: does not clarify that omitting group returns all variants (implied).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the parameter (group filter with example values). The description adds no new semantic information beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all chess variants with details like descriptions, board sizes, and rules. It distinguishes from sibling tools (e.g., chess_analyze_position, chess_generate_puzzle) which are analytical or gameplay-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. While the purpose is clear, the description does not provide any usage context or exclusions, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chess_make_movesAInspect
Play a sequence of moves from a position and return the resulting FEN, game status, and move list.
| Name | Required | Description | Default |
|---|---|---|---|
| fen | No | Starting FEN. Omit for variant start position. | |
| moves | Yes | Moves in coordinate notation (e.g. ["e2e4", "e7e5", "g1f3"]). | |
| variant | No | Variant key. Defaults to "standard". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It mentions the tool returns a result but does not disclose error handling for illegal moves, the impact (if any) on external state, or authentication/rate limits. The read-only nature is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the purpose, followed by the outputs. No extraneous information; every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema), the description adequately covers the core functionality and return values (FEN, game status, move list). It could be improved by mentioning error behavior, but it is functionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage). The description adds value by providing examples for moves (coordinate notation), default for variant (standard), and usage note for fen (omit for variant start). This exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Play a sequence of moves from a position' and specifies the outputs: 'resulting FEN, game status, and move list.' This differentiates it well from siblings like chess_get_legal_moves or chess_validate_move, which focus on legality rather than simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing what the tool does, but it does not explicitly state when to use this tool versus alternatives (e.g., checking legality or analyzing positions). No when-not or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chess_validate_moveAInspect
Check whether a specific move is legal in the current position. Returns legal/illegal with explanation.
| Name | Required | Description | Default |
|---|---|---|---|
| fen | No | FEN string. Omit for starting position. | |
| move | Yes | Move in coordinate notation (e.g. "e2e4", "e7e8q" for promotion). | |
| variant | No | Variant key. Defaults to "standard". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the return behavior (legal/illegal with explanation), but does not explicitly state that the tool is read-only or non-destructive. The description is adequate but could be more transparent about side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and the output. Every word contributes value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple validation tool with three parameters and no output schema, the description is largely complete. It covers the primary function and output. Minor improvements could include more detail about error handling or the format of the explanation, but it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with clear descriptions (fen, move, variant). Since schema description coverage is 100%, the description does not add additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'check' and the resource 'whether a specific move is legal in the current position', making the purpose clear. It also mentions the output format ('Returns legal/illegal with explanation'), which differentiates it from sibling tools like chess_get_legal_moves that list all legal moves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use the tool: to validate a single move. However, it does not explicitly mention when not to use it or suggest alternatives like chess_get_legal_moves for getting all legal moves. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dice_rollAInspect
Roll dice using standard notation (e.g. "2d6+3", "4d8-1", "d20"). Supports any combination of dice, modifiers, and multiple pools.
| Name | Required | Description | Default |
|---|---|---|---|
| notation | Yes | Dice notation (e.g. "2d6+3", "4d8", "d20+5", "3d6"). Multiple pools separated by commas. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explains supported notation and combinations. Being a simple random roll, additional behavioral details are not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, one sentence with examples, no superfluous content. Front-loaded with action and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of output schema, description could state return format, but for a simple roll the current information is sufficient. Adequate for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers the notation parameter with description. Description adds value by showing examples and mentioning multiple pools, slightly exceeding baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes rolling dice with standard notation, provides examples. Clearly distinguishes from unrelated siblings like chess and hex tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples of notation and usage, but doesn't explicitly state when not to use or mention alternatives. However, siblings are unrelated so no need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hex_compute_fovAInspect
Compute field-of-view from a hex position: all hexes visible within a given range, respecting line-of-sight through the grid.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Axial q coordinate of the observer. | |
| r | Yes | Axial r coordinate of the observer. | |
| game | Yes | Game key. | |
| seed | No | Seed used to generate the map. | |
| size | No | Map size. | |
| range | No | Vision range in hex steps (default 3). | |
| layout | No | Layout variant. | |
| players | No | Player count. | |
| blocking | No | Terrain types that block line of sight (e.g. ["mount", "mountains"]). Defaults to none. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'respecting line-of-sight' but does not detail how blocking terrain is handled, nor does it clarify if the tool is read-only or has performance implications. The schema's blocking parameter is not referenced in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the key action. However, for a tool with 9 parameters and no output schema, a slightly more structured format (e.g., listing key parameters) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should hint at the return format (e.g., list of hex coordinates). It only says 'all hexes visible' without specifying structure. Additionally, behavioral traits (read-only, performance) are missing, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The tool's description adds little beyond what the schema provides—it does not clarify defaults (e.g., range default 3) or the syntax for blocking terrain. Thus, it adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Compute field-of-view' and the resource 'hex position', specifies the output 'all hexes visible within a given range', and mentions line-of-sight consideration, distinguishing it from sibling tools like hex_pathfind and hex_generate_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The usage is implied by the purpose, but alternatives are not named. For example, it would be helpful to note that hex_pathfind is for pathfinding, not visibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hex_export_svgBInspect
Export a generated hex map as an SVG string for rendering or embedding.
| Name | Required | Description | Default |
|---|---|---|---|
| game | Yes | Game key. | |
| seed | No | Seed used to generate the map. | |
| size | No | Map size. | |
| labels | No | Show terrain labels on hexes (default false). | |
| layout | No | Layout variant. | |
| bgColor | No | Background colour (e.g. "#1a1a2e"). Omit for transparent. | |
| hexSize | No | Hex radius in pixels (default from game config). | |
| players | No | Player count. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action and output, but fails to mention whether the operation is idempotent, requires authentication, or modifies state. No side effects or constraints are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the primary function. It is front-loaded with the verb and resource. However, it may be too terse, lacking details that could be included without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with 8 parameters and no output schema. It does not describe the return value (the SVG string) in detail, nor does it address error conditions or prerequisites. The context of usage (e.g., requiring a previously generated map) is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema; it only restates the purpose. No explanation of parameter relationships (e.g., seed must match a previously generated map) or default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Export', the resource 'a generated hex map', and the output 'SVG string for rendering or embedding'. It differentiates from sibling tools like hex_generate_map (which generates the map) and hex_pathfind (which computes paths).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that the map must be generated first via hex_generate_map, nor does it specify any prerequisites or best practices for selecting parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hex_generate_mapAInspect
Generate a hex map for a given game. Returns the full hex grid with terrain types, coordinates, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| game | Yes | Game key (e.g. "nukes", "colony", "twilight", "talisman", "mongo", "endless"). | |
| seed | No | Seed string for reproducible generation. Omit for a default seed. | |
| size | No | Map size (ring count). Meaning varies by game. Omit for the game default. | |
| layout | No | Layout variant (e.g. "standard", "expanded", "6p"). Only for games with multiple layouts. | |
| players | No | Player count. Omit or 0 for no player bases. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether generation is deterministic, requires authentication, or has side effects. Terms like 'generate' imply creation but lack details on idempotency or cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and output. Every word adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description must explain return value. It does so adequately: 'full hex grid with terrain types, coordinates, and metadata'. However, missing details like coordinate system or metadata structure, but sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds no extra meaning beyond 'for a given game'. Baseline 3 applies as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'generate' and resource 'hex map for a given game'. It clearly states output: full hex grid with terrain types, coordinates, and metadata. It distinguishes from sibling tools like hex_get_info (info retrieval) and hex_list_games (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for a given game') but does not explicitly state when to use this tool versus other hex tools like hex_pathfind or hex_export_svg. No when-not or alternatives are mentioned, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hex_get_infoAInspect
Get detailed information about a specific hex coordinate on a generated map: terrain type, neighbors, and distances to other hexes.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Axial q coordinate of the target hex. | |
| r | Yes | Axial r coordinate of the target hex. | |
| game | Yes | Game key. | |
| seed | No | Seed used to generate the map. | |
| size | No | Map size. | |
| layout | No | Layout variant. | |
| players | No | Player count. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the output (terrain, neighbors, distances) but omits behavioral traits like side effects, permissions, rate limits, or whether it's read-only. The description is straightforward but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded verb and resource. No wasted words; each phrase adds value. Efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema or annotations, the description covers the core purpose but lacks usage prerequisites (e.g., map must exist), behavioral context, and how parameters like seed/size relate. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all 7 parameters. The description does not add meaning beyond what the schema provides, so baseline 3 is appropriate. No parameter details are elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), resource ('hex coordinate on a generated map'), and explicitly lists returned info (terrain type, neighbors, distances), distinguishing it from sibling tools like hex_generate_map (generates) and hex_pathfind (pathfinding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing info about a specific hex but does not provide explicit guidance on when to use or avoid this tool, nor does it compare with alternatives like hex_pathfind or hex_compute_fov. Usage context is vaguely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hex_list_gamesAInspect
List all available hex map games with their map types, layouts, sizes, and style options.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only list operation with no side effects, and discloses the return content (map types, layouts, sizes, style options). With no annotations, this adequately covers behavioral expectations, though it could mention if results are exhaustive or paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose and key details. Every word earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently explains return values. However, for a list tool, it lacks mention of pagination, ordering, or whether the list is exhaustive, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (zero parameters), so baseline is 3. The description adds value by detailing the fields each game entry includes, going beyond the empty schema to inform the agent of expected properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list' and resource 'hex map games', specifying the exact information returned (map types, layouts, sizes, style options). This distinguishes it from siblings like hex_generate_map or hex_get_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives. While the purpose is clear, the description does not mention any prerequisites, exclusions, or comparisons to siblings, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hex_pathfindBInspect
Find the shortest path between two hexes on a generated map using breadth-first search. Optionally specify impassable terrain types.
| Name | Required | Description | Default |
|---|---|---|---|
| toQ | Yes | End hex axial q. | |
| toR | Yes | End hex axial r. | |
| game | Yes | Game key. | |
| seed | No | Seed used to generate the map. | |
| size | No | Map size. | |
| fromQ | Yes | Start hex axial q. | |
| fromR | Yes | Start hex axial r. | |
| layout | No | Layout variant. | |
| players | No | Player count. | |
| impassable | No | Terrain types that cannot be traversed (e.g. ["water", "mount"]). Defaults to none. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It mentions BFS and optional impassable terrains but fails to disclose output format, error handling (e.g., unreachable destination), or performance implications. Key behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no wasted words. It efficiently communicates the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and minimal schema descriptions, the description is too brief. It does not explain the axial coordinate system, the relationship between game/seed/size, or the return value (e.g., list of hex coordinates). The tool is complex but the description is simplistic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description adds no new parameter meaning beyond the schema's brief descriptions. The mention of impassable terrains aligns with the parameter but doesn't provide extra semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds the shortest path between two hexes using BFS, distinguishing it from sibling tools like hex_compute_fov. The verb 'find' and resource 'path between hexes' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when shortest path computation is needed on a generated map, but provides no explicit when-not or alternative tools. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ti4_random_factionsAInspect
Generate random faction assignments for a Twilight Imperium 4e game. Supports base game and Prophecy of Kings expansion.
| Name | Required | Description | Default |
|---|---|---|---|
| players | No | Number of players (3-8). Defaults to 6. | |
| expansion | No | Include Prophecy of Kings factions. Defaults to "pok". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states the tool generates assignments, which is straightforward. However, it does not disclose behavioral details such as randomness source, whether results are deterministic with a seed, or what happens for invalid player counts. For a simple random generator, this is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose, second adds scope. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not explain what the tool returns (e.g., a list of factions, assignments per player). Given its simplicity, it is mostly adequate, but the lack of output specification leaves ambiguity. Additional detail on return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already documented with defaults and allowed values. The description adds no new meaning beyond what the schema provides. According to rules, baseline is 3 when coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates random faction assignments for Twilight Imperium 4e, and specifies support for both base game and Prophecy of Kings expansion. It is specific with verb 'generate' and resource 'faction assignments', and distinguishes from sibling tools which are about chess or hex games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives. While sibling tools are all unrelated (chess, hex), the description does not provide context such as prerequisites (e.g., game setup needed) or when this tool is appropriate (e.g., for random draft, not pre-assigned games). The usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!