Retrieve team match schedules, home or away, most recent first. Filter by status and language.
A team's matches home or away, most recent first.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language code for team/league names, e.g. en, es, de, ja, zh-cn | |
| page | No | Page number (default 1) | |
| status | No | Filter by match status (default all) | |
| team_id | Yes | Team id |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive safety profile, so the description only needs to add extra behavioral context. It adds the most-recent-first ordering and the home/away scope, but it does not explain status filtering or pagination behavior. This is not a contradiction and the added context is modest.
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 short sentence with no filler, and the core subject is presented immediately. The phrase 'home or away' is a little awkward, but the overall structure is compact and efficient.
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 read-only list endpoint, the description conveys the essential subject and ordering. However, with four parameters and no output schema, it does not mention status/page defaults or the shape of the returned fixtures, so an agent would need to infer or discover some behavioral details.
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?
Schema description coverage is 100%, so team_id, lang, page, and status are already documented structurally. The description adds no parameter-level details beyond implying team_id is the central selector, so the 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 identifies the resource as a team's matches, includes the home/away scope, and states the sort order as most recent first. It is distinct enough from get_league_fixtures and get_fixtures because it focuses on a specific team, though it lacks an explicit verb and 'home or away' is slightly ambiguous.
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 gives no guidance on when to use this tool versus siblings such as get_fixtures or get_league_fixtures, and it does not mention any exclusions or alternatives. The team-specific scope is implied, but the routing decision is left entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.