A
licenseNot graded
qualityD
maintenanceBridges AI assistants to running game instances for testing, debugging, and verification. Works with any game engine via a simple TCP protocol.
18 npm
MIT
Amazing Cultivation MCP
Click on "Deploy 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., "@Amazing Cultivation MCPpause the game and show my sect overview with any urgent alerts"
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.
Amazing Cultivation MCP
让 AI 通过游戏内 Mod 读取并操作《了不起的修仙模拟器》。
本项目只借鉴 rimUIMCP 的“游戏内桥接 + 本地 Runtime + MCP”分层，不照搬环世界的游戏接口。桥接本身是标准《了不起的修仙模拟器》Mod：由 GameMain:NewMod 注册，使用 OnBeforeInit 加载程序集，并在 OnStep 的 Unity 主线程处理请求。读取和动作接口来自本游戏实际使用的 XiaWorld、Wnd_GameMain、UI_WorldLayer、MapCamera 与 FairyGUI。
架构
AI / MCP Client
│ stdio
▼
MCP Server (src/server.mjs)
│ HTTP + 临时 Token，仅 127.0.0.1
▼
Local Runtime (src/runtime.mjs)
│ WebSocket + 独立临时 Token，仅 127.0.0.1
▼
游戏内 C# Mod (AmazingCultivationMCP.Bridge.dll)
│ Lua OnStep 主线程调度
├── XiaWorld.World / Map / Npc
└── FairyGUI 控件树与原版事件WebSocket 的网络回调只负责把请求加入队列。Lua Mod 每帧调用 Bridge.Update()，由 Unity 主线程读取游戏对象、执行 UI 动作并返回结果。
Related MCP server: ue-bridge
已实现能力
面向自主决策的一次性总览：世界、地图、门派、资源、人物、警报和当前选择。
世界时间、游戏模式、暂停及速度状态。
地图尺寸、NPC 数量和各类 Thing 数量。
活动人物分页读取：名称、位置、生命、年龄、性别、境界分类、阵营、真炁、当前工作和需求值。
地图格读取：地形、灵气、五行及比例、温度、肥沃度、美观度、光照和格内对象。
全地图对象分页搜索，可按 Thing 类型、名称/定义名和玩家所有权过滤。
门派状态、库存汇总、人物工作优先级与作息读取。
按人物或对象 ID 调用原版
MapCamera.LookKey定位，并用Wnd_GameMain.ShowThingInfo打开原版信息面板。通过原版管理器设置工作、作息、暂停/倍速，打开建造/生产/搜索界面，以及创建命名存档。
直接调用原版
CommandMgr发现、添加、读取和移除砍伐、采矿、收获、拆除、灭火等 Thing/格子命令，并返回游戏内读回证据。与 rimUIMCP 的地图注入思路一致，通过本游戏原生
UILogicMgr.OnMapClick/OnMapDrag*对地图格点击和拖拽；无需 Windows 窗口句柄，可衔接原版建造、区域和命令模式。FairyGUI 控件树：层级、名称、文本、角色、位置、可见性、可操作状态，以及按钮/列表/下拉框/滑块的当前值。
通过
targetId或语义选择器激活按钮、右键、填写文本、设置选中状态、选择列表项/下拉项和调整滑块。MCP 内置玩法指南，规定“观察 → 决策 → 操作 → 再观察”的可靠闭环与常用操作配方。
0.6 高层 Helper：完整分页、殖民地巡检、开局建议、工作/作息确保、人物选择、命令确保/撤销和受监控时间推进。
0.7 修仙领域能力：人物五维与心情、功法境界、瓶颈与筑基、金丹与道行、秘籍树、术法、丹方/法宝配方、技能、伤病、装备和背包，以及可验证的修炼模式/行为设置。
0.8 战斗、建造和生产：读取 FightBody 并锁定目标、开战/停战、施放技能/法宝、设置自动技能；发现原生建造目录并放置蓝图；读取建筑和生产队列、添加/移除生产任务；改换功法与受确认保护的突破。
0.9 扩展系统：阵法状态与创建/取消、炼丹炼器配方和生产目录、拜师传功、农业仓储区域、门派交易外交状态及原版交易窗口、世界地图与历练派遣/召回。
1.0 风水与聚灵：成片读取原生灵气/五行场、读取建筑风水和房间/灵气区域，并提供聚灵阵与“大凶房”的只读规划器。
世界版本与 UI 快照 ID；重新载入世界后旧目标会失效。
与 rimUIMCP 相同思路的短事务租约、动作
requestId去重/结果缓存，以及可游标轮询的动作事件日志。本机 HTTP/WebSocket 双令牌鉴权。
截图和 Win32 输入备用接口。
环境
Windows 10/11
Node.js 20 或更高版本
Steam 版《了不起的修仙模拟器》
Windows .NET Framework 4 C# 编译器
运行时没有 npm 第三方依赖。
构建和安装 Mod
先关闭游戏，然后执行：
cd C:\path\to\amazing-cultivation-mcp
$env:ACS_ROOT = 'D:\SteamLibrary\steamapps\common\AmazingCultivationSimulator'
.\scripts\install-mod.ps1安装脚本会：
针对当前游戏目录中的程序集编译 C# 桥接。
将
Info.json、Lua 引导脚本和 DLL 复制到Mods\AmazingCultivationMCP。
进入游戏的 Mod 管理器，启用 Amazing Cultivation MCP 后重启游戏。
只构建而不安装：
.\scripts\build-bridge.ps1启动 Runtime
.\scripts\start-runtime.ps1也可以前台运行以查看日志：
npm run runtimeRuntime 会生成：
work/runtime.json：MCP 到 Runtime 的地址和令牌。%LOCALAPPDATA%\AmazingCultivationMCP\bridge.json：游戏 Mod 到 Runtime 的 WebSocket 地址和令牌。
令牌每次启动都会更新，不要提交或分享这些文件。
配置 MCP
{
"mcpServers": {
"amazing-cultivation": {
"command": "node",
"args": ["C:/path/to/amazing-cultivation-mcp/src/server.mjs"],
"env": {
"ACS_ROOT": "D:/SteamLibrary/steamapps/common/AmazingCultivationSimulator"
}
}
}
}连接后先调用：
{"method":"session.status","args":{}}高层玩法 Helper
优先让 AI 调用 helper.*，只有 Helper 尚未覆盖某项玩法时再组合底层 state.*、game.* 和 ui.*。
Helper | 作用 |
| 读取世界、门派、人物、资源、警报、输入状态和风险摘要 |
| 生成带状态证据的开局优先事项，不修改游戏 |
| 跨页读取全部活动人物并报告世界/帧一致性 |
| 跨页读取所有匹配的地图对象 |
| 跨页读取完整门派库存 |
| 幂等设置人物工作优先级、启用状态或优先工作 |
| 幂等设置一个或多个小时的门派作息 |
| 通过原版地图输入选择人物并读回验证 |
| 确保对象上存在砍伐、采矿、收获等原生命令 |
| 确保对象上的指定原生命令已经撤销 |
| 按矩形逐格建造墙、地板等，逐格验证；遇到失败返回已完成坐标 |
| 按清单建造最多 128 个不同建筑单元，支持每格独立材料、方向并逐格验证 |
| 用原版拖拽建造屋顶等区域，并验证房间覆盖格 |
| 将建筑清单保存为相对坐标模板并持久化列出，适合聚灵阵、卧房、工坊等复用布局 |
| 在新原点按 0/90/180/270 度旋转建造模板，或经确认后删除模板 |
| 立即暂停，停止指定角色战斗、取消其阵法并验证脱战状态 |
| 使用原生搬运任务把动物移入繁殖区，并可推进时间验证区域登记 |
| 按集火或轮换策略命令阵法全体成员攻击，并逐人回读战斗目标 |
| 停止战斗、解散相关阵法、向安全坐标编队撤退并可验证到达 |
| 下达原生拆除命令，并可推进时间直到确认建筑已消失 |
| 推进游戏并监视多个结构化停止条件，结束时始终暂停 |
| 读取座位周边灵气、五行、障碍、风水和建造目录，给出聚灵阵候选坐标，不自动建造 |
| 读取目标房间和附近建筑的原生风水结果，给出“大凶房”迭代方案，不自动建造 |
| 汇总突破率、环境、灵气、风水和物品，满足阈值时可确认后直接突破 |
| 下达原生炼宝任务并追踪到结束，报告输入变化和新获得物品 |
示例：
{"method":"helper.startingPlan","args":{}}
{"method":"helper.ensureWork","args":{"id":8684,"workKind":"Plant","priority":3,"enabled":true}}
{"method":"helper.ensureThingCommand","args":{"command":"Cutoff","id":1050}}
{"method":"helper.runAndWatch","args":{"conditions":[{"method":"state.world","path":"dayHour","operator":"gte","value":12}],"timeoutMs":30000}}
{"method":"helper.planSpiritGathering","args":{"x":120,"y":85,"radius":6,"element":"Water"}}
{"method":"helper.planOminousRoom","args":{"x":132,"y":90,"radius":8}}ensure* 方法会先读取现状，只修改不符合目标的部分，并在返回前读回验证。
游戏内方法
方法 | 作用 | 常用参数 |
| 桥接、世界和地图状态以及能力列表 | 无 |
| 获取/释放短事务租约，避免多步操作被其他客户端穿插 |
|
| 按 |
|
| 从游标后读取动作事件日志 |
|
| 一次读取 AI 决策所需的有界总览 |
|
| 世界时间、模式、暂停和速度 | 无 |
| 地图尺寸与对象数量 | 无 |
| 活动人物分页列表 |
|
| 单个人物、工作、需求和工作设置 |
|
| 人物种族、五维、心情、特性和经历 |
|
| 功法、境界进度、瓶颈、筑基、金丹、道行、秘籍与配方 |
|
| 全部已初始化技能、等级、喜爱度、经验和禁用状态 |
|
| 身体健康、濒死状态、伤病与治疗进度 |
|
| 已装备和随身物品、法宝与秘籍元数据 |
|
| 战斗目标、施法、技能冷却、自动技能与法宝 |
|
| 发现原生建造目录及精确建造名称 |
|
| 建筑进度、风水、工人和生产队列 |
|
| 建筑生产目录及人物已掌握的炼丹炼器配方 | 建筑或人物 ID、 |
| 活动阵法、阵型、节点和预设成员 |
|
| 农业、仓储等区域及原生区域类型 |
|
| 门派关系、好感点、倾向和交易货物 |
|
| 地点解锁、历练成本、预测及在外人员 |
|
| 当前交易报价与历练/剧情选项 | 无 |
| 读取地图格的修仙环境与格内对象 |
|
| 成片读取灵气、五行、占用物和高灵气格 |
|
| 读取建筑原生风水值以及 | 可选 |
| 读取突破条件、成功率及季节、灵气、五行、风水等原生影响项 |
|
| 神修信仰、人口、神国建筑、护法、核心信徒、天劫与飞升状态 |
|
| 神国建筑解锁、占格、环位、等级、人口和信仰消耗 |
|
| 两名角色间可用的原生江湖互动、缘分、好感、警惕与访客状态 |
|
| 读取体修真气、架势、淬体进度与部位 |
|
| 查询秘籍目录及某角色的习得资格 |
|
| 查询术法与神通定义、消耗、原生命令及角色习得状态 |
|
| 查询当前功法参悟树、前置/互斥、参悟值消耗和原生可学习判定 |
|
| 经原生校验学习参悟节点，并回读新解锁术法/神通 |
|
| 查询门派分舵、成员、建筑、政策、信仰、人口、仓储、灾害、监管及完整可用目录 |
|
| 派遣可行动角色开辟分舵 |
|
| 按原生解锁与条件校验配置分舵政策和建筑槽位 |
|
| 调度分舵负责人和成员 |
|
| 开始监管或领取分舵库存产物 |
|
| 查询官方熊猫、武当 DLC 安装状态、Lua 标记和内容路径 | 无 |
| 按原版 |
|
| 分页读取来访者、动物与其他存活角色 |
|
| 搜索 NPC、建筑、植物、物品等 |
|
| 门派库存和食物/药物汇总 |
|
| 门派等级、声望、风水、弟子、解锁与作息 | 无 |
| 当前选中对象 | 无 |
| 可用对象类型、工作、作息和五行枚举 | 无 |
| 当前重要消息及其关联地点/对象 |
|
| 发现当前版本的原生命令定义 |
|
| 读取当前原生命令及目标/格子 |
|
| 读取当前地图输入模式和弹窗阻塞状态 | 无 |
| 设置人物修炼模式并返回读回状态 |
|
| 设置人物当前修炼行为并返回读回状态 |
|
| 改换功法（高风险确认） |
|
| 走原版 |
|
| 条件检查后开始突破（高风险确认） |
|
| 原生开战、锁定目标与停战 | 人物和目标 ID |
| 战斗技能、自动技能与法宝 | 人物、技能/模式和目标 |
| 进入原生建造模式并放置蓝图 | 目录名称和地图格 |
| 通过原生搬迁流程为已完成建筑放置目标蓝图 | 建筑 ID、目标格、 |
| 管理建筑生产队列 | 建筑 ID、配方/任务名或任务 ID |
| 按原生阵型结阵或解阵（确认保护） |
|
| 用已解锁节点创建并由游戏校验自定义阵型，或删除未使用阵型 | 节点清单或阵型 ID、 |
| 保存或删除阵型的有序成员方案 | 阵型/方案 ID、角色 ID、 |
| 拜师并排入原生传功任务（确认保护） | 师徒 ID、秘籍 ID、 |
| 创建并编辑农业、仓储等原生区域 | 区域类型/ID 和地图格 |
| 设置作物、门人限制、仓储优先级和出售/品质策略 | 区域 ID 与策略字段 |
| 设置守卫区敌我/锁定策略并增删守卫成员 | 区域 ID、角色 ID 清单 |
| 通过原生 | 角色/动物 ID、目标格、 |
| 执行当前原生可用的邀请、闲聊等江湖互动（确认保护） |
|
| 打开神修角色的原版神国管理窗口并返回结构化状态 |
|
| 通过原生条件与资源检查建造或升级神国建筑 | 神修 ID、格子/建筑 ID、 |
| 拆除、开启或关闭神国建筑及其效果 | 神修 ID、建筑 ID |
| 为神国建筑配置或清除原生护法 | 神修 ID、建筑 ID、护法 ID、 |
| 打开指定门派的原版交易窗口 |
|
| 世界地图、派遣历练和召回（确认保护） | 人物 ID、地点、 |
| 核验后成交或选择历练事件（确认保护） |
|
| 定位人物并打开原版人物信息 |
|
| 定位任意对象并打开原版信息 |
|
| 镜头移动至地图格 |
|
| 打开原版建造/生产/搜索/主菜单等界面 |
|
| 修改人物工作优先级 |
|
| 启用或禁用人物工作 |
|
| 设置人物优先工作 |
|
| 请求中断人物当前可中断工作 |
|
| 修改一个小时的门派作息 |
|
| 通过原版 |
|
| 进入原版地图命令选择模式 |
|
| 给对象添加原生命令并读回验证 |
|
| 给地图格添加原生命令并读回验证 |
|
| 移除对象上的原生命令并验证 |
|
| 通过原版 |
|
| 通过原版 |
|
| 通过原版管理器创建命名存档 |
|
| FairyGUI 语义控件树 |
|
| 操作原版 UI 控件 |
|
| 暂停游戏时间 | 无 |
| 设置时间倍率 |
|
| 推进至少一个模拟帧并再次暂停，返回前后状态 |
|
| 推进指定模拟帧并再次暂停，返回帧数证据 |
|
| 运行并轮询结构化状态，条件满足后暂停 |
|
先调用 state.enums 获取当前游戏版本实际支持的 workKind、plan 和 Thing 类型，不要猜枚举名称。执行改变状态的动作后，重新调用对应的 state.* 或 ui.snapshot 核实结果。
UI 示例：
{"method":"ui.snapshot","args":{"limit":3000}}拿到按钮的 targetId 后：
{
"method":"ui.input",
"args":{"targetId":"ui:1:12345678","action":"click"}
}也可以使用语义选择器：
{
"method":"ui.input",
"args":{"selector":{"role":"button","name":"功法"},"action":"click"}
}文本框操作：
{
"method":"ui.input",
"args":{"targetId":"ui:1:12345678","action":"fill","text":"太一门"}
}列表、下拉框和滑块：
{"method":"ui.input","args":{"targetId":"ui:1:123","action":"selectIndex","index":2}}
{"method":"ui.input","args":{"targetId":"ui:1:456","action":"selectValue","value":"SomeValue"}}
{"method":"ui.input","args":{"targetId":"ui:1:789","action":"setValue","value":75}}选择器可组合使用 name、text、contains、role、完整 type 和 nth。界面变化后必须重新获取快照，因为旧 targetId 会失效。
MCP 客户端还会看到 acsmcp_guide。AI 应以 state.overview 开始每轮决策，优先处理警报和人物需求，执行动作后等待片刻并再次读取相关状态；不能仅凭“命令已派发”推断游戏结果。
备用视觉接口
以下接口在游戏内 UI 适配尚未覆盖某个界面时使用：
ui.observeui.focusui.moveui.clickui.dragui.scrollui.keyui.typeruntime.wait
坐标以游戏客户区左上角为 (0,0)。正常玩法应优先使用 state.grid、state.npcs、game.focusNpc 等游戏专用接口，再使用 ui.snapshot 和 ui.input 操作尚未建立专用适配的原版窗口。
验证
npm test
.\scripts\build-bridge.ps1自动测试覆盖 MCP 协议、结构化调用路由、本机令牌鉴权和 HTTP↔WebSocket 双向中继。实际游戏 API 和 UI 仍需在启用 Mod 后进行实机验证。
启用 Mod、重启游戏后运行只读实机检查：
npm run smoke在主菜单时会验证桥接和 UI 树；载入存档后再次运行，还会验证世界总览、枚举和警报读取。该脚本不会改变或保存游戏。
安全边界
Runtime 与游戏桥只监听
127.0.0.1。游戏 Mod 不提供任意 C#、Lua、反射调用或文件执行接口。
state.*是只读适配器；游戏动作集中在显式的game.*、ui.input和runtime.*方法。ui.input的成功表示原版事件已派发；持续性结果需要再次读取状态或 UI 核实。涉及覆盖存档、删除角色或解散门派等不可逆动作时，调用方应先向用户确认。
准备公开仓库或制作 Release 时，请按 PUBLISHING.md 的清单检查提交范围。
Available Tools
3 toolsacsmcp_callC
Observe and operate Amazing Cultivation Simulator through structured game state, verified high-level helpers, native UI, and fallback Windows input. Start with helper.observe or helper.startingPlan.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| method | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the helper layer, native UI control, and fallback Windows input, but it does not explain mutation risk, method-family behavior, return shapes, or error handling for a dispatch surface containing many mutating operations.
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?
Two tight sentences with the core purpose and a starting recommendation front-loaded; there is no filler. It is concise, though arguably under-specified for the size of the method surface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a huge dispatcher with 150+ methods, nested args, no output schema, no annotations, and zero schema coverage. The description names two entry points but does not explain method families, argument shapes, or routing to acsmcp_methods/acsmcp_guide, leaving major gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only names two example method values. It never explains that args is method-specific, what shape args takes per method, or how to discover required arguments for the 150+ enum methods.
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 states a specific domain and verbs: observe and operate Amazing Cultivation Simulator via structured state, helpers, native UI, and fallback Windows input. That is clearer than a tautology, but it does not distinguish this dispatcher from siblings acsmcp_methods or acsmcp_guide.
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?
It gives a concrete starting instruction: 'Start with helper.observe or helper.startingPlan.' However, it does not say when to use this tool versus acsmcp_guide or acsmcp_methods, nor when to avoid direct game/ui methods in favor of helpers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acsmcp_guideA
Return the recommended observe-decide-act-verify loop and argument recipes for reliably playing ACS.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does disclose the substance of what is returned (a loop plus argument recipes) with no indication of side effects, consistent with a zero-argument read. It stops short of describing output format, length, or whether the content is static versus account-specific.
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?
A single sentence with zero filler, front-loaded on the return value, with the qualifier 'for reliably playing ACS' placed where it adds context rather than padding.
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-param, no-output-schema guidance tool, the description covers what comes back well enough to call it correctly. A sentence on when to reach for it relative to acsmcp_methods and acsmcp_call would close the remaining gap.
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?
The tool takes zero parameters and the schema is fully closed (additionalProperties: false), so there is nothing parameter-level to explain; baseline for 0 params applies. The reference to 'argument recipes' is a nice hint that it documents args for sibling calls rather than accepting any itself.
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?
States a specific verb and resource: it returns the recommended observe-decide-act-verify loop plus argument recipes. That is clearly distinct from a method-listing or invocation tool, though the description never names or contrasts the siblings (acsmcp_call, acsmcp_methods), and the acronym 'ACS' is never expanded.
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?
'for reliably playing ACS' implies this is a read-first orientation step, but the description never says when to call it versus acsmcp_methods, nor whether it should be called before acsmcp_call. Usage is inferable but not stated or bounded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acsmcp_methodsA
List supported ACS MCP methods and their purpose.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. 'List' implies a safe read-only operation with no side effects, which is the main behavioral trait, but the description says nothing about return shape (names only vs. signatures), ordering, or whether output could be large — minor gaps for a zero-parameter listing.
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?
A single front-loaded sentence with no filler. Every word earns its place and the key noun ('methods') appears immediately.
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, annotation-free, output-schema-free discovery tool, the description covers what is needed to invoke it correctly. The only missing piece is the relationship to siblings acsmcp_call and acsmcp_guide, which would help an agent sequence discovery then invocation.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No competing parameter semantics are introduced.
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?
States a specific verb ('List') and resource ('ACS MCP methods') plus the value returned ('their purpose'). An agent knows exactly what comes back, but the description never distinguishes this discovery listing from acsmcp_guide, which plausibly also serves documentation needs.
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?
Usage is only implied: an agent would infer this is the discovery step before acsmcp_call, but the description never says so or names the alternative. There are no explicit when-to-use or when-not-to-use conditions.
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.
3 tool updates
v1.0.2- First observed
acsmcp_call - First observed
acsmcp_guide - First observed
acsmcp_methods
TDQS
B3.4/5.0
Scored across 3 tools
Disambiguation4/5
acsmcp_call is the sole execution tool while acsmcp_methods and acsmcp_guide are both documentation/discovery tools, which creates mild overlap between listing methods and returning argument recipes. The descriptions do differentiate them well enough that an agent can pick correctly in most cases.
Naming Consistency4/5
All three names share the acsmcp_ prefix and snake_case style, which is predictable. The only deviation is that 'call' is a verb while 'methods' and 'guide' are nouns, a minor inconsistency in an otherwise coherent scheme.
Tool Count3/5
This is a facade/dispatcher design where nearly all real capability is folded into a single acsmcp_call tool, leaving two of three tools as documentation. Three tools is thin but defensible for a single-domain game automation server, sitting at the borderline of the appropriate range.
Completeness3/5
The call tool claims observation, high-level helpers, native UI, and input fallback, suggesting broad operational coverage, and the methods/guide tools provide discoverability. However, the actual surface is opaque from the outside—no explicit lifecycle operations (save/load, session state, cancellation) are visible, so gaps cannot be ruled out.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Chinese metaphysics (bazi, qimen, 5-element) as decision-support tools for AI agents.
Savecraft serves real save game data and expert game knowledge to AI assistants.
The game engine built for AI. Any agent makes a multiplayer game and publishes it.
Related MCP Servers
- AlicenseBqualityAmaintenanceEnables AI agents and scripts to inspect objects, call functions, and run Lua in a running UE4SS game via MCP, with no sockets or admin rights required.2628 PyPI2MIT
- AlicenseAqualityBmaintenanceEnables AI assistants to interact with running games in real time — introspecting game state, simulating keyboard and mouse input to actually play, capturing screenshots, executing Lua code, hot-reloading files, and receiving push notifications when state changes.8MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents and streamers to monitor and control Oxygen Not Included gameplay through MCP, including world editing, colony alerts, building orders, navigation, dupe management, and game speed control.MIT