Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

flashscore_match_commentary

Retrieve Flashscore play-by-play match commentary, newest first, by eight-character match ID. Get displayed minutes, clocks, and event types; matches without text coverage return not found.

Instructions

Flashscore match text commentary. Returns the play-by-play text Flashscore publishes for a match, newest first. Each entry can include the displayed minute, a detailed clock and an event type. Pre-match comments may have no time. Matches without text coverage return not found.

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": {
      "id": "<id>"
    },
    "name": "flashscore_match_commentary"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Eight-character Flashscore match id

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does a fair job: it discloses result ordering (newest first), the shape of an entry (displayed minute, detailed clock, event type), and the pre-match edge case where time may be absent. It does not state whether results are paginated or bounded, or whether the response is a bare list or wrapped in an object.

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?

Four short sentences, front-loaded with the core purpose, then ordering, then entry contents, then edge cases. Nothing is repetitive and every sentence contributes 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?

For a single-parameter read tool with no output schema, the description covers purpose, ordering, entry fields and a failure mode. The remaining gap — no explanation of response envelope or size limits — is minor but real for a tool returning potentially long play-by-play text.

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?

Only one parameter exists and schema coverage is 100% ('Eight-character Flashscore match id'), so the schema already fully documents it. The description adds no further meaning about the id format, where to obtain it, or how invalid ids behave, 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?

The description names a specific verb and resource: 'Returns the play-by-play text Flashscore publishes for a match.' It also specifies the ordering ('newest first') and the source provider, which separates it from the cricinfo/cricbuzz commentary siblings. It stops short of explicitly contrasting with near neighbors like flashscore_match_incidents or flashscore_match_report.

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?

Usage is only implied: an agent infers this is the tool for narrative play-by-play on a given match. It does add a useful boundary condition ('Matches without text coverage return not found'), but there is no explicit when-to-use/when-not statement and no alternative named for structured events (incidents) or summaries (report).

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

Deploy Server