01Safety
30.0 / 30
What changed in the harness
Selection accuracy 95%, destructive-action safety rate 100% (baseline only -- no rewrite pass applied).
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
26.9 / 30
03Economics
8.3 / 20
04Discoverability
12.1 / 20
Highest-impact fix
Estimated gain +12 pointsReduce the tool-definition and task token payload
Consolidate overlapping tools and trim repetitive schema text while preserving behavior, parameter, and return semantics.
Description evidence
Defects and rewrites.
0 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
| No description defects were flagged in this assessment. | ||
Selection evidence
Confusable tool pairs.
8 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
get_game_achievements |
get_player_achievements |
high | Both take appid and return achievement lists, with overlapping vocabulary (achievements, unlock, appid, list). A task like 'show me the achievements for Elden Ring' is ambiguous: get_game_achievements returns the full catalog list with names/descriptions, while get_player_achievements returns a specific player's unlocked progress for one game. The agent can easily pick the wrong one when the user doesn't explicitly say whose progress vs. the game's whole list. |
get_global_achievements |
get_player_achievements |
medium | Both mention achievements, unlock, appid and player. A task like 'what's the unlock rate for achievements in game X' could select get_player_achievements (which shows one player's unlocked counts) instead of get_global_achievements (rarity across all players), or vice versa for 'which achievements has this player gotten'. Natural phrasing about 'achievement unlocks' is genuinely ambiguous. |
get_game |
get_game_achievements |
medium | get_game advertises a 'highlighted-achievements sample (achievements_highlighted)' and requires no API key, while get_game_achievements needs STEAM_API_KEY for the full list. A task like 'what achievements does game X have' could be answered with get_game's small sample, especially since a keyless option looks more attractive; the wrong member yields only a subset of achievement data. |
get_prices |
get_items |
medium | Both batch-price a list of appids and each description cross-references the other. A task like 'check prices/reviews for these games' is ambiguous: get_items adds review %, tags and compat but caps at 100 appids, while get_prices handles up to 500 but returns price only. Picking get_prices is wrong when details are wanted, and get_items fails for lists over 100; intent alone doesn't disambiguate. |
search_games |
discover_games |
medium | A user task phrased 'search Steam for ...' points at search_games by name, but it only matches by title term, while filter-style tasks (e.g. 'search for well-reviewed games on sale') actually need discover_games. Conversely 'find a specific game by name' might wrongly pull discover_games, which has no title parameter. The word 'search' vs 'find/discover' drives the selection and is not reliable. |
discover_games |
get_recommended_games |
medium | Both return game lists with price/review/compat, and the descriptions share catalog/tags/review vocabulary. A task like 'recommend me well-reviewed games on sale' could select discover_games (needs the user to name filters, keyless) when get_recommended_games (taste inferred from the player's library) is what's implied, or vice versa when explicit filters are given — either pick returns the wrong flavor of results. |
get_specials |
get_featured |
medium | Both describe Steam store front-page listings and share tokens (front, page, special, store, price). get_featured includes the specials section plus top sellers/new releases/coming soon, while get_specials is discounts only. A task like 'what's on sale / what's featured on the Steam store right now' is ambiguous — answering the other's intent yields missing or extraneous sections. |
get_game_reviews |
get_game_news |
low | Both take appid and return 'recent' items with a limit param. A vague task like 'what's the latest on game X' is ambiguous between recent user reviews and news/patch notes; the shared 'recent' wording can pull the wrong member, though 'news' vs 'reviews' usually disambiguates. |
Compare the field