Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

flashscore_odds_geos

Flashscore odds markets, subdivisions and odds enums. Lists every country code accepted by flashscore-match-odds and flashscore-match-tv (with whether bookmakers were found for it when verified), the US states and Canadian provinces that…

Instructions

Flashscore odds markets, subdivisions and odds enums. Lists every country code accepted by flashscore-match-odds and flashscore-match-tv (with whether bookmakers were found for it when verified), the US states and Canadian provinces that change the bookmaker list, and every betting type, scope and handicap type that can appear in odds responses.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.12

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does disclose one genuine behavioral detail — entries carry whether bookmakers were found for a country when verified — but omits any statement about freshness, caching, or response shape. For a static read-only enumeration the burden is low, so this is adequate rather than rich.

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?

Two sentences with zero filler, front-loaded with the kind of data returned and then the exact coverage of each category. Every clause (country codes, US states/Canadian provinces, betting types/scopes/handicap types) maps to a distinct portion of the output.

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?

With no output schema, no annotations, and no parameters, the description must alone convey what the agent gets back — and it enumerates all four result categories, which is sufficient to decide whether to call it. It stops short of describing the shape of the returned records or how the bookmaker-verification flag is represented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the baseline rule this scores 4. The schema is empty and there is nothing for the description to compensate for; the description's enumeration of returned categories is additive rather than a substitute for missing parameter documentation.

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 concrete resource (country codes, US states/Canadian provinces, betting types, scopes, handicap types) and the specific siblings the values are consumed by (flashscore-match-odds, flashscore-match-tv). An agent can tell this is a reference/enumeration lookup rather than a data-fetching odds tool. The leading noun-phrase 'Flashscore odds markets, subdivisions and odds enums' is slightly list-like rather than a verb phrase, which keeps it just short of a 5.

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?

Naming flashscore-match-odds and flashscore-match-tv strongly implies this is the tool to call to discover valid inputs for those tools, but the description never explicitly says 'use this before calling X' or states any when-not condition. Usage is inferable rather than stated, which is the definition of a 3.

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