Skip to main content
Glama

List Results

list_results
Read-only

Look back at finished-match scores from the 30-day results cache, most-recent-first.

Results-only: each entry is the final score, red cards and finished time (no odds). Unlike the
live tools, these survive a restart — use it for "what was the score of X?" or "yesterday's
results".

Args:
    date: optional UTC kickoff date "YYYY-MM-DD" — the day the match was played.
    team: optional case-insensitive substring matched against either team name.
    league: optional case-insensitive substring matched against the league name.
    limit: max results to return, most-recent-first (1–200, default 50).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo
teamNo
limitNo
leagueNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond readOnlyHint=true, the description discloses the 30-day retention window, persistence across restarts, entry fields (final score, red cards, finished time), absence of odds, and most-recent-first ordering. No contradiction with annotations.

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?

The description is compact and front-loaded: one sentence states purpose and scope, one paragraph defines the result content and cache behavior, and the Args block is dense. Only minor redundancy ('most-recent-first' twice) exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with four optional parameters and no output schema, this description supplies everything required to call it correctly: filter semantics, ordering, output fields, cache window, and parameter constraints. No gaps that would cause mis-invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides no descriptions (0% coverage), but the description documents all four parameters with formats ('YYYY-MM-DD' UTC), matching semantics (case-insensitive substring for team and league), and validation limits for limit (1–200, default 50).

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?

The description uses a specific verb ('look back') and resource ('finished-match scores from the 30-day results cache'), defines ordering ('most-recent-first') and explicitly contrasts itself with 'live tools', so an agent can distinguish it from the other score/odds tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

It gives explicit use cases ('what was the score of X?' / 'yesterday's results'), states the cache survives restart unlike live tools, and notes results contain no odds, effectively excluding odds-related queries. It could name specific sibling tools, but the when/when-not guidance is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources