• 

Human vs. AI Go, Powered by WebMCP

Inspiration

Go has extremely simple rules, yet every move can change the direction of the entire game. That contrast made it an ideal environment for exploring a larger question:

What happens when an AI does not merely generate an answer, but directly participates in an interactive application?

Most AI board-game demos hide the interaction behind a traditional backend API. The AI receives a board state, returns a coordinate, and the application handles everything else. I wanted to make the interaction more explicit. The human player should place stones naturally by clicking the board, while the AI should observe the game and make its own moves through WebMCP tools.

The project became an experiment in building a shared digital environment where a human and an AI interact with the same game state through different interfaces.

What the Project Does

The project is an online Go game in which:

• The human player places stones by clicking intersections on the board.
• The game engine validates moves, captures stones, and updates the position.
• The AI reads the current game state through WebMCP.
• The AI chooses a move and calls a structured WebMCP tool to place its stone.
• Both players see the updated board immediately.

The AI does not directly manipulate the page or bypass the game rules. It must submit a move through the same controlled game interface used by the rest of the application.

Conceptually, the game follows a state transition model:

$$ S_{t+1} = T(S_t, a_t) $$

where:

• (S_t) is the current board state,
• (a_t) is the move selected by the human or AI,
• (T) is the rule engine that validates and applies the move.

A move is accepted only when:

$$ a_t \in A(S_t) $$

where (A(S_t)) represents all legal actions available in the current position.

How I Built It

I separated the project into three main layers: the interface, the game engine, and the AI interaction layer.

Interactive Go Board

The frontend renders the Go board and converts mouse clicks into board coordinates. When the human clicks an intersection, the interface sends the selected coordinate to the rule engine.

The board component is responsible for displaying:

• Empty intersections
• Black and white stones
• The latest move
• Captured stones
• The current player
• Invalid-move feedback

Keeping the visual board separate from the underlying game state made the interface easier to update and debug.

Go Rule Engine

The rule engine is the source of truth for the match. It determines whether a move is legal before modifying the board.

Its responsibilities include:

• Enforcing turn order
• Detecting occupied intersections
• Calculating connected stone groups
• Counting liberties
• Removing captured stones
• Preventing illegal self-capture
• Handling repetition rules
• Supporting pass actions

Neither the human interface nor the AI can directly modify the board. Every attempted move must pass through this engine.

WebMCP Integration

I exposed a small set of structured tools that allow the AI to interact with the game. The core tools provide functionality similar to:

get_board_state()
play_move(x, y)
pass_turn()
get_game_status()

The AI first retrieves the current position, reasons about possible moves, and then calls play_move with a board coordinate.

The tool layer validates the request before forwarding it to the rule engine. This prevents the AI from playing outside the board, moving twice, placing a stone on an occupied point, or acting on an outdated game state.

The complete interaction loop is:

Human clicks the board
        ↓
Rule engine validates the move
        ↓
Board state is updated
        ↓
AI reads the state through WebMCP
        ↓
AI selects and submits a move
        ↓
Rule engine validates the AI move
        ↓
The interface renders the new position

Challenges I Faced

Keeping the AI and Interface Synchronized

The most difficult problem was maintaining one authoritative game state.

The human interface, rule engine, and AI operate asynchronously. Without careful coordination, the AI could read an older position and attempt a move after the board had already changed.

I addressed this by treating every move as a transaction. Each action is checked against the latest board state and current turn before it is accepted.

Implementing Go Rules Correctly

Go looks simple until captures, liberties, suicide rules, and repeated positions are introduced. A single move can affect several neighboring groups, so validating a move requires more than checking whether an intersection is empty.

I learned to model the board as a graph. Each stone is a node connected to adjacent stones, and group traversal can be used to calculate liberties and determine whether a group should be captured.

Designing Tools for an AI

Giving an AI unrestricted access to application state would have been easy, but unreliable. The harder and more useful approach was designing a small tool interface with clear inputs, outputs, and validation rules.

For example, the AI should not need to understand the internal structure of the frontend. It only needs a stable representation of the board and a safe way to submit an action.

This taught me that effective AI tools should be narrow, predictable, and difficult to misuse.

Coordinate Conversion

Go coordinates can be represented in several ways: array indexes, screen positions, human-readable coordinates, or protocol-specific notation. Mixing these formats caused incorrect moves during early development.

I solved this by defining one internal coordinate system and performing conversions only at the boundaries of the application.

Handling Failed AI Actions

An AI can occasionally submit malformed parameters, select an illegal move, or act on stale information. The application needed to recover without freezing the game.

Instead of silently ignoring errors, the WebMCP layer returns structured feedback explaining why the move failed. The AI can then request the latest board state and try again.

What I Learned

This project changed how I think about AI integration.

I learned that an AI becomes much more useful when it can interact with a structured environment instead of only exchanging text. WebMCP allowed the browser application to expose meaningful capabilities while keeping the game engine in control.

I also learned that tool design matters as much as model intelligence. A powerful model connected to vague or unsafe tools can still behave poorly. A smaller set of well-defined tools often produces more reliable results.

From the game-engine side, I gained a deeper understanding of state machines, graph traversal, asynchronous synchronization, and defensive validation.

Most importantly, I learned to treat AI actions as untrusted external input. Every AI move must be checked exactly as carefully as a human-generated request.

What I Am Proud Of

I am proud that the project creates a direct and understandable interaction between a human, an AI, and a live application.

The human simply clicks the board. The AI observes the same match, reasons about the position, and responds through WebMCP. Both participants operate inside the same rule-controlled environment.

The result is more than a Go game. It is a small demonstration of how AI agents can safely participate in interactive web applications.

What Is Next

Future improvements could include:

• Adjustable AI difficulty
• Multiple board sizes
• Move history and SGF export
• Game replay
• Position analysis
• Suggested moves for beginners
• Timed matches
• Spectator mode
• Support for different AI models
• Human-versus-human and AI-versus-AI modes

I would also like to expose richer analysis tools, allowing the AI to explain candidate moves, identify weak groups, and teach Go while playing.

The long-term goal is to turn the project into both a playable online game and a practical example of human–AI interaction through WebMCP.

Built With

• ai-agents
• go-board-game
• human-ai
• model-context-protocol
• webmcp