Ranks Steam games by how much players like them, learned from head-to-head duels.
Scored across 3 tools
Each tool targets a clearly distinct operation: search_games resolves names to appids, game_detail reports on a single game, and versus compares exactly two games head-to-head. There is no overlap in purpose, and the descriptions explicitly state when each should be used.
game_detail (noun_action) and search_games (verb_noun) follow different patterns, and versus is a bare single word matching neither convention. The names are readable and guessable, but the convention is mixed rather than predictable.
Three tools is on the lean side but each earns its place: resolution, single-game lookup, and pairwise comparison form a coherent workflow. It is slightly thin for a domain that likely has ranking/leaderboard views, but nothing feels redundant.
The core lookups (resolve, inspect, compare) are covered with a sensible dependency chain (search first, then use appids). Gaps remain for browsing — no leaderboard, tier list, or top-games tool — so agents cannot discover games without a name, but the stated question types are answerable.
The community consensus for one game on needmoar.games: how liked it is (the share of a typical library it beats), its tier and rank, the full distribution of opinions, and the games players who like it also like or dislike — useful for "how popular / well-liked is X?" and "games similar to X". Also, in the players' own words, what they liked about it and what kept them from ranking it higher (short tags with counts), once enough players said so. Pass a Steam appid — resolve names with search_games first. The response links to the game's page you can cite.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam appid of the game (resolve names with search_games). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds meaningful behavior beyond that: the response links to a citable game page, and the qualitative tags are only returned "once enough players said so" — a data-availability threshold an agent otherwise could not anticipate. It doesn't describe response size or shape in detail, but that is acceptable at this level.
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?
Information-dense and front-loaded: it leads with what the response contains, then the trigger questions, then the input instruction and citation note. The middle clause is long and slightly run-on, but every sentence carries content and nothing is redundant filler.
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?
With no output schema, the description carries the full burden of describing returns, and it does so thoroughly: liked-share, tier/rank, distribution, related games, and tag counts. It also covers how to obtain the input and how to cite the result, leaving no gap an agent needs filled before calling it.
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% for the single appid parameter, and the schema description already says to resolve names with search_games, so the description's identical instruction adds no new semantics. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
States a specific verb+resource combination: it returns the community consensus for a single game (liked-share, tier/rank, opinion distribution, co-liked/co-disliked games, qualitative tags). It is clearly differentiated from the sibling search_games, which is named as the name-resolution step, and from versus, which the framing implies is a comparison rather than a single-game lookup.
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?
Gives concrete trigger questions ("how popular / well-liked is X?", "games similar to X") and an explicit prerequisite workflow (pass a Steam appid, resolve names with search_games first). It does not state a when-not-to-use condition relative to versus, so the guidance is clear but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve one or more game names to their Steam appids on needmoar.games. Call this first to turn a title like "Hollow Knight" into the numeric appid the versus and game_detail tools need. Accepts several names at once — pass every game the user mentioned in a single call and match each to its result.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max matches to return per name (1-10, default 5). | |
| queries | Yes | Game names to look up. Pass every title the user mentioned at once. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety and idempotency. The description adds that it accepts multiple names and returns matches, but does not elaborate on response format or potential errors. Given annotations carry the safety burden, the description adds moderate value.
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 three sentences, each contributing distinct value: purpose, usage order, and batching instruction. No redundant or extraneous information.
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 lookup tool with two parameters and full annotation coverage, the description covers the essential context: when to use, how to batch, and the output mapping. However, it could improve by briefly describing the response structure (e.g., array of matches with appid and name).
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%; both parameters have inline descriptions. The description reiterates the batching advice for 'queries' and default for 'limit', but does not add significant new meaning beyond the schema.
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 title 'Resolve games to Steam appids' and description clearly state the tool's purpose: converting game names to numeric appids. It identifies the specific resource (needmoar.games) and distinguishes from siblings (versus, game_detail) which require appids as input.
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?
Description explicitly advises to call this tool first and to batch all user-mentioned game names in one call. However, it does not provide explicit guidance on when not to use the tool or alternatives beyond the implied sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Head-to-head verdict for two games on needmoar.games: which one players like more, each game's community score (the share of a library it beats) and rank, and the full distribution of opinions on both. Use this to answer "do people prefer A or B?". Pass Steam appids — resolve names with search_games first. The response links to the matching /vs page you can cite.
| Name | Required | Description | Default |
|---|---|---|---|
| appid_a | Yes | Steam appid of the first game (resolve names with search_games). | |
| appid_b | Yes | Steam appid of the second game. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds context about what the response contains (community score, rank, full distribution of opinions, link to /vs page), fully disclosing behavior beyond annotations.
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, dense sentence that efficiently conveys purpose, inputs, output, and usage. No redundancy or unnecessary words.
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 tool with no output schema, the description adequately explains the return content: community score, rank, opinion distribution, and a link. It also mentions the source (needmoar.games) and the prerequisite step (use search_games), making it complete for selection and invocation.
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 baseline is 3. The description adds usage guidance ('resolve names with search_games first' and clarifies that appids are Steam appids), providing value beyond schema.
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 it provides a head-to-head verdict for two games, including community scores, ranks, and opinion distributions. It distinguishes from sibling tools by mentioning search_games for name resolution, indicating this tool is for comparison after IDs are obtained.
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 explicitly says to pass Steam appids and resolve names with search_games first, providing clear guidance on when to use this tool and when to use the sibling. It also states the purpose: to answer 'do people prefer A or B?'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
game_detailsearch_gamesversusSteam backlog, account value, buy-or-skip verdicts and Steam Machine checks. Hosted, keyless.
The gaming attention graph: Steam players, Twitch live viewers, aggro ratio, hype, history.
Steam games counted by their mechanics: earnings, launch ranges, price bands, crowds, closest games.
Steam concurrent players by game over time, monthly trends and growth. Free key at trendsmcp.ai
Add one secure layer between your agents and this server.
