Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fussballde_team_matches

Retrieve FUSSBALL.DE team fixtures and results across competitions, filter by next, previous, wins, draws, or losses, and page match schedules by date.

Instructions

Get FUSSBALL.DE fixtures and results of a team. Returns a team's matches across its competitions. all (default) is the match plan for a date window (default the current season, 1 July to 30 June), optionally for one competition kind and paged with limit and offset; next is the next 10 fixtures, previous the latest 10 results, and wins, draws and losses the latest 10 finished matches with that outcome.

Input Schema

NameRequiredDescriptionDefault
kindNoMatch list kind, default all
limitNoMatches (kind all only) per call, 1 to 50, default 10
offsetNoNumber of matches to skip, 0 to 1000, default 0
date_toNokind all only: last day as YYYY-MM-DD, default 30 June of the season
team_idYesTeam id, see fussballde-team
date_fromNokind all only: first day as YYYY-MM-DD, default 1 July of the current season
competition_kindNokind all only: competition kind id; omit for all kinds

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

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 burden and discloses meaningful behavior: the default season date window (1 July to 30 June), that paging via limit/offset applies to `all`, and that next/previous/wins/draws/losses each return a fixed 10-match set. It does not describe return contents or failure behavior, so it is solid but not complete.

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 statement followed by a compact semicolon-delimited enumeration of `kind` behaviors. It is dense but every clause carries information; no filler sentences.

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?

Given 7 parameters, no annotations, and no output schema, the description covers kinds, defaults, and date semantics adequately. It omits any indication of what a match record contains and only defers team_id resolution to the schema note, leaving a small gap.

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; the description adds value by explaining what each `kind` value means and by defining the default date window, which goes beyond the terse schema strings. The limit/offset and competition_kind constraints are largely restated from the schema, limiting it to a 4.

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?

The description states a specific verb and resource ('Get FUSSBALL.DE fixtures and results of a team') and scopes it to a team's matches across its competitions. It does not, however, distinguish itself from close siblings such as fussballde_club_matches or fussballde_match_plan, so an agent cannot route between them from this text alone.

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?

Usage is well implied for the `kind` values: `all` for a paged plan over a date window, `next` for upcoming fixtures, `previous` for recent results, and `wins`/`draws`/`losses` for outcome-filtered matches. There is no explicit statement of when to prefer this over the sibling match tools, which keeps it below a 5.

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