Skip to main content
Glama
Sign In
esoccer-battle-mcp

esoccer-battle-mcp

by Jhanee01
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Market Stats

market_stats
Read-only

Compute hit rates for over/under, BTTS, or 1X2 markets across players, pairs, teams, venues, and periods, with filters and optional grouping by venue, session, month, week, or opponent.

Instructions

Hit rates of a market (over/under a line, both teams to score, 1X2) for a player, a pair, a team, or simply everything matching the filters (e.g. a whole venue or turnus), optionally split by venue, session, turnus, month, week or opponent. Without a subject 'home' means player1.

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>"
    },
    "name": "market_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault
eraNo'current' (default), 'all', or an era id such as 'FC26'current
lineNoTotal-goals line for over_under, e.g. 6.5. Omit to get every line (only without group_by)
teamNoSubject team: only its matches, 'home' = its side
sinceNoFirst Battle day to include, YYYY-MM-DD
untilNoLast Battle day to include, YYYY-MM-DD
venueNoStamford Bridge, Old Trafford, Wembley, San Siro, Bernabeu (8 min) or Anfield, Etihad (12 min)
formatNoMatch length
marketYesMarket to measure
playerNoSubject player: only their matches, 'home' = their side
turnusNoBlock number within the Battle day (1-11 for 8 min, 1-8 for Latest/12 min)
sessionNoSession, derived from the turnus
time_toNoLatest local kick-off time HH:MM
group_byNonone
opponentNoRestrict to matches against this player/team
last_daysNoOnly the last N Battle days (overrides since)
time_fromNoEarliest local kick-off time HH:MM (window may wrap midnight)
min_sampleNoDrop groups smaller than this

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuine semantic rule ('home' defaults to player1 when no subject is given), but says nothing about how results are aggregated, what happens with sparse samples, or the shape of the response — the latter partly covered by the output 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?

Two sentences, front-loaded with the core purpose and followed by the scoping/grouping detail. Dense but every clause carries information; the parenthetical examples are slightly verbose but aid interpretation.

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 17-parameter read-only aggregation tool with full schema descriptions and an output schema, the description covers the essential conceptual model (what is measured, what the subject is, how results can be split) and the one non-obvious default. Remaining details live in the schema.

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 94%, so baseline is 3, but the description adds real value beyond it: it explains the subject model (player, pair, team, or none) and enumerates the grouping dimensions, which compensates for group_by having no schema description. The 'home' convention for subject parameters is clarified here and nowhere else.

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?

States a specific verb+resource: computes hit rates for a given market (over/under, BTTS, 1X2). It also scopes the subject (player, pair, team, or everything) and the optional splits, which is enough to separate it from siblings like player_form or player_h2h, though no sibling is named explicitly.

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 description of what can be measured and by the note that 'without a subject home means player1', but there is no explicit when-to-use guidance or exclusion versus query_matches, player_form or player_h2h. An agent must infer the choice from the purpose statement alone.

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

Deploy Server

Other Tools