Captain Claw

Inspiration

Most AI gaming demos stop at recommending a game. But when my friends and I actually want to play something together, finding the game is only part of the problem.

Someone still has to figure out who's online, what everyone owns, how many players a game supports, whether we've already played it, and whether it fits the time we have. Then someone has to create the party and invite everyone.

I wanted to see what this would look like if an agent could work inside the gaming platform itself instead of just giving recommendations in chat.

That's what led to Captain Claw.

What it does

Captain Claw is a fictional gaming platform with a Store, Library, Friends system, and multiplayer Parties.

A player can give an agent a request like:

"Alex, Sam and Maya are online. We have 75 minutes. Find a co-op game all four of us can play, preferably something none of us has finished."

Using WebMCP, the agent can check who's online, compare player libraries, search the catalog, inspect game details, consider session length, and find a game that works for the group.

If the player wants to continue, the agent can create a party and send invitations.

Those aren't simulated chat responses. They change the actual state of Captain Claw. The party appears in the normal UI, and an invitation sent to another player can appear in that player's browser session.

The agent handles the coordination. The player still decides what to play and presses Launch.

How I built it

Captain Claw is built with React, TypeScript, Vite, Tailwind CSS, and WebMCP, and is deployed on Netlify.

The platform uses a synthetic but internally consistent dataset of games, players, friendships, libraries, presence, and play history. This keeps the demo self-contained while still giving the agent enough connected data to solve realistic requests.

Captain Claw exposes 13 WebMCP tools for things such as checking online friends, comparing libraries, searching games, reading the current browser view, applying Store filters, creating parties, sending invitations, checking party status, and launching a session.

Some tools are tied directly to browser context. For example, the agent can inspect the Store view the player is currently looking at and work with filters the player already applied. Tools can also appear based on application state, such as the ability to respond to an invitation when one is pending.

One thing I tried to keep consistent throughout the project was that the agent should not have a separate version of the product. Agent actions use the same application logic as human actions. Game filtering uses the same filtering code as the Store, and party actions update the same party state used by the UI.

Shared party state is handled through a Netlify Function and Netlify Blobs, which also lets party invitations work across browser sessions.

Challenges I ran into

The hardest part wasn't registering tools. It was making them feel like they belonged to a real application.

Browser state matters. If a player has already filtered the Store, the agent should be able to understand that context instead of starting over. If an invitation is sent, another player should actually be able to receive it.

I also ran into smaller problems that exposed bigger design questions. Session length was one example. "We have 75 minutes" sounds simple, but treating 75 minutes as a hard maximum can remove games that are still reasonable choices. The Store and WebMCP tools now share the same session-fit rule so they can't disagree with each other.

Testing multi-user party state was another challenge. Each demo room needed isolated state so different users or judges wouldn't accidentally overwrite each other's party.

Accomplishments that I'm proud of

I'm most proud that WebMCP isn't just sitting beside the application as a demo API.

The agent can operate the same product the player is looking at.

It can use the current Store context, open a game, change visible filters, create a party, and send an invitation that another browser session can receive. The results of agent actions show up through the normal Captain Claw interface.

I also built automated checks around the main recommendation funnel and WebMCP flows so the demo isn't dependent on one lucky prompt.

What I learned

The biggest thing I learned is that useful agent tools aren't always the same thing as backend API endpoints.

Giving an agent a pile of raw data isn't necessarily helpful. Tools should represent useful capabilities and expose enough context for the agent to make a good decision.

I also learned how important shared context is. When the player changes something and the agent can work from it - or the agent changes something and the player immediately sees it - the interaction feels much more natural than passing information back and forth through chat.

WebMCP made that idea much more concrete because the browser isn't just displaying the application anymore. It can expose the application's capabilities to the agent as well.

What's next for Captain Claw

Captain Claw currently uses a fictional gaming ecosystem so the demo stays deterministic and doesn't depend on external gaming APIs.

The next step would be exploring how the same approach could work with real gaming services and richer social data.

I'd also like to expand the session-planning side: more player preferences, scheduling, better group matching, and longer-term questions like "what should our group play this weekend?"

There are also interesting actions that should require stronger human confirmation, especially purchases or other account-level changes. That's an area I'd like to explore further as agent-operated web applications become more capable.

Built With

• css
• html5
• javascript
• netlify
• netlify-blobs
• react
• tailwind-css
• typescript
• web-apis
• webmcp