Manage Bet Codes

Split Bet Code Into 2–20 Codes

mbc_split_code

Divide one booking code into 2 to 20 smaller codes on the same bookmaker so every game lands in exactly one new code. Supports 4 split methods: 'equal' (spread games evenly across codes), 'by_batches' (keep consecutive games together in each code), 'target_odds' (group games to reach a chosen combined odds per code), and 'custom' (set exact game counts per output code). Supports 2 game orders: 'mixed' (keep original slip order) and 'by_start_time' (earliest games first, latest games last). Costs 2 credits plus 1 credit per extra created code; unused parts are refunded.

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>",
      "bookmaker": "<bookmaker>"
    },
    "name": "mbc_split_code"
  }
}

Input Schema

Name	Required	Description
`code`	Yes	Booking code to split.
`count`	No	Number of output codes (2 to 20) when method is 'equal' or 'by_batches'.
`order`	No	Game order: 'mixed' (original slip order) or 'by_start_time' (sorted by kickoff).
`counts`	No	Exact game count for each output code (must sum to total games on the slip) when method is 'custom'.
`method`	No	Split method: 'equal', 'by_batches', 'target_odds', or 'custom' (default 'equal').
`bookmaker`	Yes	Bookmaker key or alias (e.g. 'sportybet', 'bet9ja', '1xng', 'msport').
`target_odds`	No	Target combined odds per output code (e.g. 5.0) when method is 'target_odds'.

Output Schema

Name	Required	Description	Default
`parts`	No
`billing`	No
`success`	No
`new_codes`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (which only say non-read-only, non-idempotent, open-world), the description discloses the credit cost model, the per-extra-code surcharge, and the refund policy for unused parts — exactly the operational facts an agent needs before spending a user's credits. It also states the partition invariant and the same-bookmaker constraint, which are behavioral guarantees not present in the schema.

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

Conciseness4/5

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

The core action and its bounds are front-loaded in the first sentence, followed by method and order semantics, then cost. It is dense and every sentence carries information, though the method/order enumeration is long enough that it reads as a packed block rather than a scannable structure.

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?

With an output schema available, return values need not be described, and the definition covers action, constraints, modes, and pricing. The remaining gap is what happens to the source code after splitting (retained, invalidated, or consumed) and whether credits are refunded on failure — relevant for a non-idempotent write tool.

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 coverage is 100%, so the baseline is 3; the description earns above that by explaining the intent of each enum value, notably 'by_batches' (keep consecutive games together) and 'target_odds' (group games to reach a chosen combined odds), which the schema only names. It also clarifies that 'mixed' preserves original slip order rather than randomizing, resolving an ambiguity in the enum label.

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 ('Divide one booking code into 2 to 20 smaller codes') and immediately bounds scope with 'on the same bookmaker' and the invariant 'every game lands in exactly one new code'. That invariant alone distinguishes it from a merge or convert operation, so an agent can identify the tool without opening the schema.

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?

It establishes a clear context for use (partitioning a slip into smaller slips) and gives per-mode guidance on which split method and game order to pick, which is effectively when-to-use guidance at the mode level. It stops short of naming alternatives such as mbc_merge_codes or mbc_convert_code, or stating exclusions like 'not for changing bookmakers'.

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

All Manage Bet Codes tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?