Skip to main content
Glama
esoccer-battle-mcp
by Jhanee01

Query Matches

query_matches
Read-only

Retrieve raw esoccer match rows with filters for player, team, date, venue, format, and session when aggregate tools cannot answer the question directly.

Instructions

Raw match rows. Use when the other tools do not answer the question directly; for aggregates prefer player_h2h, team_h2h, market_stats or player_form.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "query_matches"
  }
}

Input Schema

NameRequiredDescriptionDefault
eraNo'current' (default), 'all', or an era id such as 'FC26'current
teamNoTeam name (either side)
limitNoMax rows, up to 500
orderNonewest
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
playerNoPlayer nickname (either 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
opponentNoOpponent player (with player) or team (with team)
last_daysNoOnly the last N Battle days (overrides since)
time_fromNoEarliest local kick-off time HH:MM (window may wrap midnight)

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?

readOnlyHint=true and openWorldHint=false already tell the agent this is a safe, closed-world read, so the description's main added value is that rows are raw/unaggregated. It says nothing about result volume, the default 100-row cap versus the 500 max, or whether truncation occurs silently — useful context for a 15-filter query 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?

Two short sentences, zero padding, with the core identification ("raw match rows") front-loaded before the routing advice. Nothing could be cut without losing information.

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?

An output schema exists and the input schema is well documented, so the description does not need to explain return values or parameters. What it omits is the one thing structured fields cannot convey: how this differs from export_matches and how the many filters combine (e.g. opponent's dependence on player/team).

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 93% and the schema already documents every filter, including defaults, enums and date formats. The description adds no parameter meaning beyond that, so the baseline of 3 applies — it neither compensates nor detracts.

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?

"Raw match rows" names the resource and implicitly the operation (return unaggregated rows), which is enough for an agent to know what comes back. It also contrasts itself against aggregate siblings, though the noun phrase is terse and never states a verb or that filtering is supported. Clear but slightly elliptical.

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?

Explicitly states the trigger condition ("use when the other tools do not answer the question directly") and routes aggregate needs to four named alternatives (player_h2h, team_h2h, market_stats, player_form). It does not, however, distinguish itself from export_matches, the other raw-match sibling, leaving one routing ambiguity.

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