esoccer-battle-mcp

Overview Schema Source Related Servers Discussions Admin

Team H2H

team_h2h

Read-only

Retrieve head-to-head records and statistics between two teams, regardless of who controlled them, with filters for era, date range, venue, format, and recent meetings.

Instructions

Head-to-head record of two teams regardless of who controlled them (player names are shown in last_matches). Same statistics as player_h2h. Note: in some leagues players are bound to teams for a period (see data_notes), then team stats effectively measure the player.

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": {
      "team_a": "<team_a>",
      "team_b": "<team_b>"
    },
    "name": "team_h2h"
  }
}

Input Schema

Name	Required	Description	Default
`era`	No	'current' (default), 'all', or an era id such as 'FC26'	current
`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
`last_n`	No	Use the most recent N meetings
`team_a`	Yes	First team name
`team_b`	Yes	Second team name
`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
`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)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Nov 2, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds genuinely new context by noting that player names appear in last_matches and that in some leagues players are bound to teams, making team stats effectively player stats, with a pointer to data_notes. This is interpretive behavior disclosure that the annotations cannot carry.

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?

Three sentences, front-loaded with the core purpose before the sibling reference and the caveat. No filler; the parenthetical and the data_notes pointer each carry information an agent would otherwise have to guess.

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 13 parameters, full schema coverage, an output schema and read-only annotations, the description's job is mainly disambiguation and interpretation, both of which it handles. Only the absence of explicit routing versus player_h2h keeps it from being fully complete.

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 100% across 13 parameters, so the schema fully documents era, since/until, venue, turnus, session and the rest. The description adds no syntax, defaults or interaction rules (e.g. last_days overriding since) beyond what the schema already states, so baseline 3 applies.

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?

"Head-to-head record of two teams" states a specific resource and scope, and the qualifier "regardless of who controlled them" signals the team-level aggregation that separates it from player-level stats. It names player_h2h as its analogue, so an agent can place it, though it never says plainly which one to pick.

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?

"Same statistics as player_h2h" implies the alternative but gives no explicit condition for choosing between them. The league-binding note is a caveat about interpreting results, not a when-to-use rule, so the routing guidance remains inferred.

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

Deploy Server