esoccer-battle-mcp

Overview Schema Source Related Servers Discussions Admin

Test Rule

test_rule

Read-only

Back-test a custom pre-match rule on point-in-time match data to get hit rate, break-even odds, and a baseline comparison for stability.

Instructions

Back-test the user's own rule on all data, point-in-time: for every match that passes the filters, features are computed ONLY from matches played before it, then the conditions decide if the rule fires and the market outcome is checked. Returns hit rate, break-even odds (1 / hit rate) and a baseline (the same market without the conditions) plus a split for stability. There are no odds in the data: tell the user to compare break_even_odds with their bookmaker's odds, and flag samples under ~50 as unreliable.

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": {
      "market": "<market>",
      "pick": "<pick>",
      "conditions": "<conditions>"
    },
    "name": "test_rule"
  }
}

Input Schema

Name	Required	Description	Default
`era`	No	'current' (default), 'all', or an era id such as 'FC26'	current
`line`	No	Total-goals line, required for over_under
`pick`	Yes	over/under (over_under), yes/no (btts), home/draw/away (1x2; home = p1)
`since`	No	First Battle day to include, YYYY-MM-DD
`until`	No	Last Battle day to include, YYYY-MM-DD
`venue`	No	Stamford Bridge, Old Trafford, Wembley, San Siro, Bernabeu (8 min) or Anfield, Etihad (12 min)
`format`	No	Match length
`market`	Yes
`player`	No	Only this player's matches; p1 is always this player
`turnus`	No	Block number within the Battle day (1-11 for 8 min, 1-8 for Latest/12 min)
`session`	No	Session, derived from the turnus
`time_to`	No	Latest local kick-off time HH:MM
`group_by`	No		month
`last_days`	No	Only the last N Battle days (overrides since)
`time_from`	No	Earliest local kick-off time HH:MM (window may wrap midnight)
`conditions`	Yes	Pre-match conditions, all must hold
`min_history`	No	Skip a match if a feature has fewer earlier matches
`history_scope`	No	Which earlier matches feed the features	all

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Nov 2, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The description discloses behavior well beyond the annotations: it explains point-in-time feature computation, that conditions are ANDed, the returned hit rate, break-even odds, baseline, and stability split, and that there are no odds in the data. These details help the agent understand the tool's output and limitations. The annotations already mark it as read-only and closed-world, and the description is consistent with them.

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 core action and then adds only high-value operational details. Every sentence earns its place by clarifying the computation model, return values, or interpretation caveats. There is no redundant or filler text.

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 complexity, 18 parameters, and the existence of an output schema, the description is complete enough for an agent to call it correctly. It explains the point-in-time computation, AND semantics of conditions, return values, and a critical caveat about missing odds and small samples. No essential calling context is missing.

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 description coverage is 89%, so the schema already documents nearly all parameters. The description reinforces the point-in-time semantics of conditions and features but does not add substantial parameter-level meaning beyond the schema. A baseline 3 is appropriate when schema coverage is high and the description does not compensate with additional parameter syntax or constraints.

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 verb and resource: 'Back-test the user's own rule on all data, point-in-time.' It clearly describes the backtesting scope and computation model. However, it does not explicitly differentiate this tool from sibling tools such as query_matches, market_stats, or player_form, so it falls short of the top score.

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 use case is implied: back-test a user-defined rule against historical data. The description adds useful operational guidance about comparing break_even_odds with bookmaker odds and flagging small samples. It does not say when to use this tool versus alternatives like market_stats or query_matches, nor does it name any exclusions.

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

Deploy Server