Loading ToolBench
A web-based game platform featuring four games (Minesweeper, Connect 4, Pong, Tower of Hanoi) that can be played in single-player mode or as a duel against an AI agent via MCP tools
Collateral defines 15 game-specific tools with explicit schemas and descriptions. All tools have inputSchema and descriptions present. However, descriptions vary significantly in quality and actionability. Most parameter descriptions are minimal (1-5 words), and output schemas are not documented. Tool names follow a prefix pattern (c4_, hanoi_, ms_, pong_) but lack action verbs (get_, move_, drop_). Error handling is implicit in code, not surfaced in descriptions. Composition is strong, tools chain well within each game, but descriptions don't guide LLM selection or explain when to call each tool vs. alternatives.
Analyzes the position: columns where you win immediately (winning_now), where you must block because the human wins on their next drop (must_block), and ones that hand them the win (gives_opponent_a_win).
Board as text, top to bottom. H = human's piece, A = yours, . = empty. The last row is the column numbers.
Drops your piece in a column, 0 to 5. It falls to the lowest free slot and passes the turn unless you win.
Your own tower as text, bottom disc first, plus your move count and the clock. The human is solving an identical tower of their own beside yours; you cannot touch it and they cannot touch yours.
Moves the top disc of peg `from` onto peg `to`, on YOUR tower. Pegs are numbered 0 to 2. A disc may only rest on a bigger one. Illegal moves are rejected with the reason and cost you nothing but the round-trip. The answer carries your new position and the legal moves from it, so call this again immediately — the clock is running.
Tool names lack action verbs. Names like 'c4_board', 'hanoi_moves', 'pong_state' are noun-based, not verb-based. LLMs infer intent from names, 'get_board', 'list_moves', 'read_state' would be clearer.
Output schemas are not documented. Tools return structured objects (e.g., hanoi_move returns position, legal moves, clock), but the response schema is not declared in the tool definition. LLMs cannot plan downstream calls without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
The moves that are legal right now, so you never waste a call on an illegal one. It lists what you MAY do, not what you SHOULD — the good move is yours to work out, and working it out is the whole race. You do not need to call this between every move if you are following a plan; each hanoi_move answer already carries the new legal moves.
CALL THIS FIRST. It starts the clock — for both of you at the same instant — and hands you your starting position. Nothing moves until you do, so the human cannot get a head start while you are still reading. You each have your own tower of 5 discs on peg 0 and have to get it onto peg 2; whoever finishes first wins the race. 31 moves is optimal. Then go straight into moving: call hanoi_move over and over without stopping to report between moves. Every call costs you time on the clock, so plan the sequence once and play it out.
Board as text. ? = closed, . = open with no mines nearby, 1-8 = neighboring mines, H = human's mine, A = your mine.
Claims a cell as a mine. Getting it right earns a point and keeps your turn, so it pays to chain every safe claim before opening anything. Getting it wrong only costs the turn.
Deducible constraints. For each open numbered cell: how many mines are still missing around it (remaining) and which closed cells surround it (unknown). If remaining equals the number of unknown cells, all of them are mines. If remaining is 0, all of them are safe.
Opens a closed cell and passes the turn. If it had a mine, the point goes to the human. x is the column, y is the row, both range 0 to 8.
Moves YOUR paddle — the blue one on the left. This is the only way to move it; dragging on the page moves the human's paddle, not yours. Puts the centre of your paddle at y and lets the ball go back to full speed. Pass the `intercept_y` you just got from pong_read to return the shot. y is clamped to the court, so an out-of-range value is pinned rather than rejected. CALL pong_read AGAIN IMMEDIATELY AFTER THIS — the rally is still running and the next shot is already on its way.
Your only way to see the ball, and the only input you need: do not screenshot, click, or move the mouse to play Pong — pong_read plus pong_move is the whole game. Waits for the ball, then tells you exactly where to be. THIS CALL DOES NOT ANSWER IMMEDIATELY: it blocks until the ball is heading at your side of the court, then returns `intercept_y` — the y where the ball will actually reach your paddle, with the wall bounces already worked out. While you decide, the page slows the ball to a crawl so a round-trip to you fits inside the rally. PLAY IT AS A LOOP, ALL IN ONE TURN, WITHOUT STOPPING TO REPORT BETWEEN SHOTS: call pong_read, then immediately call pong_move with the `intercept_y` it gave you, then call pong_read again, and keep going until a result comes back with `round_over: true`. Every result names the next call in `next_action` — make it straight away. Writing the user a progress report mid-rally leaves your paddle standing still and loses the round; say nothing until it is over. `event` says what woke you: 'approaching' means play the shot now; 'waiting_for_start' means the round has not been served yet, so call pong_ready to start it; 'timeout' means nothing came at you in time, call pong_read again; 'round_over' or 'not_a_duel' means stop looping. If this call fails outright instead of answering, the game was switched out from under it and these tools no longer exist — call get_match rather than retrying.
CALL THIS FIRST, before any other pong tool. It tells you which paddle is yours and how the rally loop works — and it SERVES THE FIRST BALL, so the round starts the moment you call it. Nothing moves until you do. Read what it returns, then go straight into the pong_read / pong_move loop.
The court right now, as text, without waiting for anything. Use it to get your bearings; use pong_read to actually play. You are the BLUE paddle on the left; the human is the RED one on the right. Play ONLY through these three tools — never move the mouse, click, drag, press keys, or take a screenshot of this page. The mouse and the arrow keys belong to the human player, and using them plays their paddle for them instead of yours.
Parameter descriptions are minimal. Most parameters have 1 - 5 word descriptions ('column, 0 to 5', 'peg to take the top disc from, 0 to 2'). Descriptions should explain WHAT the parameter controls and WHY, not just the range. E.g., 'column: The column (0 - 5) where you drop your piece; it falls to the lowest free slot.'
Error handling is not surfaced in descriptions. Tools validate inputs (e.g., hanoi_move rejects illegal moves), but descriptions don't explain what errors are possible, when they occur, or how to recover. E.g., hanoi_move should document: 'Illegal moves are rejected with the reason and cost you nothing but the round-trip.'
No tool discovery or sequencing guidance. Descriptions don't explain which tool to call first, which tools are prerequisites, or how tools compose. E.g., pong_ready says 'CALL THIS FIRST', but other tools don't explain their role in the sequence.