imho.run game recommendations
Server Details
Steam games like any game you name, facts about a game, and finding a game from a description.
- Status
- Healthy
- Uptime
- 99.8% over 22 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
Scored across 8 tools
Descriptions do heavy lifting with explicit cross-references ('use games_like for one game, recommend for 2-3', 'not for facts about one game'). Real overlap remains between games_like and recommend (both rank similar games) and between find_game_by_description and search_games, but the boundaries are spelled out well enough that an agent can choose correctly.
All names are lowercase snake_case, so the formatting style is consistent, but the semantic pattern is mixed: verb_noun (find_game_by_description, search_games), bare verb (recommend), and bare nouns (game_facts, new_releases, trending). Readable, but not a predictable convention an agent can generalize from.
Eight tools is well within the ideal range for a recommendation service, and each covers a distinct discovery path (identify, search, facts, similar, personalized, new, trending, filtered recommend). No tool feels redundant padding.
The surface covers the full recommendation journey: identify a game, look up facts, find similar games, get personalized library picks, browse new/trending, and refine with liked/disliked feedback. Minor gaps exist (e.g. no way to browse by genre/tag directly or manage saved picks), but agents can work around them.
Available Tools
8 toolsfind_game_by_descriptionFind a game by descriptionARead-onlyInspect
Identify a game from a description of what the user remembers (plot, look, platform, era). Returns ranked candidates with a reason each, a confidence, and find_game_url: imho.run's /find-game page with the description filled in (the user presses the button; nothing runs by itself). Pass what the user said about the platform, the release years and the camera as platform, year_min / year_max and perspective instead of leaving them only in the text. When confidence is not high or no result fits, give the user find_game_url so they can add details there. Slow (LLM) and rate-limited: use it only when the user does not know the title; for games similar to a known game use games_like or recommend. Games rated for adults only (explicit sexual content) are not covered; filtering is best effort.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| platform | No | Where the user played it, if they said (a platform family). | |
| year_max | No | Latest plausible release year, if the user gave an era. | |
| year_min | No | Earliest plausible release year, if the user gave an era. | |
| description | Yes | What the user remembers about the game, in their words. | |
| perspective | No | Camera: first person, third person, top-down or side view. |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | |
| source | Yes | |
| results | Yes | |
| tool_url | Yes | |
| confidence | No | |
| attribution | Yes | |
| find_game_url | No | /find-game with the description filled in, for the user to refine. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety/idempotency; the description adds substantial behavioral context beyond them: it is slow (LLM-backed) and rate-limited, the returned find_game_url is user-initiated ('nothing runs by itself'), adult-only content is not covered, and filtering is best effort. These are exactly the traits an agent needs to set expectations and avoid over-calling.
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?
Front-loaded with the core purpose, and every clause carries actionable content. It is dense and slightly packs routing, latency, parameter hygiene and coverage caveats into one block, but there is no filler. Minor redundancy in restating the find_game_url fallback after already defining the field.
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?
Even though an output schema exists, the description usefully previews the return shape (ranked candidates with a reason each, a confidence, and find_game_url) and pairs it with the confidence-low workflow. For a rate-limited, non-deterministic tool it covers latency, coverage limits, and the human hand-off.
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 83%, so the schema already documents lang, platform, year bounds, perspective and description. The description still adds real guidance by telling the agent to hoist platform, release years and camera out of free text into platform, year_min/year_max and perspective, which is a usage decision the schema cannot express.
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 and resource ('Identify a game from a description of what the user remembers') and enumerates the memory dimensions (plot, look, platform, era). It also names the sibling tools it is not (games_like, recommend), so an agent can route without opening other schemas.
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?
Explicit when-to-use ('only when the user does not know the title'), explicit alternatives for the contrasting case ('for games similar to a known game use games_like or recommend'), plus a fallback path when confidence is low or nothing fits. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
game_factsGame factsARead-onlyIdempotentInspect
Public facts about one Steam game: year, developers, genres, top tags, price, Steam Deck status, review numbers, a review-mined summary and links. For a few single-player games, coop_via_mod names a reviewed fan mod for co-op, with caveats. Use it to answer questions about a game the user names; for similar games use games_like or recommend. Games rated for adults only (explicit sexual content) are not covered; filtering is best effort.
| Name | Required | Description | Default |
|---|---|---|---|
| game | Yes | Game name (typos and Russian names are fine), Steam appid or Steam store URL. | |
| lang | No | Language of the `why` lines. | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| game | Yes | |
| lang | Yes | |
| query | Yes | |
| source | Yes | |
| attribution | Yes | |
| generated_at | Yes | |
| other_matches | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: the special coop_via_mod field 'with caveats' and the 'filtering is best effort' limitation on adult content. It stops short of discussing rate limits or caching, hence not a 5.
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?
Front-loaded with what the tool returns, then usage routing, then caveats — a logical order where every sentence earns its place. The field enumeration is long but functional; only minor trimming is possible.
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?
Even though an output schema exists, the description covers the tool's edge cases (coop_via_mod caveats, filtering limits), routing to siblings, and the input's accepted forms. An agent has everything needed to select and call it correctly.
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 the schema already documents both params, including that typos/Russian names/appids/URLs are accepted for `game`. The description adds no parameter syntax or format detail beyond the schema, so the baseline 3 applies.
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?
Opens with a specific verb+resource ('Public facts about one Steam game') and enumerates the return fields (year, developers, genres, tags, price, Deck status, reviews, summary, links), plus a non-obvious optional field (coop_via_mod). An agent can distinguish it from search_games or trending without opening any schema.
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?
'Use it to answer questions about a game the user names; for similar games use games_like or recommend' explicitly names the alternatives and the condition that routes to each. It also states a when-not ('adults-only games are not covered'), leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
games_likeGames like XARead-onlyIdempotentInspect
Steam games similar to ONE game, ranked by imho.run's recommender (the list on that game's imho.run page), each with a one-line reason, price, Steam Deck status, year, review numbers, the imho.run page URL and the Steam URL. Use it for 'games like X', optionally only free, co-op or Steam Deck games. Use recommend instead when the user names 2-3 games, wants other filters (no PvP, no microtransactions, release years, niche) or describes what they want in words. Games rated for adults only (explicit sexual content) are not covered; filtering is best effort.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| coop | No | Only co-op games. | |
| free | No | Only free games. | |
| game | Yes | Game name (typos and Russian names are fine), Steam appid or Steam store URL. | |
| lang | No | Language of the `why` lines. | en |
| coop_mode | No | Kind of co-op (implies coop): online co-op (Remote Play Together does not count), or local same-screen / split-screen co-op. | |
| steam_deck | No | Steam Deck verified, or playable-or-better. |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | |
| seed | Yes | |
| query | Yes | |
| source | Yes | Always "imho.run". |
| filters | Yes | |
| results | Yes | |
| list_url | Yes | The same list on imho.run. |
| attribution | Yes | |
| generated_at | Yes | |
| other_matches | No | Other games the query could mean; pass one's appid as `q` to switch. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds real context beyond that: the ranking comes from imho.run's page, filtering is best-effort, and adult (explicit content) games are excluded — useful limitations an agent cannot infer from the 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?
Front-loads the core purpose, then usage and the alternative. Efficient, though the enumerated list of return fields is somewhat redundant given an output schema exists. Every sentence still carries routing or limitation 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?
With seven parameters, one required, and an output schema present, the description supplies everything an agent needs: purpose, scope, filter behavior, the sibling to prefer in other cases, and coverage limitations (best-effort, no adult content). Nothing material is missing.
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 86%, so the schema documents most parameters (coop, free, coop_mode, steam_deck semantics all live in schema). The description only echoes the free/co-op/Steam Deck filter intent without adding syntax beyond the schema, so 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?
States a specific verb+resource (Steam games similar to ONE game) and identifies the ranking source (imho.run's recommender). It explicitly distinguishes itself from the sibling `recommend` by scope (one game vs 2-3 games).
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 explicit when-to-use ('games like X', optional free/co-op/Steam Deck filters) and names the alternative `recommend` with the exact conditions that select it (2-3 games, other filters, natural-language description). Also states an exclusion (adults-only games not covered).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
library_recsRecommendations from a Steam libraryARead-onlyIdempotentInspect
Steam games for a player, ranked against their own public Steam library (what they play most), the way imho.run's library mode does it; owned games are left out. Use it when the user gives their Steam profile and wants picks for their taste in general; for 'games like X' use games_like or recommend. Takes a SteamID64 or a steamcommunity.com/profiles/ link (not a custom /id/ name) and works only for public profiles imho.run already has; otherwise it returns one 'unavailable' error with a link the user can open to paste their profile. Each pick names the most-played game it is closest to (similar_to). Games rated for adults only (explicit sexual content) are not covered; filtering is best effort.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| lang | No | Language of the `why` lines. | en |
| filters | No | All optional, same meaning as in recommend. | |
| profile | Yes | SteamID64 or steamcommunity.com/profiles/<SteamID64> link. |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | |
| source | Yes | |
| filters | Yes | |
| results | Yes | |
| based_on | No | The profile's most-played games the reasons refer to. |
| tool_url | Yes | imho.run's library mode, where the user can paste the link. |
| attribution | Yes | |
| generated_at | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: owned games are omitted, only public profiles imho.run already has will work, failure returns a single 'unavailable' error with an actionable link, and adult-content filtering is best-effort. These are exactly the operational traits an agent needs.
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?
Three dense sentences, front-loaded with the core purpose before routing and constraints. Every clause carries operational information, though the middle sentence packs profile format, availability, and error behavior tightly enough to be slightly heavy.
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?
An output schema exists, so return values need not be described, and the description covers the key limits and failure mode. Minor gaps remain: the 'why' lines referenced indirectly by lang are never explained here, and filter semantics are delegated to recommend.
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?
With 75% schema coverage the schema carries most of the load, but the description adds real meaning: profile must be a SteamID64 or /profiles/<SteamID64> link, not a custom /id/ name. The filters object is handled by cross-reference ('same meaning as in recommend') rather than restated, which is efficient but leaves lang and n purely to 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?
States a specific verb+resource: Steam game recommendations ranked against the player's own public library, with owned games excluded. It explicitly contrasts itself with games_like and recommend, so an agent can distinguish it from siblings without opening a schema.
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 an explicit trigger (user supplies a Steam profile and wants general picks for their taste) and an explicit exclusion that routes to alternatives ('for games like X' use games_like or recommend). It also states the profile-availability precondition and what happens when it is unmet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
new_releasesNew Steam releasesARead-onlyIdempotentInspect
Games released on Steam in the last 30 days that players rate well (70%+ positive, 50+ positive reviews), or with upcoming the upcoming games that have a release date; optionally co-op only. The site's New releases list, with price, Steam Deck status, release date and links. Released games carry release_kind: new, or ea_exit for a game that just left Early Access (its 1.0; it was playable before), so call those 'out of Early Access', not new. ea_exits: include (default), exclude (brand-new games only) or only. Use it for 'what's new / coming out'; for what is gaining players now use trending. Games rated for adults only (explicit sexual content) are not covered; filtering is best effort.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| coop | No | ||
| lang | No | Language of the `why` lines. | en |
| ea_exits | No | Games that just left Early Access: include them, exclude them (only brand-new launches) or return only them. | include |
| upcoming | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| coop | No | |
| kind | Yes | |
| lang | Yes | |
| source | Yes | |
| results | Yes | |
| ea_exits | No | The Early Access exits filter this list was built with. |
| page_url | Yes | |
| attribution | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context on top: the inclusion thresholds (70%+ positive, 50+ positive reviews), the coverage caveat that adult-only titles are excluded and filtering is best-effort, and the semantic distinction between a `new` release and an `ea_exit`.
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?
Front-loaded with the core definition and alternative-sibling routing, and nearly every clause earns its place. The first sentence is dense with stacked qualifiers and parentheticals, making it slightly harder to parse than necessary.
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 5-optional-param list tool with an output schema and read-only annotations, it covers purpose, filtering semantics, edge cases, and the one sibling overlap. Return contents (price, Deck status, release date, links, `why` lines) are noted, and the output schema carries the rest.
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 only 40%, so the description must compensate and largely does: it explains `upcoming`, `coop` (co-op only), and the meaning of every `ea_exits` enum value beyond the schema's one-liner. It never mentions `n`, leaving the result-count parameter documented only by its default/max in 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?
States a specific verb+resource+scope: Steam games released in the last 30 days meeting named rating/review thresholds, plus an `upcoming` mode. It explicitly separates itself from the sibling `trending` ('for what is gaining players now use trending'), so an agent can route without opening any schema.
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 explicit when-to-use ('what's new / coming out') and the alternative with its condition ('what is gaining players now use trending'). It also prescribes how to describe results via the `ea_exit` distinction ('call those out of Early Access, not new').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommendRecommend Steam gamesARead-onlyIdempotentInspect
Steam games for someone who likes 1-3 given games, ranked by imho.run's recommender: the list imho.run's own tool shows for those games and filters. Use it instead of games_like when the user names several games, wants filters beyond free / co-op / Steam Deck (no PvP, no microtransactions, no grind, not too hard, no Early Access, release years, more niche or more popular), or says what they want in words: pass that as preferences ('cozy base building, no combat'); the result says which Steam tags it was read as. When the user reacts to the picks, call it again with liked / disliked: liked games join the seeds, disliked ones never come back. Each pick has a one-line reason naming the seed it is closest to (similar_to), price, Steam Deck status, year, reviews, the imho.run URL and the Steam URL, plus tool_url (these games in imho.run's tool). Not for naming a game from a description (find_game_by_description) or facts about one game (game_facts). Games rated for adults only (explicit sexual content) are not covered; filtering is best effort.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| lang | No | Language of the `why` lines. | en |
| liked | No | Other games the user said they liked (e.g. from earlier answers). They fill free seed slots after `seeds` (3 in all); the rest are listed in `ignored`. | |
| seeds | Yes | 1-3 games the user likes: names, Steam appids or Steam URLs. | |
| filters | No | All optional. Leave out what the user did not ask for. | |
| disliked | No | Games the user disliked or already played: never recommended. Pass earlier picks the user rejected to get fresh ones. | |
| preferences | No | What the user wants or wants to avoid, in their words (any language), e.g. 'dragons and crafting, no horror, no grind'. Read as Steam tags. |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | |
| query | Yes | |
| seeds | Yes | |
| source | Yes | |
| filters | Yes | |
| ignored | No | liked / disliked games not used: no match, or liked past the 3 seed slots. |
| results | Yes | |
| tool_url | Yes | imho.run's tool with these games picked; the user can tune filters there. |
| attribution | Yes | |
| preferences | No | How `preferences` were read as Steam tags. |
| generated_at | Yes | |
| preferred_tags | No | |
| preferences_applied | No | null without `preferences`; false when they could not be read. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it is a safe, idempotent read; the description goes further by disclosing the ranking engine, the seed-slot behavior of liked games (fill free slots after seeds; overflow listed in ignored), the 'disliked never come back' rule, the per-pick fields returned, and a coverage limit (adult-only explicit games not covered; filtering best effort). These are traits not derivable from the 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?
Purpose, source and sibling contrast are front-loaded, and nearly every clause carries operative detail. It is a single dense block that runs long, so an agent must parse carefully, but little is 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 an output schema present, return values need not be explained, yet the description summarizes the pick fields anyway (similar_to, price, Deck status, year, reviews, imho.run URL, Steam URL, tool_url). Combined with filter guidance, exclusions and coverage caveats, nothing an agent needs to call this correctly is missing.
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 86%, so the structured field descriptions carry most of the load (baseline 3). The description adds real meaning for preferences ('read as Steam tags', any language, and the result reports which tags it inferred) and for the feedback semantics of liked/disliked, but does not restate filter syntax.
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 (Steam game recommendations seeded by 1-3 games), names the ranking source (imho.run's recommender) and the output shape. It explicitly contrasts with the sibling games_like, so an agent can select between them without opening either schema.
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 explicit when-to-use conditions versus games_like (several named games, filters beyond free/co-op/Deck, natural-language descriptions of what the user wants) and explicit when-not cases (find_game_by_description for naming a game from a description, game_facts for single-game facts). The feedback-loop invocation pattern is also spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_gamesSearch Steam games by titleARead-onlyIdempotentInspect
Find Steam games by title (typos, partial names, Russian names and acronyms are fine): appid, year, imho.run page and Steam link for each match. Use it to check which game the user means or to get an appid; the other tools also accept names directly. For a game the user can only describe, use find_game_by_description. Games rated for adults only (explicit sexual content) are not covered; filtering is best effort.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| source | Yes | |
| results | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the read-only/idempotent/closed-world profile; the description adds matching tolerance (typos, partial names, Russian names, acronyms) and an important content limitation (adult-only games not covered, filtering best effort). These are behavioral traits an agent cannot infer from the structured fields.
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?
Front-loads purpose and return fields, then adds usage routing and caveats in three dense sentences with no filler. Slightly packed with parenthetical clauses, but every clause adds needed 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?
An output schema exists, so return values needn't be explained, yet the description still lists them helpfully. It covers purpose, routing, matching behavior and a content caveat; the only gap is the meaning/limits of the `n` parameter.
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 0%, so the description carries the burden: it explains query semantics well (fuzzy/typo/acronym tolerance). However, the `n` result-count parameter is never mentioned, and its bounds only exist as raw schema constraints, leaving half the parameter surface undocumented in prose.
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 (find Steam games by title) and immediately enumerates the returned fields (appid, year, imho.run page, Steam link). It also explicitly differentiates itself from the sibling find_game_by_description, so an agent can route without opening the schema.
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 use cases ('check which game the user means or to get an appid') and names the alternative for the contrasting case ('For a game the user can only describe, use find_game_by_description'). It even notes that other tools accept names directly, removing the need to call this first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendingTrending on SteamARead-onlyIdempotentInspect
Steam games trending right now (imho.run/trending): rising = established games gaining reviews and players against their own recent baseline, breakouts = new games taking off. Each has reviews this week, growth in %, price, Steam Deck status and links. Use it for 'what's hot / popular right now on Steam'; for new releases use new_releases, for games like a given game use games_like. Games rated for adults only (explicit sexual content) are not covered; filtering is best effort.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| kind | No | rising | |
| lang | No | Language of the `why` lines. | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| lang | Yes | |
| source | Yes | |
| status | Yes | collecting: the lists are not ready yet; results is empty. |
| results | Yes | |
| page_url | Yes | |
| updated_at | No | |
| attribution | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — and it does, by enumerating the returned fields (reviews this week, growth %, price, Steam Deck status, links) and disclosing a coverage limitation: adult-only games are excluded and filtering is best effort. That caveat is real behavioral information an agent needs. It stops short of explaining ordering or result-count behavior, so not a 5.
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?
Dense but front-loaded: the core purpose comes first, then mode definitions, then the alternative routing, then the caveat. Every sentence carries weight, though the parenthetical URL and the field enumeration make it slightly list-heavy.
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?
An output schema exists, so return structure needn't be spelled out, yet the description still summarizes the payload. Combined with the enum semantics and the explicit sibling routing, an agent has what it needs to select and call this correctly; only ordering/pagination behavior is unaddressed.
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 only 33% (only `lang` is documented in the schema), so the description must compensate — and it does for the most important parameter by explaining what `rising` and `breakouts` actually mean, which the bare enum values do not convey. `n` and the return-count cap are left to the schema, which handles them adequately.
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 ('Steam games trending right now') and goes further by defining its two modes: `rising` as established games gaining against their own recent baseline, `breakouts` as new games taking off. An agent can distinguish this from new_releases and games_like without opening any schema.
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 an explicit trigger ('what's hot / popular right now on Steam') and names the alternatives with the condition that selects each: new_releases for new releases, games_like for games similar to a given one. This is exactly the when/when-not/alternatives structure.
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.
8 tool updates
- Changed
find_game_by_description1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "attribution": { + "title": "Attribution", + "type": "string" + }, + "confidence": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Confidence" + }, + "find_game_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "/find-game with the description filled in, for the user to refine.", + "title": "Find Game Url" + }, + "lang": { + "enum": [ + "en", + "ru" + ], + "title": "Lang", + "type": "string" + }, + "results": { + "items": { + "properties": { + "igdb_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Igdb Url" + }, + "name": { + "title": "Name", + "type": "string" + }, + "platforms": { + "items": { + "type": "string" + }, + "title": "Platforms", + "type": "array" + }, + "rank": { + "title": "Rank", + "type": "integer" + }, + "steam_appid": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Steam Appid" + }, + "steam_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Steam Url" + }, + "summary": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Summary" + }, + "url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Its imho.run page, when we have one.", + "title": "Url" + }, + "why": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Why" + }, + "year": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Year" + } + }, + "required": [ + "rank", + "name" + ], + "title": "AgentFindItem", + "type": "object" + }, + "title": "Results", + "type": "array" + }, + "source": { + "title": "Source", + "type": "string" + }, + "tool_url": { + "title": "Tool Url", + "type": "string" + } + }, + "required": [ + "source", + "attribution", + "lang", + "results", + "tool_url" + ], + "title": "FindGameResponse", + "type": "object" +}
- Changed
game_facts1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "attribution": { + "title": "Attribution", + "type": "string" + }, + "game": { + "properties": { + "appid": { + "title": "Appid", + "type": "integer" + }, + "audience_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "For game developers: what this game's players also play (co-play overlap from public Steam libraries). Only for well-sampled games.", + "title": "Audience Url" + }, + "coming_soon": { + "default": false, + "title": "Coming Soon", + "type": "boolean" + }, + "coop_via_mod": { + "anyOf": [ + { + "description": "Reviewed fan-mod co-op for a game without full official co-op (#665).", + "properties": { + "caveats": { + "description": "Always pass these on: unofficial mod, save and anti-cheat risk.", + "items": { + "type": "string" + }, + "title": "Caveats", + "type": "array" + }, + "last_checked": { + "title": "Last Checked", + "type": "string" + }, + "maturity": { + "enum": [ + "stable", + "beta" + ], + "title": "Maturity", + "type": "string" + }, + "max_players": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Max Players" + }, + "mod_name": { + "title": "Mod Name", + "type": "string" + }, + "mod_url": { + "description": "The mod's official project page. Link this, never a mirror.", + "title": "Mod Url", + "type": "string" + }, + "note": { + "title": "Note", + "type": "string" + }, + "note_lang": { + "default": "en", + "enum": [ + "en", + "ru" + ], + "title": "Note Lang", + "type": "string" + }, + "official_coop_is_summon_only": { + "default": false, + "title": "Official Coop Is Summon Only", + "type": "boolean" + }, + "scope": { + "enum": [ + "full_campaign", + "partial_campaign", + "shared_world", + "sandbox_servers" + ], + "title": "Scope", + "type": "string" + }, + "scope_text": { + "title": "Scope Text", + "type": "string" + }, + "status": { + "description": "ok = released after the last game patch; frozen_game = the game is no longer patched; lagging = the game was patched after the mod; check_due = not rechecked in 90+ days.", + "enum": [ + "ok", + "frozen_game", + "lagging", + "check_due" + ], + "title": "Status", + "type": "string" + } + }, + "required": [ + "mod_name", + "mod_url", + "scope", + "scope_text", + "maturity", + "status", + "last_checked", + "note" + ], + "title": "AgentCoopViaMod", + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Only for listed single-player games: co-op through a reviewed fan mod." + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Steam's short description (English).", + "title": "Description" + }, + "description_lang": { + "default": "en", + "title": "Description Lang", + "type": "string" + }, + "developers": { + "items": { + "type": "string" + }, + "title": "Developers", + "type": "array" + }, + "genres": { + "items": { + "type": "string" + }, + "title": "Genres", + "type": "array" + }, + "name": { + "title": "Name", + "type": "string" + }, + "price": { + "properties": { + "amount": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Price as last scraped from the US Steam store.", + "title": "Amount" + }, + "currency": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Currency" + }, + "is_free": { + "title": "Is Free", + "type": "boolean" + }, + "text": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "\"Free\", \"29.99 USD\" or null when unknown.", + "title": "Text" + } + }, + "required": [ + "is_free" + ], + "title": "AgentPrice", + "type": "object" + }, + "release_date": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Release Date" + }, + "reviews": { + "anyOf": [ + { + "properties": { + "positive_pct": { + "description": "Share of positive Steam reviews, 0-100.", + "title": "Positive Pct", + "type": "integer" + }, + "total": { + "description": "Steam user reviews.", + "title": "Total", + "type": "integer" + } + }, + "required": [ + "total", + "positive_pct" + ], + "title": "AgentReviews", + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "similar_url": { + "description": "Games like this one on imho.run.", + "title": "Similar Url", + "type": "string" + }, + "steam_deck": { + "enum": [ + "verified", + "playable", + "unsupported", + "unknown" + ], + "title": "Steam Deck", + "type": "string" + }, + "steam_url": { + "title": "Steam Url", + "type": "string" + }, + "summary": { + "anyOf": [ + { + "properties": { + "co_op": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Co Op" + }, + "dealbreakers": { + "items": { + "type": "string" + }, + "title": "Dealbreakers", + "type": "array" + }, + "difficulty": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Difficulty" + }, + "hooks": { + "items": { + "type": "string" + }, + "title": "Hooks", + "type": "array" + }, + "language": { + "default": "en", + "title": "Language", + "type": "string" + }, + "length": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Length" + }, + "session_shape": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Session Shape" + }, + "tagline": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Tagline" + } + }, + "title": "AgentFactsSummary", + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Review-mined summary (English), when we have one." + }, + "tags": { + "description": "Top Steam user tags by votes.", + "items": { + "type": "string" + }, + "title": "Tags", + "type": "array" + }, + "url": { + "title": "Url", + "type": "string" + }, + "year": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Year" + } + }, + "required": [ + "appid", + "name", + "url", + "similar_url", + "steam_url", + "price", + "steam_deck" + ], + "title": "AgentGameFacts", + "type": "object" + }, + "generated_at": { + "title": "Generated At", + "type": "string" + }, + "lang": { + "enum": [ + "en", + "ru" + ], + "title": "Lang", + "type": "string" + }, + "other_matches": { + "items": { + "properties": { + "appid": { + "title": "Appid", + "type": "integer" + }, + "name": { + "title": "Name", + "type": "string" + } + }, + "required": [ + "appid", + "name" + ], + "title": "AgentMatch", + "type": "object" + }, + "title": "Other Matches", + "type": "array" + }, + "query": { + "title": "Query", + "type": "string" + }, + "source": { + "title": "Source", + "type": "string" + } + }, + "required": [ + "query", + "source", + "attribution", + "lang", + "game", + "generated_at" + ], + "title": "GameFactsResponse", + "type": "object" +}
- Changed
games_like1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "attribution": { + "title": "Attribution", + "type": "string" + }, + "filters": { + "properties": { + "coop": { + "default": false, + "title": "Coop", + "type": "boolean" + }, + "coop_mode": { + "anyOf": [ + { + "enum": [ + "online", + "local" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Coop Mode" + }, + "deck": { + "anyOf": [ + { + "enum": [ + "verified", + "playable" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Deck" + }, + "free": { + "default": false, + "title": "Free", + "type": "boolean" + } + }, + "title": "AgentFilters", + "type": "object" + }, + "generated_at": { + "title": "Generated At", + "type": "string" + }, + "lang": { + "enum": [ + "en", + "ru" + ], + "title": "Lang", + "type": "string" + }, + "list_url": { + "description": "The same list on imho.run.", + "title": "List Url", + "type": "string" + }, + "other_matches": { + "description": "Other games the query could mean; pass one's appid as `q` to switch.", + "items": { + "properties": { + "appid": { + "title": "Appid", + "type": "integer" + }, + "name": { + "title": "Name", + "type": "string" + } + }, + "required": [ + "appid", + "name" + ], + "title": "AgentMatch", + "type": "object" + }, + "title": "Other Matches", + "type": "array" + }, + "query": { + "title": "Query", + "type": "string" + }, + "results": { + "items": { + "properties": { + "appid": { + "title": "Appid", + "type": "integer" + }, + "genres": { + "items": { + "type": "string" + }, + "title": "Genres", + "type": "array" + }, + "name": { + "title": "Name", + "type": "string" + }, + "price": { + "properties": { + "amount": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Price as last scraped from the US Steam store.", + "title": "Amount" + }, + "currency": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Currency" + }, + "is_free": { + "title": "Is Free", + "type": "boolean" + }, + "text": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "\"Free\", \"29.99 USD\" or null when unknown.", + "title": "Text" + } + }, + "required": [ + "is_free" + ], + "title": "AgentPrice", + "type": "object" + }, + "rank": { + "title": "Rank", + "type": "integer" + }, + "reviews": { + "anyOf": [ + { + "properties": { + "positive_pct": { + "description": "Share of positive Steam reviews, 0-100.", + "title": "Positive Pct", + "type": "integer" + }, + "total": { + "description": "Steam user reviews.", + "title": "Total", + "type": "integer" + } + }, + "required": [ + "total", + "positive_pct" + ], + "title": "AgentReviews", + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "steam_deck": { + "enum": [ + "verified", + "playable", + "unsupported", + "unknown" + ], + "title": "Steam Deck", + "type": "string" + }, + "steam_url": { + "title": "Steam Url", + "type": "string" + }, + "url": { + "description": "Link this when you mention the game: its page on imho.run.", + "title": "Url", + "type": "string" + }, + "why": { + "description": "One short sentence: why this game is like the seed.", + "title": "Why", + "type": "string" + }, + "year": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Year" + } + }, + "required": [ + "rank", + "appid", + "name", + "url", + "steam_url", + "why", + "price", + "steam_deck" + ], + "title": "AgentPick", + "type": "object" + }, + "title": "Results", + "type": "array" + }, + "seed": { + "properties": { + "appid": { + "title": "Appid", + "type": "integer" + }, + "name": { + "title": "Name", + "type": "string" + }, + "steam_url": { + "title": "Steam Url", + "type": "string" + }, + "url": { + "description": "The game's page on imho.run (the full list of similar games).", + "title": "Url", + "type": "string" + } + }, + "required": [ + "appid", + "name", + "url", + "steam_url" + ], + "title": "AgentSeed", + "type": "object" + }, + "source": { + "description": "Always \"imho.run\".", + "title": "Source", + "type": "string" + } + }, + "required": [ + "query", + "source", + "attribution", + "seed", + "lang", + "filters", + "list_url", + "results", + "generated_at" + ], + "title": "GamesLikeResponse", + "type": "object" +}
- Added
library_recs - Added
new_releases - Added
recommend - Added
search_games - Added
trending
1 tool update
- Changed
find_game_by_description4 fields changed- added
Input schema / properties / perspectiveAdded value: +{ + "description": "Camera: first person, third person, top-down or side view.", + "enum": [ + "first", + "third", + "top_down", + "side" + ], + "type": "string" +} - added
Input schema / properties / platformAdded value: +{ + "description": "Where the user played it, if they said (a platform family).", + "enum": [ + "pc", + "playstation", + "xbox", + "nintendo", + "sega", + "mobile", + "browser", + "arcade" + ], + "type": "string" +} - added
Input schema / properties / year_maxAdded value: +{ + "description": "Latest plausible release year, if the user gave an era.", + "maximum": 2035, + "minimum": 1970, + "type": "integer" +} - added
Input schema / properties / year_minAdded value: +{ + "description": "Earliest plausible release year, if the user gave an era.", + "maximum": 2035, + "minimum": 1970, + "type": "integer" +}
1 tool update
- Changed
games_like1 field changed- added
Input schema / properties / coop_modeAdded value: +{ + "description": "Kind of co-op (implies coop): online co-op (Remote Play Together does not count), or local same-screen / split-screen co-op.", + "enum": [ + "online", + "local" + ], + "type": "string" +}
3 tool updates
- First observed
find_game_by_description - First observed
game_facts - First observed
games_like
Related MCP Connectors
Live Steam market data for AI agents: top sellers, deals, player counts. Paid per call via x402.
Steam backlog, account value, buy-or-skip verdicts and Steam Machine checks. Hosted, keyless.
Steam game, Agoda/Booking.com hotel and Google Play app reviews with optional AI insight reports.
Ranks Steam games by how much players like them, learned from head-to-head duels.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceHelps users choose which Steam games to play or buy by analyzing their library, playtime, discounts, and reviews.-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to recommend Steam games from natural language by searching games, finding similar titles, filtering by tags and platform, and retrieving detailed game metadata.1MIT
- AlicenseAqualityDmaintenanceLet your agent control your steam client. e.g. "pick a strategy game from my library and launch it"1719 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to research Steam games by fetching regional prices, reviews, current player counts, store charts, and news through public endpoints without an API key.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.