current_matchdayGet the current matchday's football / soccer matches (results / scores) for a league (e.g. this week's Bundesliga fixtures) in the current season.
| Name | Required | Description | Default |
|---|---|---|---|
| league | Yes | League shortcut, e.g. 'bl1' (Bundesliga), 'bl2' (2. Bundesliga), 'bl3' (3. Liga), 'dfb' (DFB-Pokal). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, openWorldHint) already declare the tool's safe, non-destructive, and idempotent behavior. The description adds that it returns 'results/scores', which provides some output detail beyond the annotations. It does not contradict annotations, but the additional transparency is modest given the rich annotation set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose, includes a concrete example, and is front-loaded. No unnecessary words, though it could potentially be broken into two sentences for slightly better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately covers what it does and what it returns (results/scores). It is complete enough given the low complexity, though it does not explicitly state that it only returns one matchday or how to handle leagues without a current matchday.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'league' is fully described in the schema with examples and explanation of shortcuts, so the description adds no additional meaning beyond the schema. With 100% schema coverage, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current matchday matches for a specified league, with example 'this week's Bundesliga fixtures'. It distinguishes from sibling tools like 'get_matches' (which likely handles other matchday queries) and 'get_table' (standings), making its specific purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for current matchday fixtures, but it does not explicitly state when to avoid using it or mention alternatives among siblings. Usage context is implied but clear, lacking explicit guidance on exclusions or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, with detailed descriptions differentiating similar tools like ask_pipeworx, ask_pipeworx_grounded, and deep_research. However, some overlap exists between ask_pipeworx and ask_pipeworx_beta, as both serve as universal routers with only minor routing improvements.
Tool names follow inconsistent patterns: some use snake_case (ask_pipeworx, entity_profile), others use lowercase single words (forget, recall), and some use camelCase (bet_research, deep_research). This mix of conventions makes the naming scheme unpredictable.
With 35 tools, the server covers a wide range of data sources, but the count feels slightly heavy for the apparent scope. Several tools serve meta-purposes (discover_tools, suggest_questions) or specialized functions (polymarket_arbitrage), adding to the complexity.
The tool set offers comprehensive coverage for financial, economic, drug, and news data, including comparison and grounding capabilities. However, the football-related tools are limited to German leagues, leaving a minor gap for other sports or regions.