Friday expert picks on 25 football matches from players with records since 1997. Read-only, free.
Scored across 6 tools
find_matches and list_matches both enumerate matches (one with brief predictions and filters, one bare schedule), and get_consensus vs get_match_prediction both return crowd/group splits and top exact scores for a match, differing mainly by lookup key (id/filters vs team names). Descriptions do distinguish them (list vs full records vs single expert pick), but the boundaries are thin enough that an agent could easily pick the wrong one. get_accuracy and get_expert_picks are clearly distinct.
All six tools follow a clean snake_case verb_noun pattern (find_matches, get_accuracy, get_consensus, get_expert_picks, get_match_prediction, list_matches). The find/list verb split is semantically meaningful rather than inconsistent.
Six tools is well within the ideal range and each maps to a distinct facet of the read-only football predictions domain (browse, schedule, single-match detail, crowd records, expert picks, accuracy stats). No filler tools.
Core read paths are covered: match discovery, per-match predictions, consensus records, expert picks, and accuracy metrics. Minor gaps exist—no way to enumerate available competitions/games or team lists explicitly, and no leaderboard/player-level lookup—but agents can work around these via filters and free-text team names.
Football (soccer) matches with TipMaster expert predictions, filtered by team, competition (e.g. "Bundesliga", "Premier League", "LaLiga"), mode, status and kickoff window: upcoming (locked), live and finished (played) matches of the last 10 days. Each line has teams, kickoff, status, result, the most likely score and the home/draw/away call of the Top 20%, Top 25% and All players groups.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | national (exact scores, 15 countries) or classic (home/draw/away, 25 matches a week); omit for both. | |
| team | No | A team, or "Home vs Away" | |
| limit | No | Default 25 | |
| toUtc | No | Kickoff until, unix seconds | |
| status | No | open, locked (final predictions, not played yet), played or cancelled; omit for all. | |
| fromUtc | No | Kickoff from, unix seconds | |
| competition | No | League name, e.g. "Premier League" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuine context beyond annotations: the 10-day kickoff window and the exact per-line payload (teams, kickoff, status, result, most likely score, group calls). It does not discuss limit/pagination behavior, but the additions are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core identity (matches with expert predictions) and then adds filters and return content. Two tight sentences; the only density is a long first sentence, but every clause (filters, window, line contents) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully explains the returned columns, and all parameters are schema-covered. For a read-only filtered search tool the definition is nearly complete, lacking only explicit guidance on limit/pagination behavior and sibling routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all seven parameters are already documented, including enum meanings for mode and status. The description restates the filterable fields and adds the kickoff-window interpretation, but adds little beyond the schema's own enum descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (find football/soccer matches with TipMaster expert predictions) plus the filters and a description of each returned line. It is clear on its own, but it does not explicitly distinguish itself from siblings like list_matches or get_match_prediction, leaving the agent to infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope note about 'upcoming (locked), live and finished (played) matches of the last 10 days' implies the retrieval window and helps orient usage. However, there is no explicit when-to-use vs alternatives (e.g., no hint that get_match_prediction returns a single match or that list_matches might be a leaner listing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How often TipMaster players got football (soccer) matches right, per group (Top 20%, Top 25%, All players): majorityCorrect is the share of matches where the group’s most common home/draw/away call was right, outcomeCorrect the share of individual predictions with the right outcome, exactCorrect the share with the exact final score (National only). National covers the last 8 weeks, each week’s groups ranked on the 8 weeks before it; Classic covers this season, ranked by career record since 1997, and career gives each group’s average career points per match since 1997. A group’s rates appear once it has 50 matches with a published split (reason too_few_matches until then). Pass competition (National league name) or game (Classic) to narrow it.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Classic game: btm = Bundesliga TipMaster, tmi = TipMaster International | |
| mode | No | national (exact scores, 15 countries) or classic (home/draw/away, 25 matches a week); omit for both. | |
| competition | No | National league name, e.g. "Bundesliga" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses real behavioral detail: rates only appear after 50 matches, a too_few_matches reason is returned before that, and National is a rolling 8-week window ranked on the prior 8 weeks. It does not discuss payload size, pagination or caching, but the data-availability semantics are unusually well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and every clause carries substantive information about metrics, windows or thresholds. It is dense — long compound sentences pack metric definitions, ranking windows and the minimum-match rule together — so it reads heavier than it needs to, but there is essentially no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must define the return fields, and it does: majorityCorrect, outcomeCorrect and exactCorrect are each defined, including the exactCorrect National-only caveat. Combined with the availability rule and filter guidance, an agent has enough to call and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds cross-parameter meaning the schema lacks: 'competition' is the National league name and 'game' applies to Classic, making the mode pairing explicit. That interaction constraint is genuinely useful context an agent would otherwise have to infer from enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause states exactly what is returned: per-group accuracy rates for TipMaster football predictions, with the three metrics named (majorityCorrect, outcomeCorrect, exactCorrect). It is clearly an aggregate-accuracy tool rather than a pick or match lookup, so it is distinguishable from siblings like get_expert_picks and get_consensus by intent, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than prescribed: it explains the National vs Classic windows and says 'Pass competition ... or game ... to narrow it', which tells the agent how to filter but not when this tool is preferable to get_consensus or get_match_prediction. No exclusions or preconditions for choosing among siblings are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full prediction records: the crowd’s home/draw/away shares, the top 3 exact scores and most likely score (National), the Top 20% / Top 25% / All players groups (bands) and the expert cohort. Pass an id for one match, or mode/status filters for a list. outcome is null while fewer than 20 players have predicted.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | One match id, e.g. "classic:btm:7:14" | |
| mode | No | national (exact scores, 15 countries) or classic (home/draw/away, 25 matches a week); omit for both. | |
| status | No | open, locked (final predictions, not played yet), played or cancelled; omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety bar is low. The description adds genuinely useful behavior the annotations cannot: the "outcome is null while fewer than 20 players have predicted" threshold, which is a non-obvious data-availability rule. It does not describe ordering, limits, or pagination for the list form.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence defines the payload, followed by the two invocation shapes and the null-outcome caveat. Every clause carries information an agent needs; nothing is restated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must carry the return shape — and it does, naming the crowd shares, top scores, player bands, and expert cohort plus the null-outcome case. Missing is any hint of list-mode size, ordering, or pagination, which matters for a filter-driven list call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with enum descriptions, so the baseline is 3. The description goes beyond it by stating the id-vs-filter branching (single record vs list) and by tying "most likely score" to the National mode, clarifying how mode changes the payload rather than just filtering it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: it enumerates exactly what a full prediction record contains (home/draw/away shares, top 3 exact scores, player bands, expert cohort). It never names or contrasts itself against the visible siblings get_match_prediction, find_matches, or list_matches, so the agent must infer the boundary itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Pass an id for one match, or mode/status filters for a list" gives clear invocation guidance for the two call shapes, and the schema confirms filters are optional. But there is no when-to-use vs when-not guidance, and no routing to get_match_prediction (lighter prediction) or find_matches/list_matches for discovery, which are the obvious alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The current TipMaster Classic round: 25 real football (soccer) matches per game (btm = Bundesliga TipMaster, tmi = TipMaster International), each with the expert cohort’s home/draw/away split and majority pick (expertPick), and the whole crowd’s split beside it. The expert cohort is the top quarter, by career points per match, of this round’s players with at least 100 career Classic matches, a record kept since 1997. Expert predictions are published once the round’s entries close (Friday 18:00 Europe/Berlin, releaseUtc); before that released is false, expertPick and expert are null and expertSample is 0. Shares need at least 20 players.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | One Classic game; omit for both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description discloses critical behavior: predictions are released only after entries close, before which released is false, expertPick and expert are null, and expertSample is 0. It also defines the expert cohort qualification and the minimum 20-player threshold for shares.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded, beginning with the core resource before moving to cohort definition, release timing, and null behavior. Most clauses earn their place, though the single paragraph could be slightly easier to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns and does so for key fields such as expertPick, expert, expertSample, released, and the home/draw/away splits. It is nearly complete for a one-parameter read tool, though the full response structure is not exhaustively described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the enum values are already documented. The description still adds useful meaning by expanding btm as Bundesliga TipMaster and tmi as TipMaster International, going beyond the bare enum labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and scope: the current TipMaster Classic round, with 25 matches per game, expert cohort splits, majority picks, and crowd splits. It also distinguishes the expert cohort from the whole crowd, which differentiates it from a generic consensus tool like get_consensus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the data is usable by explaining the Friday 18:00 Europe/Berlin publication time and the pre-release null state. However, it does not explicitly say when to choose this tool over siblings such as get_consensus or get_match_prediction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The TipMaster expert prediction for one football (soccer) match, found by team names ("Bayern vs Freiburg", one team name also works) or by id. Returns the most likely final score (mostLikelyScore, National only), the top 3 exact scores, and the home/draw/away split of three groups ranked by their own record: Top 20%, Top 25% and All players. Once played it carries the result. Shares are final once status is locked or played (a Classic match with status open still moves); the person asking has nothing to enter. Classic matches have no score (scoreRecorded false), only home/draw/away. A group with fewer than 20 players is withheld (reason). Other close matches are listed in alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A match id, e.g. "daily:4821" or "classic:btm:1:9" | |
| match | No | Teams, e.g. "Bayern vs Freiburg" or "Arsenal" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/idempotent annotations already covering safety, the description still contributes real behavioral context: shares are final once status is locked or played (open Classic matches still move), Classic matches have scoreRecorded false and only home/draw/away, and groups under 20 players are withheld with a reason. That is exactly the kind of edge-case disclosure an agent cannot get from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and lookup method, then return shape, then edge cases; every sentence carries information. It is a dense single paragraph with several parenthetical asides, which costs a little scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description names the returned fields, explains the group ranking tiers, covers the Classic-vs-National divergence, and documents the withheld-group case. An agent can call this correctly and interpret the response without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds semantics the schema does not: the two lookup keys are alternatives, a partial team name ('Arsenal') is sufficient, and the id format maps to daily/classic match families. It does not say what happens if neither parameter is supplied, which keeps it off a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'The TipMaster expert prediction for one football (soccer) match,' and enumerates the return payload (mostLikelyScore, top 3 exact scores, home/draw/away split by group). It never names a sibling to contrast with, so an agent must infer the boundary with get_consensus or get_expert_picks, but the resource is concrete enough to be actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear invocation context for both lookup paths ('found by team names ... one team name also works) or by id' and notes that near-misses are surfaced via alternatives, which tells the agent how to recover from a failed lookup. It stops short of explicit when-to-use/when-not guidance versus the sibling prediction/consensus tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every published football (soccer) match (teams, kickoff, entry deadline, status, result) without the prediction fields.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | national (exact scores, 15 countries) or classic (home/draw/away, 25 matches a week); omit for both. | |
| status | No | open, locked (final predictions, not played yet), played or cancelled; omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and closed-world behavior, so the description's added context is the field inventory and the explicit statement that prediction data is omitted, which tells the agent what it will and will not get back. It does not cover ordering or result volume, which is a minor remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the resource and its scope, then packs the returned fields into a parenthetical with zero filler. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey return shape, and the parenthetical field list does exactly that while flagging the excluded prediction fields. Minor gaps remain around ordering and whether the list is paginated or bounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (mode, status) already carry enum-level descriptions including 'omit for both/all' defaults. The description adds no extra meaning about these filters, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (published football matches) and enumerates the fields returned (teams, kickoff, entry deadline, status, result). The clause 'without the prediction fields' implicitly separates it from prediction-oriented siblings such as get_match_prediction, but 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the exclusion of prediction fields hints that prediction tools should be used when those are wanted, but there is no explicit 'use this when' or a named alternative like find_matches. An agent can infer the split, but must do the work itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_matchesget_accuracyget_consensus3 fields changedInput schema / properties / mode / descriptionPrevious value: -"Only \"classic\" is published."New value: +"national (exact scores, 15 countries) or classic (home/draw/away, 25 matches a week); omit for both."Input schema / properties / mode / enumPrevious value: -[
- "classic"
-]New value: +[
+ "classic",
+ "national"
+]Input schema / properties / status / descriptionPrevious value: -"Restrict to one match status; omit for all."New value: +"open, locked (final predictions, not played yet), played or cancelled; omit for all."get_crowd_recordget_match_predictionlist_matches3 fields changedInput schema / properties / mode / descriptionPrevious value: -"Only \"classic\" is published."New value: +"national (exact scores, 15 countries) or classic (home/draw/away, 25 matches a week); omit for both."Input schema / properties / mode / enumPrevious value: -[
- "classic"
-]New value: +[
+ "classic",
+ "national"
+]Input schema / properties / status / descriptionPrevious value: -"Restrict to one match status; omit for all."New value: +"open, locked (final predictions, not played yet), played or cancelled; omit for all."get_consensus1 field changedInput schema / properties / id / descriptionPrevious value: -"One match id from list_matches"New value: +"One match id, e.g. \"classic:btm:7:14\""get_consensus2 fields changedInput schema / properties / mode / descriptionPrevious value: -"Restrict to one game mode; omit for all."New value: +"Only \"classic\" is published."Input schema / properties / mode / enumPrevious value: -[
- "classic",
- "national",
- "worldtour"
-]New value: +[
+ "classic"
+]get_crowd_record2 fields changedInput schema / properties / mode / descriptionPrevious value: -"Restrict to one game mode; omit for all."New value: +"Only \"classic\" is published."Input schema / properties / mode / enumPrevious value: -[
- "classic",
- "national",
- "worldtour"
-]New value: +[
+ "classic"
+]list_matches2 fields changedInput schema / properties / mode / descriptionPrevious value: -"Restrict to one game mode; omit for all."New value: +"Only \"classic\" is published."Input schema / properties / mode / enumPrevious value: -[
- "classic",
- "national",
- "worldtour"
-]New value: +[
+ "classic"
+]get_expert_picksget_consensusget_crowd_recordlist_matchesFootball match outcome probabilities recorded before kick-off, and an open record of results.
Free football match probabilities (Dixon-Coles), season projections and a public track record.
Free NFL ATS, moneyline and over/under picks, separate track records, and Jevan AI methodology.
Public read-only football and cricket match tips from bettingtipsai.com.
Add one secure layer between your agents and this server.