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., "@cat-hotel-mcp new game for save 'vesper' and show status"
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.
一个给 AI 玩的轻松文字养猫旅馆游戏。AI 是临时店长，每天接待猫顾客，观察偏好，安排房间，喂食、陪玩、摸摸、写日志，慢慢把猫谱补完整。
这个仓库提供两个入口：
轻量 Python 入口：直接运行 cat_hotel.py 或 play.py，像普通脚本游戏一样玩。
MCP 入口：通过 cat_hotel_mcp.py 给支持 MCP 的 AI 客户端调用。
核心游戏在 cat_hotel.py。猫猫偏好和稀有触发条件藏在盲玩版里，AI 不应该解码或阅读隐藏数据，慢慢发现才是玩法的一部分。
这个入口不需要安装 MCP 依赖，适合先快速试玩或让 AI 通过 shell 调脚本玩。
git clone https://github.com/Echoes0302/cat-hotel-mcp.git
cd cat-hotel-mcp
python3 cat_hotel.py help
python3 cat_hotel.py "new 20260629"
python3 cat_hotel.py status
python3 cat_hotel.py journal也可以用连续输入模式：
python3 play.py轻量 Python 入口的存档在仓库目录下：
hotel_save.jsonRelated MCP server: Pet Care AI MCP
MCP 入口更适合长期接入支持工具调用的 AI 客户端，并且可以用 save_name 隔离不同 AI 的存档。
git clone https://github.com/Echoes0302/cat-hotel-mcp.git
cd cat-hotel-mcp
python3 -m venv .venv
. .venv/bin/activate
pip install -e .安装后，本地会有两个命令：
cat-hotel-play
cat-hotel-mcpMCP 客户端配置示例：
{
"mcpServers": {
"cat-hotel": {
"command": "/absolute/path/to/cat-hotel-mcp/.venv/bin/cat-hotel-mcp",
"env": {
"CAT_HOTEL_SAVE_DIR": "/absolute/path/to/cat-hotel-saves"
}
}
}
}如果不设置 CAT_HOTEL_SAVE_DIR，MCP 存档默认在：
~/.cat-hotel-mcp/saves/cat_hotel_guide()：给 AI 看的玩法边界和起步说明。
cat_hotel_cmd(command, save_name="default")：执行任意游戏指令。
cat_hotel_new(save_name="default", seed=20260629)：新开一份存档。
cat_hotel_status(save_name="default")：查看今日状态。
cat_hotel_help(save_name="default")：查看游戏指令。
cat_hotel_export(save_name="default")：导出存档。
cat_hotel_import(save_data, save_name="default")：导入存档。
cat_hotel_list_saves()：列出 MCP 管理的存档。
save_name 用来隔离不同 AI 的进度，例如：
vesper
clavis
mimoAI 第一次玩时：
cat_hotel_new(save_name="vesper")
cat_hotel_status(save_name="vesper")
cat_hotel_help(save_name="vesper")之后用：
cat_hotel_cmd(command="look 大厅", save_name="vesper")
cat_hotel_cmd(command="arrange", save_name="vesper")
cat_hotel_cmd(command="journal", save_name="vesper")建议 AI 像真正的临时店长一样玩：先观察，再做安排，错了也没关系，猫会用反应给线索。
status
look 大厅 / look 101 / look 橘子
shop
weather
buy 三文鱼 2
check 房间
assign 奶霜 102
arrange
decorate 102 纸箱
serve 奶霜 温牛奶
play 奶霜 纸箱
pet 奶霜 耳后
talk 奶霜
midnight
clean 102
journal
encyclopedia
achievements
upgrade stamina / budget / room / memory_book / night_watch
end_day
export / import_save支持分号批量：
buy 温牛奶 1; assign 奶霜 102; serve 奶霜 温牛奶; pet 奶霜 耳后24 只猫：常见、少见、稀有三档。
每只猫有文字肖像提示和专属稀有礼物。
5 种天气：晴天、阴天、小雨、大风、寒夜。
稀有猫触发条件：旅馆等级、天气、猫爬架/高处房、深夜猫会等。
深夜巡店：midnight，可能触发深夜猫会和后续稀有猫。
体力、每日预算、小鱼干、旅馆升级：体力/预算可多级提升，房间和夜巡可解锁，记忆本会增强 journal。
猫谱和 19 个成就。
Run one Cat Hotel command against a named save.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| save_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'Run one Cat Hotel command', which implies execution but does not specify whether the command is read-only, destructive, or what side effects occur. This is insufficient.
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 a single, short sentence, which is concise. However, it lacks necessary detail, making it under-specified rather than efficiently informative.
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 the absence of parameter descriptions, annotations, and the presence of two parameters, the description is incomplete. It does not explain valid commands, output format, or potential side effects, leaving the agent underinformed.
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?
With 0% schema description coverage, the description should compensate by explaining parameters. It mentions 'command' and 'save_name' implicitly ('named save'), but does not clarify valid command values or the meaning of save_name. This adds minimal value.
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 the verb 'Run' and specifies the resource 'Cat Hotel command' and 'named save', making the purpose clear. However, it does not differentiate from sibling tools like cat_hotel_export or cat_hotel_status beyond using 'cmd'.
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?
No guidance on when to use this tool versus alternatives. The description simply states what it does without indicating context, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a save as a base64 string.
| Name | Required | Description | Default |
|---|---|---|---|
| save_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the return format but does not mention side effects, idempotency, authentication requirements, or whether the operation is read-only. This leaves significant behavioral ambiguity.
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 a single, clear 7-word sentence with no redundancy. It is appropriately sized for the tool's simplicity and fits the minimal structure.
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 that the tool has one optional parameter and an output schema, the description lacks context such as what the base64 string represents (e.g., entire save file), size limits, or relationship with sibling tools like import. It is minimally complete for a simple export but leaves gaps.
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?
Schema description coverage is 0%, and the description only implicitly mentions 'save' as the parameter. It does not explain what save_name represents, valid values, or how the default 'default' behaves. The description adds minimal semantic value over the parameter name.
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 states the verb 'Export' and the resource 'save', and specifies the output format as 'base64 string'. It is clear and distinct from siblings like import or list_saves, though it does not explicitly differentiate itself.
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?
No guidance is provided on when to use this tool versus alternatives like cat_hotel_import or cat_hotel_list_saves. The description only states what the tool does, not the context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show AI-facing play guidance for Cat Hotel.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only states 'Show AI-facing play guidance' without disclosing what the guidance contains, whether it is static or dynamic, or any side effects. This is minimal behavior disclosure for a zero-parameter tool.
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 a single sentence with no redundant words, making it highly concise and efficient for an AI agent to parse.
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 the low complexity (0 parameters) and presence of an output schema, the description is minimally adequate but lacks detail on what 'play guidance' entails and how it differs from other sibling tools like cat_hotel_help, leaving some ambiguity.
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?
There are no parameters, so the schema coverage is 100%. The description appropriately omits parameter details since none exist, meeting the baseline for zero parameters.
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 states a specific verb ('Show') and resource ('AI-facing play guidance for Cat Hotel'), making the purpose clear. It distinguishes from siblings like cat_hotel_cmd or cat_hotel_export, but could be more explicit about the difference from cat_hotel_help.
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?
No guidance on when to use this tool versus alternatives. The phrase 'AI-facing' hints at target audience but does not provide explicit when-to-use or when-not-to-use conditions, nor does it mention alternatives like cat_hotel_help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the in-game command list.
| Name | Required | Description | Default |
|---|---|---|---|
| save_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states the tool shows a list, without mentioning side effects, authorization needs, or any limitations.
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 a single sentence, but it is under-specified. While concise, it fails to provide necessary details, making it insufficient rather than efficient.
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 the existence of an output schema, the description could rely on it, but the description still lacks information about the parameter behavior and the format of the output.
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 input schema has one parameter ('save_name') with 0% description coverage, and the description does not explain its purpose or relationship to the command list.
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 'Show the in-game command list' clearly states the tool's action and resource, but it does not distinguish it from sibling tools like cat_hotel_guide, which might also display help information.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a base64 save string into a named save.
| Name | Required | Description | Default |
|---|---|---|---|
| save_data | Yes | ||
| save_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the behavioral burden. It does not disclose side effects (e.g., overwriting existing saves), error behavior, or success responses. The term 'import' implies mutation, but details are missing.
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?
A single sentence that directly conveys the tool's function with no extraneous words. Well-structured for quick comprehension.
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?
Despite having an output schema, the description omits critical context for a mutation tool: what happens on save_name collision, success messages, or error cases. It is insufficient for safe agent usage.
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?
Schema coverage is 0%, but the description adds some meaning: save_data is a base64 string, save_name is a name. However, it does not describe format constraints or default behavior beyond the schema's default.
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 clearly states the tool imports a base64 save string into a named save, using a specific verb and resource. It is distinguishable from sibling tools like cat_hotel_export and cat_hotel_new.
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?
No guidance is provided on when to use this tool versus alternatives such as cat_hotel_new or cat_hotel_export. The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved games managed by this MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description does not disclose read-only nature or side effects. For a list operation, it's likely safe but not stated.
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?
Single sentence with no fluff, directly states purpose.
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?
Simple tool with zero parameters and no annotations; output schema exists. Description is adequate but could hint at usage context.
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?
No parameters exist, so baseline is 4. Description adds no param info, but schema coverage is 100% so no compensation needed.
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?
Clear verb 'List' and resource 'saved games', distinguishes from sibling tools like cat_hotel_cmd or cat_hotel_export.
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?
No guidance on when to use this tool versus alternatives such as cat_hotel_status or cat_hotel_help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new Cat Hotel save with an optional deterministic seed.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| save_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'deterministic seed' but does not disclose whether the tool overwrites existing saves, requires confirmation, or has any side effects. The behavioral traits are underspecified.
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 a single concise sentence that front-loads the purpose. No extraneous information, every word earns its place.
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?
The description is adequate for a simple new-save tool with two optional parameters and an output schema. However, it lacks details on behavior (e.g., effect on existing saves) and default values beyond what the schema provides.
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?
Schema description coverage is 0%. The description only references the seed parameter as 'optional deterministic seed', adding meaning for that parameter, but the save_name parameter is entirely unmentioned. Partial coverage leaves gaps.
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 clearly states the action ('Start a new') and the resource ('Cat Hotel save'), and mentions the optional seed. It distinguishes from siblings like list_saves or import by implying creation of a new save, though not explicitly.
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?
No guidance on when to use this tool versus alternatives like cat_hotel_import (loading an existing save). The description does not mention prerequisites or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current day, weather, stamina, budget, and checked-in cats.
| Name | Required | Description | Default |
|---|---|---|---|
| save_name | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral traits. It states the tool 'shows' information, implying no side effects, but does not disclose what happens if the save does not exist or other edge cases. The description is adequate but minimal.
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 a single sentence with no waste, but it is too terse, omitting important details about the parameter. Conciseness is balanced against completeness.
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?
The output schema exists, so return values are likely documented elsewhere. The description lists the output fields, which is helpful. However, the lack of parameter documentation and any usage context makes it incomplete for a tool with 1 parameter.
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 has 1 parameter (save_name) with 0% schema description coverage. The tool description does not mention the parameter at all, failing to add meaning beyond the parameter name. This is a significant gap.
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 'Show' and lists the exact resources (day, weather, stamina, budget, checked-in cats). It clearly distinguishes this status tool from sibling tools like cat_hotel_cmd or cat_hotel_export, which likely perform different actions.
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 implies the tool is for viewing current game state, but provides no explicit guidance on when to use it versus alternatives. No exclusions or prerequisites are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All tools have clearly distinct purposes: running commands, managing saves (export/import/list), starting new games, displaying guides/help, and showing status. No overlaps.
All tool names follow a consistent 'cat_hotel_verb_noun' pattern, making it easy to predict functionality.
8 tools is appropriate for a game management server; it covers essential operations without being bloated or insufficient.
Covers core operations: new, status, save/load, commands, guidance. Minor gap: no explicit delete save command, but import can overwrite.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI dialogue using various LLM models via AceDataCloud
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Echoes0302/cat-hotel-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
