SportIQ

cricket_head_to_head

Read-onlyIdempotent

Compare two cricket teams head-to-head using squad form and player stats to estimate win probabilities, key players, and historical win rates.

Instructions

Compare two cricket teams head-to-head using squad form and player stats.

Args: team_a: First team code or name (e.g. "MI", "India"). team_b: Second team code or name (e.g. "CSK", "Australia").

Returns: data: {team_a, team_b, team_a_edge_count, team_b_edge_count, key_players_a, key_players_b, h2h_win_rate_a, h2h_win_rate_b, win_prob_a, win_prob_b}. meta.estimated: true. meta.estimate_quality: "uninformative" when no player stats were available (both sides at default form), else "player_stats".

Input Schema

Name	Required	Description	Default
`team_a`	Yes	First team code or name (e.g. "MI", "India").
`team_b`	Yes	Second team code or name (e.g. "CSK", "Australia").

Output Schema

Name	Required	Description	Default
`data`	No
`meta`	No
`error`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Jul 10, 2026

TDQS

A3.9/5.0

Behavior5/5

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

The description goes beyond simple input/output by detailing the meta-data nature of the results, specifically 'meta.estimated' and the conditional 'estimate_quality' field. This is crucial behavioral context that tells an agent when the data is reliable (i.e., when player stats are missing).

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

Conciseness3/5

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

While the core concept is concise, the description is structurally compromised by including the literal input arguments and return schema structure within the free-text description. This makes the description dense and less readily digestible for an AI agent.

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 output structure, the description is highly complete. It not only covers the inputs and the primary goal but also explicitly defines the quality and estimated nature of the return values, which is essential for agent reasoning.

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?

Since the schema coverage is 100%, the structured data fully describes the parameters. The description provides no semantic information regarding the arguments that is not already covered in the input schema descriptions.

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 purpose is exceptionally clear: 'Compare two cricket teams head-to-head.' It specifies the method used ('using squad form and player stats') and immediately sets it apart from simpler squad or match detail retrieval tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description focuses entirely on *how* the tool works rather than *when* to use it. It provides no guidance on scenarios where this tool would be preferred over other H2H tools like cricket_player_matchup or cricket_differential_picks.

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

Deploy Server