AskScores
Server Details
Sports stats questions in plain English: NBA, WNBA, NFL, MLB, NHL and college football.
- Status
- Healthy
- Uptime
- 98.3% over 18 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of confusing it with another. Its purpose is clearly stated and distinct.
With a single tool named 'ask', there is no pattern to violate. The name is simple, readable, and consistent with the server's purpose.
A single tool is borderline for a server with such a broad domain. While a unified natural-language query tool can work, the surface feels thin compared to more structured multi-tool designs.
The tool claims comprehensive coverage across major sports and stat types, including game logs, splits, and playoff history. However, it lacks explicit structured operations for discovery or metadata, leaving minor gaps.
Available Tools
1 toolaskAsk AskScoresARead-onlyInspect
Answer a sports statistics question in plain English: NBA, WNBA, NFL, MLB, NHL and college football. Player and team stats by season or career, game logs, last N games, leaders, records, head-to-head, splits against left- and right-handers, playoff history. Returns the answer, the table behind it and a link to the page on askscores.com.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | e.g. "aaron judge vs lefties 2025", "lebron james last 5 games" |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only and closed-world behavior. The description adds valuable behavioral detail beyond them: it discloses the return shape (answer, table, page link), which is the kind of context annotations cannot convey, especially useful since there's no output schema.
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?
Two dense but well-structured sentences: the first front-loads capabilities, the second describes returns. It's information-rich rather than padded, though the capability list is long enough to verge on a feature dump.
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 single-parameter Q&A tool with no output schema, the description covers scope (leagues, stat categories), example phrasing is in the schema, and the return format is described. Nothing critical is missing; only question-phrasing constraints (e.g. the 200-char limit) go unmentioned.
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 coverage is 100% and includes example values for the single question parameter. The description adds league/scoping context that helps frame questions but doesn't add syntax or format detail beyond the schema. Baseline 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 names a specific verb (answer a sports statistics question) and enumerates the scope precisely: leagues, stat types, splits, records. It's unambiguous what this tool does.
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?
No siblings exist, so there's no alternative to route away from. The description implies usage via the example question formats, but doesn't explicitly state when to use this versus not, or prerequisites for phrasing questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
ask
Related MCP Connectors
Live sports stats and pre-computed analysis for AI assistants across NBA, MLB, NFL, and NHL.
NFL/NBA/MLB/NHL/PGA + DFS and prediction-market data. Browse free; query with a free API key.
Live and historical NBA/NFL/NHL data — fantasy bots, content sites, betting research.
Sports betting odds, player props, scores, betting splits and history from 30+ sportsbooks
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceProvides access to comprehensive sports data from 5 major leagues (NBA, NFL, MLB, EPL, NHL) including teams, players, games, statistics, standings, injuries, and betting odds through 67+ endpoints. Enables users to query sports information and analytics through natural language.12MIT
- AlicenseBqualityDmaintenanceProvides comprehensive NBA statistics via Model Context Protocol, enabling queries for player stats, game scores, team info, and advanced analytics through natural language.2111MIT
- AlicenseAqualityDmaintenanceEnables access to live ESPN sports data for NFL, NHL, and NBA leagues, including standings, scores, schedules, team info, and playoffs through natural language queries.615 npm1MIT
- AlicenseNot gradedqualityBmaintenanceEnables natural language access to NFL data, including play-by-play with EPA, player and team stats, injuries, depth charts, and closing lines for games since 1999.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.