bb-gnubg-mcp

by hbomze

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
The four board/position conversion tools (board_from_position_id, position_id, key_of_board, board_from_position_key) are clearly paired but could be misselected due to similar naming. Other tools like best_move vs pub_best_move and rollout vs cubeful_rollout are distinct but share comparable names, though descriptions help.
Naming Consistency3/5
Tool names use a mix of conventions: verb_noun (get_constants), noun phrases (best_move, probabilities), and abbreviations (bearoff_id_2_pos, pub_eval_score). No consistent verb pattern is present, but names are descriptive and readable.
Tool Count3/5
With 18 tools, the server is on the heavy side, exceeding the typical 3-15 well-scoped range. However, each tool serves a distinct backgammon analysis function, so the count is justified by the broad domain.
Completeness5/5
The tool set covers position representation, evaluation, move generation, rollouts, bearoff, and match equity—a complete lifecycle for backgammon analysis. There are no obvious dead ends or missing critical operations.
Average 4/5 across 18 of 18 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions the return type (dict with 6-point position) but leaves the list input behavior unexplained. The dual input types (integer vs list) create a significant ambiguity: does a list get converted to an ID, or returned as a position tuple? No error handling or edge cases 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a one-sentence summary followed by an args/returns block. It is appropriately sized, though the ambiguity around the list input could be resolved with one additional clarifying clause without bloating the text.
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?
The tool is simple, but the description lacks completeness due to the unclear handling of the 6-element list input. The presence of an output schema reduces the need to detail return values, but the input behavior is not fully specified, and no usage context is provided. This is a notable gap for an agent to invoke the tool correctly.
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 0%, so the description is the only source of parameter meaning. It adds that the list must have 6 elements, but does not explain what those elements represent, how they relate to the integer ID, or what range/format the integer should take. The added constraint is helpful but incomplete.
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 states a clear verb and resource: 'Convert a bearoff ID to a 6-point position tuple.' However, the input schema allows a 6-element list, which the description does not reconcile with the stated purpose, introducing ambiguity about whether the tool also converts positions to bearoff IDs or handles lists differently.
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 compared to siblings like bearoff_probabilities or position_id. There are no usage contexts, exclusions, or alternatives mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior on its own. It mentions the return type but leaves key ambiguities: 'N moves' is undefined (no parameter for N), and the '6-element list' format is unexplained. No error behavior or context is provided.
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?
The description is concise and structured with Args/Returns. It avoids filler but introduces the unexplained 'N', which slightly detracts. Overall efficient.
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?
The tool is simple and an output schema exists, but the description leaves gaps: 'N moves' is undefined, the list format is unclear, and there is no usage context. It is adequate but not thorough.
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 0%, so description compensation is needed. The description adds that bearoff_id is either an integer ID or a 6-element list, which provides more than the bare schema type. However, it does not explain what the integer represents or what the list elements mean, leaving the parameter only partially specified.
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 states a specific action ('Get the probability distribution of bearing off') with a clear resource. It does not explicitly differentiate from sibling tools like 'probabilities' or 'bearoff_id_2_pos', but the bearing-off scope is unambiguous.
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?
There is no guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or use cases are mentioned; the description simply states what the tool does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, mention any side effects, or disclose limitations such as stochastic behavior. While the presence of a 'seed' parameter hints at reproducibility, the description does not explicitly explain that results may vary across rollouts or that different evaluation modes have different determinism.
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 well-structured with a clear purpose line, followed by Args and Returns sections. It is concise, with no redundant sentences. Every line adds value, and the docstring format is easy to scan.
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?
The description covers all parameters and returns, but it leaves gaps. The 'evaluation_mode' options are listed without any explanation of trade-offs or suitability. Phrases like 'any supported format' for board_input are vague, and the description does not clarify the meaning of the output probabilities. Given the tool's complexity (7 params) and lack of annotations, more context is needed for full completeness.
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 schema has 0% coverage, so the description must compensate. It does so by providing a brief explanation for each of the 7 parameters, including conditions (e.g., 'player required if board_input is a boardState dict'), defaults (nr=1296, evaluation_mode='prune'), and the structure for 'score' and 'cube'. This adds meaning well beyond the bare type definitions.
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 starts with a specific verb and resource: 'Calculate win/gammon/backgammon probabilities for a position.' This clearly states what the tool does. It does not explicitly distinguish from sibling tools like 'bearoff_probabilities', but the general scope is clear from the phrase 'for a position'.
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 is provided on when to use this tool versus alternatives. The description lacks any 'when to use' or 'use this instead of X' statements. The evaluation_mode list gives options but does not explain when each is appropriate, leaving the agent to infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the conversion behavior and the conditional requirement for 'player.' However, it does not disclose potential error cases, format limitations, or other behavioral traits. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-sentence summary followed by an Args section and a Returns section. Every line adds value, and the structure is easy to scan. No wasted words.
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?
For a simple conversion tool, the description covers the essential aspects: input format, player condition, and return value. The presence of an output schema reduces the need to detail the return structure. It doesn't enumerate supported formats, but that's a minor gap 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?
With 0% schema description coverage, the description adds meaning beyond raw types: board_input is 'a board in any supported format,' and player is 'who is on roll' with a note that it's required for boardState dicts. This compensates well, though it could elaborate on what formats are supported.
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 tool's function: 'Convert a board to its GNUBG position key string.' This specifies the verb (convert) and resource (board to position key). It doesn't explicitly distinguish from sibling tools like board_from_position_key, but the direction is clear, so it earns a 4 rather than 5.
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?
The description implies usage: if you need a key string from a board, use this tool. It provides a specific condition for the 'player' parameter ('Required if board_input is a boardState dict'), but does not explicitly discuss alternatives or when not to use the tool. This meets the minimum viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral info. It discloses the return structure (2x25 board array, position ID, key) and the input type, which covers the essential behaviour of this conversion tool. However, it doesn't mention error handling or validation of the key.
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?
The description is concise and structured with 'Args' and 'Returns' sections. The main sentence is clear, but the Args section is somewhat redundant with the schema and main text, though it adds a minor clarification.
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 that an output schema exists, the description appropriately focuses on the conversion logic and output fields. It sufficiently covers the tool's purpose and return values, but omits any error conditions, which are not critical for a simple converter.
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?
The schema has one parameter with no description coverage, so the description must compensate. The 'Args' section merely restates 'A GNUBG position key string,' adding little beyond the parameter name. It doesn't provide format examples or constraints.
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 'Convert a GNUBG position key string to a board representation,' identifying the specific input and output. This distinguishes it from the sibling 'board_from_position_id' which uses a different input format.
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?
The description does not explicitly mention when to use this tool over alternatives, but the conversion from a key is implied. It lacks explicit guidance on when not to use it or which sibling to choose for other input types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It states that the tool returns a dict with MWC but does not explicitly mention that it is a read-only operation, any side effects, or edge-case behavior for invalid score values. The verb 'look up' hints at read-only nature but is not explicit.
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 compact and well-structured, with a one-sentence purpose followed by Args and Returns sections. Every word is purposeful, and the format is easy to scan for both parameter semantics and return value.
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?
For a simple lookup tool, the description covers the essential aspects: purpose, both parameters with ranges, and the return type. Since an output schema exists, detailed return documentation is not required. However, it omits any mention of error handling or invalid input behavior, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions for its two integer parameters (schema description coverage is 0%). The description fully compensates by explaining the meaning of both parameters: x_away is points player X needs to win (0-25) and o_away is points player O needs to win (0-25), including valid ranges.
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 opens with a specific verb 'Look up' and a clear resource 'match equity' given a match score, making its purpose immediately obvious. It distinguishes itself from sibling tools by focusing on match winning chance (MWC) for a player, which is a distinct concept from general probabilities or rollout results.
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?
The description implies usage for computing match equity from a match score, but it does not explicitly state when to prefer this tool over alternatives like 'probabilities' or 'cubeful_rollout'. It provides clear input context but lacks exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the responsibility for behavioral disclosure. It transparently describes the return value as a dict with a 2x25 board array and the position ID, giving insight into what to expect. However, it does not mention potential error handling or validation behavior, which is a minor gap for a conversion tool.
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 concise and well-structured: a one-sentence summary followed by Args and Returns sections. Every sentence contributes meaning without waste, and the format is easy to parse for an AI agent.
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 the tool's simplicity (one parameter, straightforward conversion), the description is largely complete. It explains the input, output, and even the return structure. The only missing element is contextual guidance about when to use this over other conversion tools, but that is already factored into the usage guidelines dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines the parameter as a string, providing zero description. The description compensates fully by stating the parameter is a 14-character GNUBG Position ID and providing a concrete example ('4HPwATDgc/ABMA'). This gives the agent all necessary information to supply a valid input.
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's function: converting a 14-character GNUBG Position ID to a board representation. It specifies the exact resource (GNUBG Position ID) and the output (board representation), which distinguishes it from sibling tools like board_from_position_key that likely handle a different format.
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 provides no guidance on when to use this tool versus alternatives such as board_from_position_key or position_id. It only describes what the tool does, not the circumstances that would make it the appropriate choice, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It mentions the return format (dict with notation, steps, position key) and accepts multiple board formats, which is useful. However, it does not comment on side effects (e.g., whether the board is mutated), error handling, or edge cases like no legal moves. The description is adequate but not deeply 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 efficiently structured with a one-line summary followed by Args and Returns sections. Every sentence provides necessary information without redundancy or filler. It is concise while delivering complete parameter and return documentation.
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 the tool's complexity (backgammon move generation), the description covers the input formats, dice roll specification, player default, and return structure. It lacks only minor behavioral details such as handling of invalid dice or no-legal-move scenarios, but overall it is sufficiently complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the tool description compensates fully with an Args section explaining board_input (any supported format), dice (as [die1, die2], each 1-6), and player (x/o, default 'x'). This adds significant meaning beyond the bare schema and leaves no parameter vague.
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 'Generate all legal moves for a board and dice roll' with a specific verb and resource. It distinguishes itself from siblings like 'best_move' (which focuses on selecting a move) and 'roll' (which simulates dice), making the tool's purpose unambiguous.
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?
The description explains what the tool does but does not explicitly state when to use it over alternatives or provide exclusions. While the context of 'moves' alongside siblings implies it is for move enumeration, there is no direct comparison to 'best_move' or other tools, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose the return shape ('Dict with equity and standard deviation') and the null-if-unsupported behavior, which is helpful. But it does not explain what 'unsupported' means, how equity relates to win probability, or any assumptions/error behavior.
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 compact and well-structured with clear Args and Returns sections. Every sentence adds necessary information without filler.
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?
For a tool with one parameter and an existing output schema, the description covers the key input and return behavior. It could be slightly more complete by clarifying the unsupported condition and what 'equity' means, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says 'pips' is an integer, but the description adds meaningful semantics: 'Number of pips remaining to bear off a single checker.' This fully compensates for the 0% schema description coverage.
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 opens with a specific verb and resource: 'Estimate win probability for a one-checker bearoff race.' This precisely defines the tool's function and differentiates it from general bearoff tools like bearoff_probabilities and probabilities.
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?
Usage is implied by the phrase 'for a one-checker bearoff race,' which tells the agent when this tool is relevant. However, there is no explicit comparison to sibling tools, no 'when not to use,' and no alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states the action (simulate) and the exact return structure (dict with die1 and die2, each 1-6). This is sufficient for a simple, side-effect-free tool, though it does not explicitly mention randomness.
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 two sentences, immediately states the action, and includes the return format. There is no extraneous information, making it highly concise and well-structured.
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 the tool's simplicity (no parameters, deterministic return shape) and the existence of an output schema, the description fully covers the necessary context. It specifies exactly what is returned, leaving little room for ambiguity.
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 tool has zero parameters and the schema is empty, so the baseline for 0-parameter tools is 4. The description adds relevant return semantics beyond the schema, though no parameter explanations are needed.
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 simulates a roll of two six-sided dice, with a specific verb and resource. It is distinct from sibling tools like 'rollout' and 'cubeful_rollout', which refer to deeper simulation processes.
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 provides no guidance on when to use this tool versus alternatives. It does not mention that this is for a simple random dice roll as opposed to rollout or other sampling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the calculation method (Monte Carlo), the return format (dict with probabilities and std devs), and the RNG seed for reproducibility. However, it does not explicitly state that the operation is read-only or free of side effects, which is important in the absence of annotations.
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 well-structured: a one-line summary, followed by a clear Args list and Returns section. Every sentence adds value, and the organization makes it easy to scan. It is appropriately sized for a tool with 8 parameters.
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 the complexity (8 parameters, no annotations), the description covers all parameters and the return type. However, some parameter descriptions are terse (e.g., 'cube state dict' and 'rollout_type' options are listed but not explained in detail). Still, with an output schema, the return values need not be described further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description provides a detailed Args section explaining every parameter, including defaults and valid options (e.g., 'player': Who is on roll, 'ngames': default 1296, 'score': match score format). This fully compensates for the schema's lack of descriptions.
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 'Perform a cubeless Monte Carlo rollout of a position' with a specific verb and resource. It distinguishes itself from sibling tools by specifying 'cubeless', which contrasts with the sibling 'cubeful_rollout'.
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?
The description implies when to use the tool via the term 'cubeless', but it does not explicitly say 'use this instead of cubeful_rollout for cubeless analysis' nor mention any conditions or alternatives. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It states the evaluation type and return format ('Dict with move as from/to pairs and notation'), but does not discuss error handling, non-determinism, or limitations such as lower accuracy relative to neural evaluation. It adds minimal behavioral context beyond the tool name and 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?
The description is brief and front-loaded: the first sentence states the purpose, followed by a clean Args/Returns structure. Every line carries necessary information without redundancy.
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?
For a simple computation tool with an output schema, the description covers purpose, parameters, and return type. It lacks explicit usage differentiation and edge-case handling, but overall provides a solid foundation.
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?
With 0% schema coverage, the description compensates by documenting all three parameters: board_input's flexible format, dice's exact structure with range 1-6, and player's default value 'x'. It adds meaning to the bare type definitions, though 'any supported format' remains vague.
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's function with a specific verb ('Find the best move') and identifies the evaluation method ('GNUBG's public (non-neural, fast) evaluation'), distinguishing it from the sibling tools like 'best_move' which likely uses neural evaluation.
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 gives context that this is the 'public (non-neural, fast)' evaluation, implying it is the speed-oriented alternative. However, it does not explicitly name alternatives or provide when-to-use/when-not-to-use guidance, so it provides clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions the neural network evaluation method, the trade-off for ply depth, seed for reproducibility (implying potential randomness), and outlines the return structure including alternatives with probabilities. This adds meaningful context beyond the schema, though it doesn't explicitly state side-effect-free behavior or error conditions.
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 efficiently structured: a one-sentence purpose, a clean Args list, and a Returns line. Every sentence adds value, and the front-loaded first sentence immediately tells the agent what the tool does. The format is easy to parse and not padded.
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?
For a tool with 7 parameters, no annotations, but an output schema, the description is complete. It covers purpose, all parameter semantics, and a high-level return description (leaving detailed return parsing to the output schema). The only gap is explicit sibling differentiation, but that is a minor omission given the clear purpose and parameter detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. The Args section explains each of the 7 parameters: board_input accepts any supported format, dice format, player default, ply meaning, match score context, cube state structure, and seed purpose. This adds rich semantic meaning beyond the plain schema types and defaults.
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 opens with a specific action and resource: 'Find the best move for a position and dice roll using neural network evaluation.' This precisely states what the tool does and distinguishes it from siblings like pub_best_move or moves by focusing on the best-move computation. The 'Returns' section further clarifies the output, reinforcing purpose clarity.
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?
The description provides context for parameter choices (e.g., 'ply: Higher is stronger but slower', 'score: Omit for money game') but does not explicitly state when to use this tool over siblings like pub_best_move or when to avoid it. The usage is implied through the tool's purpose rather than explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the player parameter is conditionally required for boardState dicts and describes the return format (dict with name and numeric code). This goes beyond a minimal description and gives useful behavioral context.
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 concise and well-structured with an Args and Returns section. Every sentence provides necessary information, and the list of classifications is directly useful. No wasted words.
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 description gives a complete picture of the tool's input requirements, output structure, and possible classification values. It does not dwell on edge cases or invalid inputs, but for a straightforward classification tool with an output schema, this is sufficient completeness.
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 description coverage is 0%, so the description compensates well. It explains board_input as 'Board in any supported format' and player as 'Who is on roll' with the condition for when it's required. This adds meaning beyond the raw schema, though the term 'supported format' could be more explicit.
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 a specific action ('Classify a board position') and resource (GNUBG's position types), listing the exact classification categories. This distinguishes it from sibling tools like probabilities or best_move, which serve different purposes.
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 provides clear context for when to use the tool by explaining its function and listing the classification outputs. It does not explicitly mention alternative tools or when not to use it, but the purpose is self-evident enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the sign convention ('Positive favors the mover, negative favors opponent'), the required player condition for dict board inputs, and supported input formats. It does not exhaustively describe errors or side effects, but none are expected for a pure scoring function.
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 compact and front-loaded with a one-sentence summary, followed by a terse Args/Returns block. Every line adds unique information; there is no repetition of schema fields or annotation data.
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 the simple two-parameter schema and the presence of an output schema, the description covers purpose, parameters, and result sign. The only notable gap is lack of explicit guidance on alternatives, though 'fast heuristic' implies the usage context. This is sufficient for an agent to invoke the tool correctly.
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 schema has no property descriptions (0% coverage), so the description compensates by explaining that board_input accepts 'any supported format' and that player is required if board_input is a boardState dict. It stops short of enumerating all supported formats or explaining player optionality for non-dict inputs, but adds meaningful semantics beyond the raw 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 opens with 'Compute a fast heuristic evaluation score using GNUBG's public (non-neural) model' — a specific verb with a clear resource. This distinguishes it from sibling tools like best_move, moves, and equities_value by naming the evaluation model and heuristic nature.
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 phrase 'fast heuristic' clearly signals when this tool is appropriate, implying quick evaluation rather than full rollout. It does not explicitly name alternative tools or when-not-to-use scenarios, but the provided context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions simulation count (ngames), reproducibility (seed), and the return of detailed statistics including cubeful equity. It does not mention performance cost or failure modes, but for a computation tool the main behavioral aspects are reasonably covered.
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 well-structured with an Arg list and Returns section. Each line provides meaningful information without verbosity. The 'Board in any supported format' phrase is a bit vague, but overall every sentence 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?
Given the tool's complexity and 7 parameters, the description covers all parameters and the return value, which is sufficient for basic usage. It does not detail supported board formats or explicitly discuss alternative tools, but with an output schema present and all inputs documented, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates fully by explaining every parameter: board_input format flexibility, player on roll, ngames default and configurability, ply depth, match score semantics, cube state dict, and seed purpose. This adds meaning far beyond the raw 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 opens with a specific verb and resource: 'Perform a cubeful rollout with doubling cube handling.' This clearly distinguishes it from sibling tools like 'rollout' by emphasizing the cubeful/doubling-cube aspect, making the tool's purpose unambiguous.
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 clearly identifies context for use: cases involving the doubling cube and cubeful equity. It does not explicitly name alternatives or say when not to use, but the cubeful phrasing and the existence of sibling 'rollout' imply differentiation. Slight room for explicit 'use plain rollout for cubeless' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly discloses the return structure (a dict with position_classes, evaluation_modes, and rollout_types) and its role in supplying values to other tools. Being a no-argument getter, the behavior is fully transparent; there are no side effects or hidden complexities.
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 short sentences: purpose, return value, and usage. It is front-loaded with the main purpose, every sentence adds value, and there is no redundant or verbose content.
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 the simplicity of a zero-parameter constant lookup with an output schema, the description is fully complete. It explains what the tool returns, that the values are used by other tools, and how to apply those values. An agent can confidently leverage this tool without further clarification.
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 tool has zero parameters, so the baseline is 4. The description adds useful context about the output, but there are no parameter semantics to explain. The schema already reflects no parameters, so no additional info is required.
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 states exactly what the tool does: 'Get all GNUBG constant values used by other tools.' This clearly identifies the verb (get), resource (constant values), and scope (all GNUBG constants). It distinguishes the tool from siblings by focusing on constants rather than operations like classify or rollout.
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 says 'Use these string names as parameter values in other tools,' which tells the agent when to use this tool: to obtain valid enum values for other tools. It stops short of stating when not to use it or naming alternatives, but since it is the only constant-retrieval tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It discloses accepted input formats, the player condition, and the return value structure. It does not discuss error handling, but for a pure conversion operation this is adequate.
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 front-loaded with the purpose and uses a clean docstring structure with Args and Returns sections. Every sentence adds value without redundancy.
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 is simple with two parameters and an output schema. The description covers the main inputs, requirements, and return format. Minor gaps include not clarifying behavior when a Position ID string is passed as input or not referencing related conversion tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains both parameters: board_input lists the three supported formats, and player specifies 'x' or 'o' and when it is required. This fully compensates for the lacking schema information.
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 converts a board to a 14-character GNUBG Position ID, using a specific verb and resource. This differentiates it from the sibling tool board_from_position_id, which performs the reverse transformation.
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 gives clear context on when to use the tool (when a position ID is needed) and specifies when the player parameter is required. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bb-gnubg-api-mcp MCP server](https://glama.ai/mcp/servers/hbomze/bb-gnubg-api-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hbomze/bb-gnubg-api-mcp)

Score Badge

Copy to your README.md:

[![bb-gnubg-api-mcp MCP server](https://glama.ai/mcp/servers/hbomze/bb-gnubg-api-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hbomze/bb-gnubg-api-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/hbomze/bb-gnubg-api-mcp'

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