Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

flashscore_match_darts

Retrieve leg-by-leg darts match data with throw-by-throw scoring, remaining scores, 180s/140+ highlights, and full statistics.

Instructions

Flashscore darts throw-by-throw and statistics. Returns a darts match leg by leg: who started and won each leg, the leg score, every visit with the points scored, the score remaining and 180 or 140-plus highlights, and the score the winner finished from, plus the statistics comparison (three-dart average, 180s, 140+ and 100+ visits, checkout percentage, highest checkout). Set-play matches add the set of each leg, the leg score within the set and the statistics of every set; a live match includes the leg being played. Streamed events whose scoring is not tracked and non-darts matches return not found.

Input Schema

NameRequiredDescriptionDefault
idYesEight-character Flashscore match id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.12

TDQS

A3.7/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 so well: it discloses live-match behavior ('a live match includes the leg being played'), set-play variations, and the two not-found conditions (untracked streamed scoring, non-darts matches). The remaining gap is that it never says this is a read-only retrieval or whether the id must come from a search/schedule tool first.

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?

Front-loaded with the one-line purpose, then the return contents, then the exceptions. The middle sentence is long and lists many statistics fields, but each detail is substantive for an output-less tool, so little is wasted.

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, so the description must explain the return shape and it does thoroughly: legs, visits, remaining scores, highlights, set structure, live state, plus statistics comparison. The only missing piece is where the match id comes from (a schedule/search tool), which prevents a perfect score.

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% – the single 'id' parameter is already documented as an 'Eight-character Flashscore match id'. The description adds no format, sourcing, or validation detail beyond that, so the baseline of 3 for full schema coverage 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 resource and scope: 'Flashscore darts throw-by-throw and statistics', then enumerates exactly what a darts match return contains (legs, visits, checkouts, statistics). The domain specificity distinguishes it from generic flashscore_match_stats siblings, though it never explicitly names an alternative when the match is not darts.

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 implied rather than stated: the tool is for darts matches, and the closing sentence says non-darts matches and unscored streamed events 'return not found', which is useful boundary guidance. However, no sibling tool is named as the alternative (e.g. flashscore_match_stats or flashscore_match_point_by_point for other sports), so the agent has to infer routing.

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