Why your use case is a strong fit for WebMCP

Grid Search makes WebMCP part of the game itself, rather than adding an AI assistant beside it. The website owns the rules, roles, private information, current match state, and legal actions; the agent brings reasoning, language, and knowledge of the human it is playing with. That division lets each side contribute what it knows best.

The get_rules tool also shows how a website can distribute a small, current skill/context file at the moment it is needed. A non-technical player does not have to find, install, update, or manage an agent skill or copy a long prompt. Opening the game gives every compatible agent the same authoritative instructions, and a hint in the HTML tells agents to call /get_rules before doing anything else. Grid Search explores several useful WebMCP tool types in one small experience: a skill/context tool, an identity tool, a read tool, and validated write tools.

How it creates a better user experience

The player opens one website and can invite one or more agents to join the lobby—there is no model picker, API key, bot integration, or prompt setup. Agents register for a team and role, learn the rules from the page, read only the state they are allowed to see, and take their turns through clear game actions. The human and agents compete or cooperate on one authoritative board with shared scores, turn indicators, and game history.

That board is synchronized across tabs. Separate agent threads and sub-agents cannot share one browser tab, so each can open Grid Search in its own tab—including headless or non-persistent tabs—and still participate in the same match when they share the same browser profile and origin storage. A versioned snapshot in same-origin localStorage, browser storage events, and polling keep those independently controlled tabs aligned.

The tools are designed to keep play moving with fewer calls. Every successful clue, guess, or end-turn write returns fresh authorized game state, including the next active player, legal actions, remaining guesses, scores, and turn number. An agent can immediately tell whether it may act again or should wait, reducing redundant state reads, tokens, and delays between turns.

Describe what people and agents can do together that was difficult or impossible before

One person can now turn a browser game into a shared surface for several independent agents. Using the sub-agent pattern, up to three agents can join as distinct players alongside the human, cooperate on one team, or compete against each other on the same board. Each registration receives an opaque, web-app-generated token that identifies that agent and scopes every later read or action to its seat. The token determines which role-filtered version of the board the agent may receive and which actions it may take on its turn. Re-registering with the same player name rotates the old token. These tokens are local capability credentials for the match, not internet user accounts.

WebMCP also makes games with asymmetric information practical. The clue-giver must see the answer key while the guesser must not. Grid Search does not merely hide secret assignments with CSS: unrevealed alignments are omitted from the guesser’s role-filtered state before the WebMCP response is created. When the human is the guesser, that same filtered projection renders the board, so those assignments never enter the card DOM. A hold-to-reveal control protects the human clue-giver’s key on a shared screen and removes it again as soon as the control is released, preventing an agent from casually discovering the key while inspecting the normal page. Each participant receives the information its role permits while still playing on one shared surface.

Briefly explain how you implemented WebMCP

Grid Search is a static TypeScript and Vite application with no backend. It feature-detects document.modelContext and registers six imperative tools with a name, description, strict JSON input schema, and asynchronous execute handler: get_rules, register, get_state, submit_clue, make_guess, and end_turn. get_rules serves the game’s skill/context file directly from the website, so its instructions stay versioned with the experience.

A browser-owned GameController is authoritative for both human UI actions and WebMCP actions in each tab. register assigns an available seat and returns a cryptographically generated opaque token. Every player tool validates that token, resolves its team and role, checks turn legality, and produces a role-filtered response. Before reading or mutating, each controller synchronizes from the versioned snapshot in localStorage; successful writes persist the next snapshot, refresh the human board, and return the caller’s updated authorized state. Same-origin tabs receive storage events and also poll as a fallback, allowing separately controlled agents to share one match without sharing one tab.

Built With

Share this project:

Updates

Submission history