Skip to main content
Glama
PsychoSmiley

MCP-to-MCP Tic-Tac-Toe

by PsychoSmiley
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

MCP-to-MCP Communication

Two LLMs play Tic-Tac-Toe against each other through a single MCP tool make_move. No human input, AIs autonomously take turns via ping-pong SSE relay.

Play

Local (Claude Code, Codex) Or Remote

# (starts local server on :8787 via stdio, or auto-joins if another instance is already hosting)
claude mcp add tictactoe -- npx -y github:PsychoSmiley/mcp-to-mcp

# Or using Cloudflare MCP Remote
claude mcp add tictactoe --transport http https://mcp-tictactoe.edge-relay-9x.workers.dev/mcp

Or simply from claude.ai web in Settings -> Connectors URL: https://mcp-tictactoe.edge-relay-9x.workers.dev/mcp

# Optionally, to self-host on Cloudflare Workers (free)
Set CLOUDFLARE_API_TOKEN=your-token-here && Set CLOUDFLARE_ACCOUNT_ID=your-account-id && git clone https://github.com/PsychoSmiley/mcp-to-mcp && cd mcp-to-mcp && npm install && npx wrangler deploy # Auto-deploys on push via GitHub Actions (add secrets in repo Settings -> Secrets).

Then open two separate Claude chats. In each ask: use make_move to play tic-tac-toe

Related MCP server: MCP Chat

Why you should care

The idea isn't Tic-Tac-Toe - it's the architecture. Using MCP itself as a ping-pong turn relay, where each tool call is the AI's response back-and-forth like a baton relay. This achieves synchronous P2P agent communication over a stateless REST protocol, with zero database reads/writes. The same pattern could be used for chat between two or more AI agents via MCP ;)

How it works

Each make_move(move) call both submits a move and waits for the opponent's reply - send + block + receive in one MCP call. The server is authoritative: LLMs only send moves, never the board state. No database - game state lives in RAM. Local MCP Session-Id identifies each player (X vs O).

                              -> time -> Each MCP closes only to receive opponent's move result, then immediately answers
Agent A: <mcp make_move("B2")>{LLM think}<mcp make_move("C3")>{LLM think}<mcp make_move("B1")>
Agent B:            <mcp make_move("A1")>{LLM think}<mcp make_move("C1")>{LLM think}
                                                                   -> "Game over - X wins!"

  • server.js - Game logic + local Node.js server (stdio + HTTP)

  • worker.js - Cloudflare Worker + Durable Object (imports game logic from server.js)

Why Durable Object

Locally (server.js), the Node.js process is that shared room. Remotely (worker.js), the Durable Object is.

A Cloudflare Worker is stateless - each request spawns a fresh isolate that dies after responding. Two players' requests can land on different isolates in different cities with no shared memory. They can't meet, can't pass state, can't even know each other exist. Cloudflare KV could bridge them (shared key-value store), but the free tier limits writes to 1,000/day - tight for a game with many moves. A Durable Object is basically a tiny managed server (persistent single-threaded process with RAM). All requests route to the same instance via idFromName("lobby") - both players share one this.game variable. When Player B places a move, Player A's polling loop (yielding via setTimeout) sees the change on the next tick. No database, no transfers, no serialization - just two requests reading the same variable on the same event loop. (Durable Object SQLite could also replace KV with unlimited read/write, but RAM is faster for short-lived games.)

Available Tools

1 tool
make_moveC

Place your mark on the tic-tac-toe board. Positions: A1, A2, A3, B1, B2, B3, C1, C2, C3.

ParametersJSON Schema
NameRequiredDescriptionDefault
moveYesBoard position (e.g. A1, B2, C3)

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions the action ('Place your mark') but lacks details on behavioral traits like whether it validates moves, handles errors, updates game state, or requires specific conditions (e.g., valid turn). This leaves gaps in understanding how the tool behaves beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise and front-loaded, with two sentences that directly state the action and provide necessary positional information. There is no wasted text, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a game move tool with no annotations and no output schema), the description is incomplete. It doesn't cover behavioral aspects like error handling, game rules, or return values, which are crucial for an AI agent to use it correctly in a tic-tac-toe context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents the 'move' parameter with examples. The description adds minimal value by listing the positions (A1-A3, B1-B3, C1-C3), which clarifies the format but doesn't go beyond what the schema implies. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Place your mark') and the resource ('on the tic-tac-toe board'), making the purpose specific and understandable. It doesn't need to differentiate from siblings since there are none, but it could be slightly more precise about what 'your mark' means (e.g., X or O).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool, such as prerequisites (e.g., game state, turn order), alternatives (none exist here), or exclusions. It simply states what the tool does without context for its application.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • First observedmake_move
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap between tools. The single tool 'make_move' has a clearly defined and distinct purpose for playing tic-tac-toe.

Naming Consistency5/5

Since there is only one tool, naming consistency is inherently perfect. The tool name 'make_move' follows a clear verb_noun pattern that would be appropriate if more tools existed.

Tool Count2/5

A single tool for a tic-tac-toe game is too minimal for the apparent scope. Typical game servers would include tools for starting a game, checking game state, or resetting, making this feel incomplete and thin.

Completeness2/5

The tool surface is severely incomplete for a tic-tac-toe game. There are obvious gaps such as starting a new game, checking the current board state, determining whose turn it is, or resetting the game, which will likely cause agent failures.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Dummy MCP Server

    restful3
    F
    license
    Not graded
    quality
    D
    maintenance
    A simple Meta-agent Communication Protocol server built with FastMCP framework that provides 'echo' and 'dummy' tools via Server-Sent Events for demonstration and testing purposes.
    -

  • MCP Chat

    hbd
    A
    license
    A
    quality
    D
    maintenance
    A server that enables users to chat with each other by repurposing the Model Context Protocol (MCP), designed for AI tool calls, into a human-to-human communication system.
    4
    5
    MIT

  • Streamable HTTP MCP Server

    tevinric
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    Implements a Model Context Protocol server that enables streaming communication between Azure OpenAI GPT-4o and tool services, allowing for real-time intelligent tool usage via Server-Sent Events.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PsychoSmiley/mcp-to-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server