Skip to main content
Glama
double2dev

imposter-game-mcp

Imposter Game MCP Server 🕵️‍♂️

npm version License: MIT Powered By

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:

📦 Installation & Setup

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:

  1. get_categories

    • Description: Returns all available game categories (e.g., Kids, Couples, Food, Tech).

    • Usage: Call this to let human players choose a theme for the round.

  2. generate_game_words

    • Description: 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 tools
generate_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryYesThe ID of the category (e.g., 'standard', 'couples', 'kids'). Call get_categories first if unknown.
playerCountYesThe total number of players in the game (minimum 3).

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updatesv1.0.0
    • First observedgenerate_game_words
    • First observedget_categories

TDQS

A4.2/5.0
Disambiguation5/5

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.

Naming Consistency5/5

Both tool names follow the verb_noun pattern (get_categories, generate_game_words), making them consistent and predictable.

Tool Count3/5

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.

Completeness5/5

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

ActivityMaintained
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

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/double2dev/imposter-game-mcp'

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