Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fussballde_competitions

List FUSSBALL.DE competitions by federation, season, team type, league, and area; returned competition IDs feed matchday, match plan, table, and top-scorer queries.

Instructions

List FUSSBALL.DE competitions for a league and area. Returns the competitions (Staffeln) at one selector path: a federation, season, competition type, team type, league and area. Each competition id (for example 031BFREJC800001BVS5489BUVUR5FS5A-G for the 2026/27 Bundesliga) is the key used by the matchday, match plan, table and top-scorer endpoints. An empty list is a valid result for a path with no competitions.

Input Schema

NameRequiredDescriptionDefault
areaYesArea id from fussballde-competition-options
leagueYesLeague id from fussballde-competition-options
seasonYesFour-digit season code
team_typeYesTeam type id from fussballde-competition-options
federation_idYesFederation id
competition_typeNoCompetition type id, default 1

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.4/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden, and it delivers meaningful behavior: this is a read/list operation, it returns a list of competitions, and an empty list is explicitly a valid outcome rather than an error. It omits pagination behavior, rate limits and auth requirements, which keeps it below a 5 for an unannotated tool.

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?

Four sentences, each earning its place: purpose, parameter scope, output key with example, and empty-result behavior. Front-loaded with the core action and no repeated or filler text.

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 annotations and no output schema, the description must justify its own existence, and it covers the operation's nature, the selector-path input model, the identity field of the output, downstream reuse of that id, and empty results. It leaves the remaining fields of a competition entry undocumented, a modest gap for a simple listing endpoint.

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 baseline is 3, but the description adds genuine semantics by framing the six parameters as a single 'selector path' rather than independent filters — exactly one combination yields the result set. It also anchors the output key with a concrete id example. It does not explain the competition_type default or what values like '-300' mean, which stays partly with the schema.

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 ('List FUSSBALL.DE competitions') and pins the scope precisely: competitions at one selector path defined by federation, season, competition type, team type, league and area. It also clarifies the return unit (competitions/Staffeln and their `id`), so an agent can tell it apart from ID-lookup and downstream endpoints.

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?

The description makes the tool's role in a workflow explicit: the returned `id` is the key used by the matchday, match plan, table and top-scorer endpoints, which tells an agent to call this first when it needs those. It does not name a specific alternative or state when not to use it (e.g., use fussballde_competition_options to discover valid selector values), so it stops short of full routing guidance.

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