01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→100, token cost up 8%, unconfirmed writes 0%→0%.
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
25.4 / 30
03Economics
19.6 / 20
04Discoverability
11.9 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
8 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 |
|---|---|---|
get_game_catalog |
no_return_description |
Return the full catalog of TGC printable component types (cards, boards, boxes, and similar) that can be added to a game. Optionally filter by category (e.g., 'cards', 'boards', 'boxes') to narrow the results, or omit category to list everything. No authentication required. |
logout |
name_restates_behavior no_return_description |
End the current TGC session by destroying its session token. After logging out, authenticated calls will fail until you authenticate again. Returns a confirmation that the session was ended. |
create_game |
name_restates_behavior no_return_description |
Create a new game project under the given designer as the first step of building a game. Requires authentication. Returns the new game's ID, which you can then pass to tools such as add_component_to_game and get_game_details. |
add_component_to_game |
no_return_description |
Add a printable component (e.g., 'BridgeDeck', 'SmallTuckBox') or a stock part to a game, using quantity to set how many of the part to include. Requires authentication. Returns an identifier for the added component (such as a game part UUID) so you can reference it later. |
upload_file |
no_return_description |
Upload an image file (from an absolute file_path on disk or a public url) into a TGC folder for use in a game component. Provide either file_path or url, not both; filename is required when uploading from a URL. This is a heavyweight operation, so avoid calling it repeatedly in quick succession. Returns an identifier (e.g., the file ID) for the uploaded file. Requires authentication. |
update_game |
name_restates_behavior no_return_description |
Revise an existing game by changing its name, description, or public visibility (is_public). Requires authentication. Returns confirmation of the update and the resulting game state. |
get_component_details |
no_return_description |
Return the detailed specifications for a component type (by catalog identity such as 'BridgeDeck') or for a game part (by UUID), so you can inspect its properties before adding it to a game. |
delete_game |
name_restates_behavior no_return_description |
Permanently delete a game project and all of its associated data. This action cannot be undone, so only call it when certain. Returns confirmation that the game was deleted. |
Selection evidence
Confusable tool pairs.
7 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
get_component_sizes |
get_component_details |
medium | Both accept a part_id like 'BridgeDeck' and describe a component type, so a task worded as 'get the info/specs/details for the BridgeDeck component' is ambiguous between pixel dimensions and full component details. |
get_game_catalog |
get_game_details |
low | Names overlap on 'game'; a request like 'show me game catalog details' or 'details of available games' could land on get_game_catalog (which returns printable component types) instead of a specific game's detail record. |
get_game_catalog |
get_my_games |
medium | A natural task like 'show me my game catalog' matches both names, yet get_game_catalog lists printable component types while get_my_games lists the user's games, so an agent can pick the wrong tool for a 'list my games' intent. |
get_game_details |
get_component_details |
medium | Both are 'get X details' tools; a task like 'get the details of my game's components' or an underspecified 'show me the details' is ambiguous between the game record (game_id) and a component/part (part_id). |
get_my_designers |
get_my_games |
medium | Both are get_my_* list tools with the same auth requirement and ID-list output shape, so a generic request like 'list my stuff / my account resources' could target the wrong object type (designers vs games). |
get_my_games |
get_game_details |
medium | A request like 'show me details of my games' could select get_game_details (which needs one game_id) instead of get_my_games (which lists all games), especially since the two are chained and share game names/IDs. |
add_component_to_game |
update_game |
low | A casual instruction like 'update my game to include a deck of cards' literally matches the name update_game, though the intent is adding a component; update_game only changes name/description/visibility. |
Compare the field