Loading ToolBench
Steam Charts MCP has two explicitly defined tools with basic naming and schemas, but suffers from critical gaps in description quality, parameter documentation, output schema specification, and error handling. Tool names follow verb conventions (get_, get_), but descriptions are extremely terse (15-25 chars vs. baseline 194 chars). Parameter descriptions exist but lack context and constraints. Critically, output schemas are completely undocumented, callers have no way to know what fields are returned or their types. Error handling is minimal; failed lookups return generic failure messages with no recovery guidance. The server is barely functional as a production-grade tool suite.
Get the game ID of a steam game
Get the Steam charts for a game
Tool descriptions are critically short (15-25 characters vs. baseline 194 chars). 'Get the game ID of a steam game' and 'Get the Steam charts for a game' provide no context on when to use each tool, dependencies, or expected output format. LLMs cannot reliably select the right tool from such bare descriptions.
Output schemas are completely undocumented. get-steam-charts returns a SteamCharts object with fields oneHourAgo, twentyFourHourPeak, allTimePeak, and chartData (array of ChartData with month, avgPlayers, gain, gainPercent, peakPlayers), but none of this is visible to the LLM or client. Without documented return types, downstream tool composition is impossible and callers must guess at field names and types.
Parameter descriptions lack constraint information. 'gameName' has no guidance on format, required length, or handling of ambiguous/multiple matches. 'gameId' provides no hint that this must be a numeric Steam App ID or how it's obtained. Missing constraints force LLMs to guess and invite invalid inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Error handling is generic and non-actionable. Both tools return 'Failed to retrieve game ID' or 'Failed to retrieve charts' with no context. There is no distinction between retryable failures (network timeout), user-fixable errors (game not found), or fatal errors. LLMs cannot recover from these responses, they have no next step.
No pagination or result limits documented. get-steam-charts returns full chart history (potentially hundreds of rows) in a single response. Large result sets waste tokens and risk context window exhaustion. The tool should accept limit/offset parameters and state a default result cap in its description.
No validation of inputs. A malformed gameId (non-numeric, negative, or extremely large) will be passed directly to the external Steam API, potentially causing 500 errors or timeouts. Input validation rules should be documented and enforced with actionable error messages.
No dependency documentation. get-steam-charts requires a gameId, but users do not have this, they only have game names. The description should state 'Call get-game-id first to obtain the gameId if you only have a game name.' Without this hint, agents will call get-steam-charts directly with invalid inputs.
No documentation of response field types or structure. The implementation shows SteamCharts contains oneHourAgo (number), chartData (array), etc., but the tool definition exposes none of this. Tools must document what fields are returned and their types so LLMs can chain downstream operations.