imposter-game-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@imposter-game-mcpLet's play a round with 5 players in the Tech category."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Imposter Game MCP Server 🕵️♂️
The official Model Context Protocol (MCP) server for playing the Imposter Game (Spyfall alternative) directly with AI.
Powered by Imposter Game Word Generator.
🎮 What is the Imposter Game?
The Imposter Game (also known as Spyfall or Chameleon) is a popular social deduction party game. In the game, everyone receives a secret word (e.g., "Coffee"), except for one player (the Imposter) who receives a slightly different word (e.g., "Tea"). Players take turns asking questions to figure out who the Imposter is, while the Imposter tries to blend in.
Want to play in person with friends on your phone?
Play instantly for free without downloading an app at impostergamewords.com.
Related MCP server: mcp-llm
🤖 Why use this MCP Server?
This MCP Server allows you to play the Imposter Game with an AI acting as the game host/moderator (like Claude, Cursor, or any MCP-compatible client).
Features:
Access to high-quality word pairs across 10+ categories (Standard, Couples, Kids, Tech, Food, etc.)
Automatically handles role assignments and word generation.
Perfectly balanced word pairings sourced from the official Imposter Game Generator.
📦 Installation & Setup
Using npx (Recommended for Claude Desktop)
To use this server in Claude Desktop, add the following to your claude_desktop_config.json:
{
"mcpServers": {
"imposter-game": {
"command": "npx",
"args": ["-y", "imposter-game-mcp"]
}
}
}Global Installation via npm
npm install -g imposter-game-mcp🛠️ Provided Tools
This server exposes the following tools:
get_categoriesDescription: Returns all available game categories (e.g., Kids, Couples, Food, Tech).
Usage: Call this to let human players choose a theme for the round.
generate_game_wordsDescription: Generates a set of secret words and assigns the Imposter role.
Inputs:
category(string): The chosen category (e.g., 'standard').playerCount(number): The number of players in the game (minimum 3).
Usage: Use this to set up a game session. The AI will receive the secret roles and act as the Game Master to privately message or reveal words to the human players.
📚 Resources & Strategy Guides
Want to improve your skills? Check out our official guides:
📄 License
This project is licensed under the MIT License. Data provided by Impostergamewords.com.
Available Tools
2 toolsgenerate_game_wordsA
Generate a set of words for an Imposter Game session. Given a category and player count, this returns a secret word pair (one for civilians, one for the imposter) and assigns the roles to a list of players.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The ID of the category (e.g., 'standard', 'couples', 'kids'). Call get_categories first if unknown. | |
| playerCount | Yes | The total number of players in the game (minimum 3). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does describe the core output behavior (returns word pair, assigns roles) but does not mention side effects, persistence, or failure modes. It also doesn't clarify whether 'assigns the roles' means persistent state or just part of the return value. This is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the general purpose, the second details the output. Both are essential and concise, with no filler or repetitive content. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description explains the return value sufficiently at a high level (word pair, role assignment). However, it lacks details about the exact return structure (e.g., JSON format, how players are listed) and does not mention the need to call get_categories first (though the schema does). This is slightly incomplete but acceptable for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage with descriptions for category and playerCount, including an example category ID and a minimum for playerCount. The tool description only restates the parameter names without adding additional meaning, syntax, or format details, so it does not exceed the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and resource ('words for an Imposter Game session'), and clearly states the return value: a secret word pair and role assignments. This distinguishes it from the sibling tool get_categories, which is about fetching categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used when you have a category and player count for an Imposter Game session. It implies the prerequisite of knowing a category, but it does not explicitly mention alternatives or when-not-to-use conditions. The sibling get_categories is present but not referenced in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_categoriesA
Get a list of all available Imposter Game categories. Use this to show the user what game topics they can choose from.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description clearly indicates a read-only operation ('Get a list') with no side effects. It provides sufficient behavioral context for a simple list retrieval, including that it returns all categories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the main action. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is complete. It covers purpose and usage, which is all that's needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool accepts zero parameters, so the description needs no parameter details. The baseline of 4 applies as there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Get' + resource 'list of all available Imposter Game categories' clearly states functionality. The scope ('all available') distinguishes from potential filtered variants, and sibling generate_game_words is clearly a different operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: to show the user what game topics they can choose from. This clear usage context helps the agent decide between this and generate_game_words.
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.
2 tool updates
v1.0.0- First observed
generate_game_words - First observed
get_categories
TDQS
The two tools have clearly distinct purposes: one lists categories, the other generates game words with role assignments. No overlap or ambiguity exists between them.
Both tool names follow the verb_noun pattern (get_categories, generate_game_words), making them consistent and predictable.
With only two tools, the server feels thin for a general game service, but the narrow scope of generating words and listing categories makes the count borderline reasonable.
The server covers the core workflow: fetching categories and generating a word set with role assignments. No obvious missing operations for this specialized purpose.
Maintenance
Related MCP Connectors
An MCP server for deep research or task groups
MCP server for trivia: 1.4M+ questions (EN+PL), 24 categories, 12 tools + 4 prompts, OAuth 2.1.
MCP server for AI dialogue using various LLM models via AceDataCloud
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server for toolhouse.ai. This does not rely on an external llm unlike the official server.4MIT
- MIT
- AlicenseAqualityCmaintenanceMCP server for Sonsuchup web tool that allows AI assistants to manage mystery cases, including people, alibis, timelines, and records via natural language.911MIT
- FlicenseNot gradedqualityBmaintenanceMCP server for a Wordle-style five-letter word guessing game playable in ChatGPT, supporting English and Brazilian Portuguese with progress persistence.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/double2dev/imposter-game-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server