Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

sofascore_player_tournaments

SofaScore player competitions. Lists every competition a player has played in, with id, name, slug, category, sport and gender.

Instructions

SofaScore player competitions. Lists every competition a player has played in, with id, name, slug, category, sport and gender. It includes competitions without season statistics (cups, friendlies, all-star games) that player-statistics-seasons leaves out. Returns 404 when SofaScore has no competitions for the player.

Input Schema

NameRequiredDescriptionDefault
idYesNumeric SofaScore player id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.12

TDQS

A4.1/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 it discloses genuinely useful behavior: the resource is a read-style listing, includes competitions lacking season statistics, and returns 404 when no competitions exist. It does not cover auth or pagination, but the 404 disclosure is real behavioral value beyond any structured field.

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 tight sentences, front-loaded with the purpose, then the distinguishing scope, then the error behavior. Nothing is padded, though the opening fragment 'SofaScore player competitions' is slightly redundant with the sentence that follows.

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, the description correctly carries the return-value burden by listing the fields returned, plus the 404 edge case. For a simple one-param lookup this covers what an agent needs, though it could say more about ordering or result volume.

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% for the single required id parameter, which the schema already documents as 'Numeric SofaScore player id'. The description only implies that id refers to a player ('a player has played in') and adds no format or constraint detail, so baseline 3 applies.

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 verb and resource ('Lists every competition a player has played in') and enumerates the returned fields (id, name, slug, category, sport, gender). It explicitly distinguishes itself from the sibling sofascore_player_statistics_seasons, so an agent can route without opening either schema.

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?

Names an alternative (player-statistics-seasons) and the condition that selects this tool: it covers cups, friendlies and all-star games that the other omits. That is clear context, but there is no guidance about when to prefer this over other player tools like sofascore_player or sofascore_player_events, and no explicit when-not clause.

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