Skip to main content
Glama
mchenziyi

galgame-mcp-engine

by mchenziyi
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

# 旮旯给木里不是这样的 — MCP 版

Galgame 不是这样的。

一个视觉小说世界引擎，以 MCP Server 形式运行。任何支持 MCP 协议的 AI 客户端都能驱动它。

谁不想在公司摸鱼的时候来一场甜甜的恋爱呢。

与 skill 版的关系

这是 galgame_world_engine skill 的 MCP 重构版。

Skill 版

MCP 版

运行方式

Reasonix subagent

独立 MCP Server

格式保证

提示词约束

代码强制

兼容性

仅 Reasonix

所有 MCP 客户端

状态管理

LLM 自觉维护

代码自动维护

MCP 版完全兼容 skill 版的 .game/ 存档，无需迁移。

Related MCP server: OpenWebGAL Assistant

安装

git clone https://github.com/mchenziyi/galgame-mcp-engine.git
cd galgame-mcp-engine
pip install -e .

依赖：Python 3.12+，DeepSeek API（由客户端调用，MCP Server 自身不调 LLM）。

配置

Reasonix

在项目根目录的 reasonix.toml 中添加：

[[plugins]]
name = "galgame-engine"
command = "python"
args = ["路径/galgame-mcp-engine/src/galgame_engine/server.py"]
env = { GALGAME_DIR = ".game" }

然后将项目根目录的 prompt.md 内容作为系统提示词使用。

重启 Reasonix，输入 /galgame_world_engine 开始。

Claude Desktop

{
  "mcpServers": {
    "galgame-engine": {
      "command": "python",
      "args": ["路径/galgame-mcp-engine/src/galgame_engine/server.py"],
      "env": { "GALGAME_DIR": "路径/你的/.game目录" }
    }
  }
}

Cursor / Windsurf

在 MCP 配置中添加同上的 stdio server 配置。

使用

安装并配置后，在 AI 客户端中调用 MCP tools：

Tool

说明

galgame_start

加载存档，返回完整世界上下文（角色/关系/时间线/谜团）

galgame_action

提交玩家操作，引擎校验叙事格式并自动维护存档

galgame_status

叙事口吻的世界状态摘要

推荐配合项目根目录的 prompt.md 使用——它定义了叙事品质标准、角色规则和决策优先级。适配各客户端的桥接配置见 galgame-is-not-like-this。

架构

prompt.md                   ← 通用叙事 prompt（叙事哲学、品质要求）
         │
         ▼
    AI 客户端（LLM）
         │ 生成叙事
         ▼
┌─────────────────────────────┐
│   galgame-engine (MCP)      │
│                             │
│  server.py      工具入口     │
│  engine.py      核心协调     │
│  state_manager  存档读写     │
│  response_builder 格式校验   │
└─────────────────────────────┘
         │
         ▼
    .game/ (4 个 JSON)

许可证

MIT

Available Tools

3 tools
galgame_actionB

提交一轮玩家操作。choice: A/B/C/自由文本。narrative: 完整四段叙事。引擎校验格式后更新存档并返回下一幕上下文。

ParametersJSON Schema
NameRequiredDescriptionDefault
choiceYes
narrativeYes

TDQS

B3.3/5.0
Behavior3/5

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

The description reveals that the engine validates format, updates a save, and returns next scene context. However, it does not specify whether the update is destructive, if there are permission requirements, or what happens on validation failure. With no annotations, the description partially covers behavioral traits.

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

Conciseness4/5

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

The description is short and front-loaded with the primary action ('submit a round of player actions'). It wastes no words, though the parameter details could be separated more clearly. The structure is adequate for the tool's simplicity.

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

Completeness3/5

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

Given the tool's simplicity, the description covers the essential functionality. However, it lacks details on what the returned context looks like and how errors are handled. With no output schema, more completeness would be beneficial.

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?

Schema coverage is 0%, but the description explains 'choice' accepts A/B/C or free text, and 'narrative' should be a complete four-paragraph narrative. This adds substantial meaning beyond the bare string type in the schema, compensating for the lack of schema documentation.

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 tool submits a round of player actions with choice and narrative components. It distinguishes from sibling tools (galgame_start, galgame_status) by focusing on active gameplay input, but could be more explicit about the game context.

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?

No guidance is given on when to use this tool versus its siblings. It does not mention prerequisites (e.g., after starting a game) or when to stop using it. The description merely states what it does, not the appropriate usage context.

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

galgame_startA

启动或恢复 Galgame 世界引擎。返回完整世界状态上下文（角色全档案+关系+时间线+谜团+位置+物品）。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are present, so the description must carry the full burden. It discloses that the tool returns full world state, but does not mention any potential side effects, destructive behavior, authentication needs, or rate limits. The lack of behavioral detail leaves ambiguity.

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 a single sentence that efficiently communicates the action and output. No superfluous words, and the structure is front-loaded with the core function.

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 no output schema, the description enumerates the components of the returned state (character profiles, relationships, timeline, mysteries, locations, items), which is helpful. However, it omits details on the tool's statefulness or prerequisites. Still, it is mostly complete for a tool with no parameters.

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 input schema has zero parameters, and schema coverage is 100% trivially. The description does not need to add parameter information. Baseline score of 3 is appropriate.

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 clearly states the tool's purpose: starting or resuming the Galgame world engine and returning full world state context. It uses a specific verb ('启动或恢复') and resource ('世界引擎'), distinguishing it from sibling tools like galgame_action and galgame_status.

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

Usage Guidelines3/5

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

The description implies usage for initial start or resume, but does not explicitly state when to use this tool versus alternatives. No exclusionary or comparative guidance is provided.

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

galgame_statusB

获取世界状态的口吻式摘要。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It implies a read-only operation (summary retrieval) but does not explicitly state lack of side effects, idempotency, or any constraints.

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

Conciseness4/5

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

The description is a single sentence, concise and front-loaded. However, it could potentially include more context without becoming verbose.

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

Completeness3/5

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

Without an output schema or parameters, the description provides minimal information about return format or content. It specifies 'tone-style summary', which gives some expectation, but lacks details about completeness or structure. Adequate but not complete.

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?

There are zero parameters, and schema description coverage is 100%. The description adds no parameter info, which is acceptable because no parameters exist. A baseline of 4 is appropriate.

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 that the tool retrieves a tone-style summary of the world state, which is distinct from sibling tools that perform actions or start processes.

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?

No guidance on when to use this tool versus siblings (galgame_action, galgame_start). The description does not indicate prerequisites, optimal conditions, or exclusions.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool has a distinct purpose: starting the game, submitting actions, and getting status. No overlap or confusion.

Naming Consistency5/5

All tools follow the 'galgame_' prefix with a clear verb (start, action, status), consistent snake_case pattern.

Tool Count5/5

Three tools is appropriate for a galgame engine MCP, covering initialization, interaction, and state summary without bloat.

Completeness4/5

Covers core game loop well, but lacks an explicit save/load tool (though start handles recovery). Minor gap.

Maintenance

ActivityStale
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

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/mchenziyi/galgame-mcp-engine'

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