I’ve just open-sourced a new project (https://github.com/galois17/mcp-py-tournament): an MCP Server for managing recreational tennis or pickleball tournaments.
This server exposes a Model Context Protocol (MCP) server that provides deterministic, stateful control of tournaments—handling players, matches, rounds, and standings—all while remaining conversational through an LLM like Gemini (tested), ChatGPT (not tested), or Claude (not tested). (I must admit that when it comes to MCP integration, I’ve only tried Gemini and Claude.)
The Problem: LLMs Can’t Keep Score
Modern LLMs can “pair players” or “keep score” in a chat, but that breaks down the moment you need consistency, persistence, or multi-user control.
An LLM-only chat is stateless. It can’t remember the score from 10 minutes ago, it can’t guarantee fair pairings, and it certainly can’t let two different users see the same, up-to-date leaderboard.
The Solution: MCP for a Stateful, Deterministic Backend
This is where the Model Context Protocol (MCP) comes in. Instead of letting the LLM be the app, the LLM becomes a conversational interface to a real, stateful application.
The MCP server manages the “truth,” and the LLM handles the conversation.
Here is a direct comparison of why this architecture is so much more powerful.
| Concern | LLM-Only Approach | MCP-Backed Approach |
|---|---|---|
| Determinism | Pairings and results vary per run. | Uses defined algorithms (BALANCED / RANDOM) — always reproducible. |
| Record Keeping | State is lost once the chat ends. | All data persisted to DynamoDB. |
| Rules Enforcement | LLM might skip or misapply rules. | Strict validation logic in Python. |
| Multi-User Safety | Each chat has its own inconsistent memory. | Shared tournament state accessible via tournament_id. |
| Extensibility | Hard to add structure or APIs. | Easy to extend with new tools (e.g., get_leaderboard_csv, get_player_stats). |
| Auditing & Analytics | Impossible — no database. | Full historical data for analysis or dashboards. |
Core Features of the Tournament Server
The server manages the entire tournament lifecycle. Each tournament gets a unique tournament_id and its own isolated state.
- Player Management: Player registration with skill levels.
- Match Generation: Create rounds with
BALANCEDorRANDOMpairing algorithms. - Logistics: Handles court and round configuration.
- Scoring: Manages score reporting and provides automatic leaderboard updates.
- Persistence: All records are stored in DynamoDB.
What You’ll Need (Prerequisites)
This MCP server requires access to AWS DynamoDB for storing tournament data.
You must have:
- An AWS account with DynamoDB permissions (
dynamodb:*or equivalent). - Local AWS credentials configured via
~/.aws/credentials, environment variables, or an IAM role. - A DynamoDB table named
TournamentTable(though the server will create this automatically on the first run if it doesn’t exist).
You can check your access with a simple AWS CLI command:
1
aws dynamodb list-tables
This is walkthrough of the interaction: