Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

sofascore_player_events

SofaScore player matches with per-match numbers. Returns one page (30 matches) of a player's matches, each with the player's own numbers merged in: statistics (football: rating and minutes_played; basketball: points, rebounds, assists…

Instructions

SofaScore player matches with per-match numbers. Returns one page (30 matches) of a player's matches, each with the player's own numbers merged in: statistics (football: rating and minutes_played; basketball: points, rebounds, assists and more), incident_counts (goals, assists, yellow and red cards, penalty goals), on_bench for an unused substitute and played_for_team_id (club or national team). Page 0 is the most recent window and can include upcoming fixtures (status type notstarted); matches inside a page run oldest first. Follow has_next_page for older pages; a page past the end returns 404.

Input Schema

NameRequiredDescriptionDefault
idYesNumeric SofaScore player id
pageNoZero-based page number. Defaults to 0

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.12

TDQS

A3.9/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 page size (30 matches), that page 0 is the most recent window and may include upcoming fixtures, that matches run oldest-first within a page, the has_next_page convention, and that a page past the end returns 404. It stops short of stating access/safety traits, but the operational behavior is thoroughly disclosed.

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 core purpose before enumerating return fields, then pagination and edge cases. It is dense but every sentence (field breakdown, page semantics, 404) adds distinct value rather than restating the same point.

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 tool with no output schema and no annotations, the description covers return structure and pagination well. It omits any note on return format stability or auth, but for a read-style listing endpoint the essentials an agent needs to call it correctly are present.

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?

Schema coverage is 100%, so the schema already documents both params, making 3 the baseline. The description adds genuine meaning beyond it by defining what page 0 represents ('most recent window'), the intra-page ordering, and the follow-has_next_page rule, which the terse schema does not.

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?

States a specific resource and scope: 'SofaScore player matches with per-match numbers,' clarified as one page of a player's matches with the player's own stats merged in. An agent can distinguish this from sofascore_player_season_statistics or sofascore_player_ratings without opening another schema.

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

Usage Guidelines2/5

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

The description explains what comes back and how pagination works, but never states when to reach for this tool versus alternatives like sofascore_player_season_statistics, sofascore_player_ratings, or sofascore_player_tournaments. There is no when-to-use or when-not guidance, only behavioral detail.

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