Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

flashscore_scores

Flashscore scores and fixtures by sport. Returns the public score feed for one sport and date-picker day offset. The upstream field-delimited text is preserved because field semantics vary by sport.

Instructions

Flashscore scores and fixtures by sport. Returns the public score feed for one sport and date-picker day offset. The upstream field-delimited text is preserved because field semantics vary by sport. Use flashscore-sports to discover sport keys, flashscore-navigation for the current category/country/competition directory, and flashscore-competitions for competitions on the selected date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sportYesSport key
day_offsetNoDays from today; -7 to 7; defaults to 0

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.12
    • changedInput schema / properties / sport / enum
      Previous value: -[
      -  "football",
      -  "tennis",
      -  "basketball",
      -  "hockey",
      -  "golf",
      -  "formula-1",
      -  "baseball",
      -  "snooker",
      -  "american-football",
      -  "aussie-rules",
      -  "badminton",
      -  "bandy",
      -  "beach-soccer",
      -  "beach-volleyball",
      -  "boxing",
      -  "cricket",
      -  "cycling",
      -  "darts",
      -  "esports",
      -  "field-hockey",
      -  "floorball",
      -  "futsal",
      -  "handball",
      -  "horse-racing",
      -  "kabaddi",
      -  "mma",
      -  "motorsport",
      -  "netball",
      -  "pesapallo",
      -  "rugby-league",
      -  "rugby-union",
      -  "table-tennis",
      -  "volleyball",
      -  "water-polo",
      -  "winter-sports"
      -]New value: +[
      +  "football",
      +  "tennis",
      +  "basketball",
      +  "hockey",
      +  "golf",
      +  "formula-1",
      +  "baseball",
      +  "snooker",
      +  "american-football",
      +  "aussie-rules",
      +  "badminton",
      +  "bandy",
      +  "beach-soccer",
      +  "beach-volleyball",
      +  "boxing",
      +  "cricket",
      +  "cycling",
      +  "darts",
      +  "esports",
      +  "field-hockey",
      +  "floorball",
      +  "futsal",
      +  "handball",
      +  "horse-racing",
      +  "kabaddi",
      +  "mma",
      +  "motorsport",
      +  "netball",
      +  "pesapallo",
      +  "rugby-league",
      +  "rugby-union",
      +  "table-tennis",
      +  "volleyball",
      +  "water-polo",
      +  "winter-sports",
      +  "moto-racing",
      +  "ski-jumping",
      +  "alpine-skiing",
      +  "cross-country-skiing",
      +  "biathlon"
      +]
  2. Addedv1.17.5

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it delivers the most important behavioral fact: the upstream field-delimited text is preserved because field semantics vary by sport, warning the agent the return is raw, not normalized. It omits rate limits and pagination, but the output-format disclosure is substantive.

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 tool's function, then a behavioral caveat, then routing. Each sentence carries distinct information with no padding.

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?

No output schema exists, and the description compensates by explaining the raw field-delimited return format. Parameters are fully covered by the schema and the sibling routing is present, so an agent has what it needs for a 2-param read tool.

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 description coverage is 100%, so both parameters are already documented. The description only echoes this with 'one sport' and 'date-picker day offset,' adding marginal meaning beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb and resource: 'Returns the public score feed for one sport and date-picker day offset,' which tells the agent exactly what comes back. It also names sibling tools (flashscore-sports, flashscore-navigation, flashscore-competitions), giving partial differentiation, though it does not distinguish itself from other score providers in the broader catalog.

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

Usage Guidelines4/5

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

Provides explicit routing context: sports for sport keys, navigation for the category/country/competition directory, competitions for competitions on the selected date. This establishes prerequisites and alternatives clearly, though it never states when to avoid this tool.

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

Deploy Server

Other Tools