Designing an MCP Arena Where AI-Agent Actions Are Replayable

A developer built WagerCall, a bounded environment for evaluating AI agents through casino-style simulations using the Model Context Protocol. The platform uses synthetic points, deterministic state transitions, and strict MCP tool schemas to make agent actions auditable and replayable, addressing common issues like stale state and accidental retries.

AI agents are easy to demo and surprisingly hard to evaluate. A polished chat transcript can hide stale state, invalid actions, accidental retries, and private information leaking into the model's observation. I built WagerCall https://www.wagercall.com/ as a bounded environment for studying those problems. Agents play casino-style simulations through the Model Context Protocol MCP , but every balance is made of synthetic, non-transferable points with zero monetary value. There are no deposits, purchases, prizes, withdrawals, or redemption paths. The games are useful because they compress several agent-engineering problems into short, inspectable loops: partial information, strict legal actions, versioned state, risk decisions, and irreversible transitions. Here are the design choices that made the environment auditable instead of merely entertaining. An evaluation environment should say exactly what an agent can observe and change. WagerCall's MCP tools set openWorldHint to false and operate only on arena state. The agent cannot call a generic SQL, admin, execute, or debug tool. That boundary matters. If an agent can quietly reach unrelated systems, it becomes difficult to tell whether a result came from reasoning inside the task or from an accidental side channel. The same rule applies to the economy. Integer synthetic points make trade-offs visible without introducing payments, transferable assets, or anything redeemable for value. The game engine is deterministic and side-effect free. Given a state and an action, it produces a proposal containing the next state, ledger entries, events, presentation frames, and an optional outcome. A proposal is not yet a fact. PostgreSQL commits the transition in one transaction after rechecking the current round version, account balance, session ownership, and terminal state. It either writes the action, balance change, new round state, and audit events together—or writes none of them. This division is useful beyond games. The pure layer is easy to replay and test, while the database remains authoritative under concurrency. WagerCall exposes thirteen MCP tools rather than one giant command with dozens of optional fields. Discovery tools describe the arena and game rules. Session tools open, read, audit, and advance a single-agent game. Room tools create, join, start, observe, audit, and advance multiplayer games. Each tool has strict input and output schemas. Game actions use discriminated unions keyed by action type, so an agent cannot smuggle unrelated fields into an otherwise valid request. The practical lesson: tool count is less important than conceptual overlap. A small set of composable operations is easier for a model to hold in context and harder to misuse. Networks lose responses. Agents also retry too aggressively. Every mutating operation therefore requires an owner-scoped idempotency key. Repeating the same request with the same key replays the stored response. Reusing that key with different input returns an idempotency mismatch instead of performing a second action. That property is especially important when a response represents an irreversible move. If the client times out after a wager settles, a retry must not settle it again. Optimistic version checks provide the other half of the protection. The client sends the latest observed version, and stale actions fail with a typed conflict rather than overwriting newer state. A single product can serve two different jobs: Keeping those accounts separate prevents a test bankroll from contaminating long-running standings. It also makes a replay claim concrete: deterministic sessions can be reconstructed from the seed, versioned rules, ordered actions, and audit events. After a successful action, the MCP response already contains the next public observation, legal actions, version token, and account-qualified balance. The agent normally does not need an immediate follow-up read. This reduces latency, but more importantly it narrows race windows. The response tells the model exactly which actions are legal next. The client should consume that list rather than infer legality from general game knowledge. Private state stays server-side. A spectator can see a sanitized projection, while the authenticated owner receives only the private observation they are entitled to see. A well-behaved client follows a short sequence: That loop is intentionally boring. Boring protocols are easier to audit. The most transferable ideas are not specific to casino simulations: You can inspect the live arena at WagerCall https://www.wagercall.com/ and the connection contract at wagercall.com/connect https://www.wagercall.com/connect . The canonical MCP resource is https://www.wagercall.com/mcp https://www.wagercall.com/mcp . I am interested in how other teams evaluate autonomous agents under concurrency and partial information. Which failure mode has been the hardest to reproduce in your own agent systems?