Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

sofascore_team_achievements

SofaScore team trophies. Returns the trophies a team has won: the total and, per competition, the number won and the winning seasons (newest first, with the season id where SofaScore tracks it).

Instructions

SofaScore team trophies. Returns the trophies a team has won: the total and, per competition, the number won and the winning seasons (newest first, with the season id where SofaScore tracks it). Some competitions, such as US leagues, report a count with an empty or shorter seasons list. Returns 404 when SofaScore records no achievements for the team.

Input Schema

NameRequiredDescriptionDefault
idYesNumeric SofaScore team id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.12

TDQS

A4/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 behavioral burden and does so well: it discloses ordering (newest first), that some competitions (US leagues) return a count with an empty or shorter seasons list, and that a 404 is returned when SofaScore records no achievements. It stops short of pagination or rate-limit behavior, but the data-shape caveats are genuinely useful.

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?

Three tight sentences, front-loaded with what is returned, then the per-competition shape, then edge cases and the 404. No filler and every sentence carries information.

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 one-parameter read tool with no output schema, the description explains the return structure and its irregularities well enough to set expectations. It is not quite complete (no mention of what 'total' counts or whether non-tracked season ids appear), but nothing essential is missing.

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?

Only one parameter exists and schema coverage is 100% ('Numeric SofaScore team id' is already documented in the schema). The description adds no formatting, sourcing, or lookup guidance beyond the schema, so the 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: 'Returns the trophies a team has won', with the scope narrowed to total and per-competition counts plus winning seasons. An agent can distinguish this from sofascore_team_tournaments or sofascore_team 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 Guidelines3/5

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

The description implies the use case (fetch a team's trophy history) but never states when to choose this over the many neighboring team endpoints such as sofascore_team_tournaments or sofascore_team_statistics_seasons. Implied usage is legible, but there are no explicit conditions or exclusions.

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