mcp-claudinho

Match detail

get_match

Read-only

Fetch a single match by ID with live score/minute when in play. Optionally enrich with prediction-market signals; marketComplete=false means an incomplete read, not no signal.

Instructions

One match by its id, with live score/minute overlaid when it's in play. Optional prediction-market enrichment carries marketComplete; false means the read was incomplete, not that no signal exists. Get the id from get_today or get_live; to find a team's match without an id, use get_next_fixture. tz/lang/flavor affect formatting.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Match id
`tz`	No	IANA timezone for kickoff times, e.g. America/Mexico_City
`lang`	No	Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en)
`flavor`	No	Commentary flair: off, subtle, full (default: full)

Output Schema

TableJSON Schema

Name	Required	Description
`match`	Yes
`source`	No
`degraded`	No
`marketSignal`	No
`marketComplete`	No	False when optional market enrichment did not check this fixture
`responseTruncated`	No
`responseTruncation`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.10.0Sep 15, 2026

addedOutput schema / properties / marketComplete

Added value: +{
+  "description": "False when optional market enrichment did not check this fixture",
+  "type": "boolean"
+}

addedOutput schema / properties / responseTruncated
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / responseTruncation
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedv0.9.0Jul 3, 2026

changedInput schema / properties / lang / description

Previous value: -"Locale for formatting: en, es, pt, fr (other locales fall back to en)"New value: +"Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en)"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "degraded": {
+      "type": "boolean"
+    },
+    "marketSignal": {
+      "anyOf": [
+        {
+          "additionalProperties": true,
+          "properties": {},
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "match": {
+      "anyOf": [
+        {
+          "additionalProperties": true,
+          "properties": {
+            "away": {
+              "$ref": "#/properties/match/anyOf/0/properties/home"
+            },
+            "group": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "home": {
+              "additionalProperties": true,
+              "properties": {
+                "code": {
+                  "type": "string"
+                },
+                "flag": {
+                  "type": "string"
+                },
+                "name": {
+                  "type": "string"
+                }
+              },
+              "type": "object"
+            },
+            "id": {
+              "type": "string"
+            },
+            "kickoff": {
+              "type": "string"
+            },
+            "minute": {
+              "type": [
+                "number",
+                "null"
+              ]
+            },
+            "score": {
+              "anyOf": [
+                {
+                  "additionalProperties": true,
+                  "properties": {
+                    "away": {
+                      "type": "number"
+                    },
+                    "home": {
+                      "type": "number"
+                    }
+                  },
+                  "type": "object"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "shootout": {
+              "$ref": "#/properties/match/anyOf/0/properties/score/anyOf/0"
+            },
+            "stage": {
+              "type": "string"
+            },
+            "status": {
+              "type": "string"
+            },
+            "venue": {
+              "type": "string"
+            },
+            "winnerCode": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "id"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "source": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "match"
+  ],
+  "type": "object"
+}

First observedv0.1.0Jun 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover readOnlyHint and openWorldHint, but the description adds concrete behavioral context: the live score/minute overlay is conditional on in-play status, and marketComplete=false is explicitly interpreted as an incomplete read rather than a missing signal. This directly enriches the open-world annotation and prevents a likely misinterpretation.

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?

Three sentences with zero redundancy. Each sentence carries unique value: main behavior, the marketComplete caveat, and id sourcing/alternative routing. Information is front-loaded and every word earns its place.

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?

With an output schema and annotations present, the description covers all necessary missing context: how to get the id, when to choose an alternative, and how to interpret a potentially ambiguous output field. Nothing an agent needs to call this tool correctly is omitted.

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%, so the schema already documents all four parameters. The description's only addition is the high-level note that 'tz/lang/flavor affect formatting,' which is a mild summary rather than substantive new semantic detail. Baseline 3 is appropriate.

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 description states the exact verb and resource ('One match by its id') and explicitly differentiates from sibling tools: get_today/get_live provide collections, get_next_fixture finds a match without an id. An agent can immediately tell this tool is for a known match id.

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

Usage Guidelines5/5

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

It gives explicit sourcing guidance ('Get the id from get_today or get_live') and names the alternative for id-less team lookup ('use get_next_fixture'). This is clear when-to-use and when-not-to-use guidance with no gaps.

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

Deploy Server