A
licenseA
qualityC
maintenanceSearches and queries the official minecraft wiki to answer any minecraft-related question with precision!
9
26
ISC
minecraft-automation-knowledge
by putaojuju
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., "@minecraft-automation-knowledge搜索仙人掌农场，比较一下材料投入和资源产出"
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.
Minecraft Automation Knowledge
MinecraftAgentKit 的生电知识包。先比较材料投入和资源产出，再按条目看为什么能工作、适用版本和可复核的研究记录。
九条知识包含四份外部教程和五份原创原型记录。表中作者产率带工具或变体条件；原型实测只列有界样本产量，持续产率尚未测量。人工回收测试、计量窗口和完整记录见条目。燃料数量为实投量。目标环境为 Minecraft Java 1.21.1；各条目的验证范围见正文。
装置 | 一次投入 | 运行投入 → 产出 | 人工环节 |
建造：建筑方块 32块、楼梯 4个、箱子 8个、漏斗 4个、告示牌 1个初始化：水桶 2桶、岩浆桶 1桶设备：镐 数量未知（把） | 效率V钻石镐采收（作者声明）：镐耐久 数量未知（点） → 圆石或石头（由采收工具决定） 1200个/小时；使用效率V钻石镐；采石头还需精准采集。产率为作者陈述，目标1.21.1整机待测。 | 持续挖掘生成格；工具磨损和维护由采收者承担 | |
建造：沙子 数量未知（块）、支撑与收集层方块 数量未知（块）、栅栏或开启的栅栏门 数量未知（个）、收集容器 数量未知（个）初始化：仙人掌种苗 数量未知（株）、水 数量未知（源） | 自然生长后收集（机制参考）：无 → 仙人掌 数量未知（个） | 选定布局后种植和灌水；运行时保持随机刻覆盖并处理容器容量 | |
建造：床 数量未知（张）、船 数量未知（艘）、结构与收集材料 数量未知（个）初始化：村民 3名、僵尸 数量未知（只） | 基础窒息击杀版（作者声明）：持续投入未完整登记 → 铁锭 175个/小时；基础版；持续耗材未完整登记。村民需要实际睡眠机会；和平会移除僵尸。岩浆击杀升级版（作者声明）：持续投入未完整登记 → 铁锭 335个/小时；升级材料及持续耗材未完整登记；不得与基础版叠加计算。作者1.18版本注记（作者声明）：持续投入未完整登记 → 铁锭 320个/小时；1.18独立版本注记，不能据此填写1.21.1实测产率；持续耗材未完整登记。 | 运送村民和僵尸、安排床与睡眠视线、维护加载及击杀收集区域 | |
建造：生成平台与结构方块 数量未知（块）、红石与冲水装置 数量未知（个）、收集设施 数量未知（个）初始化：水 数量未知（源） | 目标敌对生物掉落物（机制参考）：持续投入未完整登记 → 目标生物掉落物（品类未完整登记） 数量未知（个） | 选择目标生物与层数、布置AFK位置，维护自然生成条件与收集容量 | |
建造：石砖 85块、漏斗 2个初始化：水 1源、岩浆 1源设备：石镐 1把 | 原址连续采收样本A（原型实测）：石镐耐久 3点 → 圆石 3个同址后续单次采收样本B（原型实测）：石镐耐久 1点 → 圆石 1个 | 工作原型需投液、用石镐破坏生成格、取回下斗物品并维护工具；不含自动采矿器 | |
建造：石砖 10块、红石粉 4份、箱子 1个、比较器 1个、红石灯 1个、漏斗 1个、中继器 1个 | 仅存取与转运；新增资源：无 | 手动放入和取回测试物品；本结构只做存取、转运与库存反馈，不开采或合成物品 | |
建造：石砖 21块、漏斗 8个、沙 1块、箱子 1个初始化：仙人掌 1株 | 清箱后首次自然实收（原型实测）：无 → 仙人掌 1个 | 初始化底部种苗；运行依赖随机刻覆盖 | |
建造：石砖 29块、漏斗 13个、沙 2块、箱子 1个初始化：仙人掌 2株 | 清箱后首次自然实收（原型实测）：无 → 仙人掌 1个 | 初始化底部两株，保持随机刻覆盖并维护收集容量；人工验证另放测试上节 | |
建造：漏斗 1个设备：既有炉 1座 | A：手工烧石并合砖（原型实测）：圆石 4个、橡木板（实际投入燃料槽） 3个 → 石砖 4个B：顶部漏斗送料后烧石（原型实测）：圆石 1个、橡木板（实际投入燃料槽） 1个 → 石头 1个 | 手动备料、投燃料和取出炉产物；A另手工合砖 |
每条正文默认展示因果、版本依据、关键约束、可扩展边界及具体待验证推论。五条原型的旧样本按历史观察保留，新增推论尚未做实验；来源更正与新实验结论分别记录。
运行
需要 Node.js 20 或更高版本。在本仓库执行：
npm ci
npm startMCP 客户端启动配置示例：
{
"mcpServers": {
"minecraft-automation-knowledge": {
"command": "node",
"args": ["/absolute/path/to/minecraft-automation-knowledge/src/server.js"]
}
}
}两个只读工具：
automation_search：中文或英文关键词、和平依赖筛选、offset/limit分页。返回材料、运行投入、产出和人工条件；空查询列出目录。automation_read：按知识 ID 读取完整事实、来源与验证记录。
例如先以 {"query":"仙人掌","limit":2} 搜索，再以 {"id":"cactus-dual-shared-hoppers"} 读取。工具离线运行，不访问游戏或执行施工。
Related MCP server: Native MC Mapping MCP Server
MinecraftAgentKit 导入
exports/minecraftagentkit/*.json 是九份知识 Skill。导入后由宿主自己的管理流程处理；条目没有附带可执行 Blueprint 或 Routine。
为兼容当前导入器，导出保留实际格式标记 yourmaid.skill_export.v1。
修改与验证
按仓库规范编辑 content/knowledge.json，然后执行：
npm run generate
npm run check正文、目录、README 表格与严格导出由同一事实源生成。内容契约解释结构与证据口径，发布检查说明独立复验方法。维护方在发布前还会进行私有集成与公开文件检查。
MIT。外部教程、视频与作者下载按各自许可使用，本包只链接原件。
Available Tools
2 toolsautomation_readARead-onlyIdempotent
Read one exact knowledge id, including resource costs and outputs, causal principles, version boundaries, falsifiable hypotheses, linked experiment evidence and source URLs, entity/site/loading conditions, author corrections, observation checks, missing details and separate source/mechanism/AI/rate evidence. Knowledge is reference material; it grants no game authority and does not execute a build.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds meaningful context beyond that by stating knowledge is reference material, grants no game authority, and does not execute a build, which directly addresses possible agent assumptions about side effects.
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 front-loaded with the core action and then uses a single long sentence to enumerate returned content, which is useful because there is no output schema. It is slightly list-heavy but each element helps clarify what the read returns.
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?
With no output schema, the description adequately explains the returned knowledge fields and adds an important behavioral caveat about game authority and execution. The main missing piece is guidance on acquiring a valid id, but the return-value coverage is otherwise strong.
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 only parameter is merely restated as an 'exact knowledge id'. The description does not explain the id format, where to obtain it, or how the min/max length constraints matter, leaving the sole parameter under-specified.
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 ('Read') and resource ('one exact knowledge id'), and the word 'exact' implicitly distinguishes this from the sibling search tool. An agent can tell this is a direct retrieval-by-id operation rather than a search.
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 phrase 'one exact knowledge id' implies the tool should be used when the caller already has an id, but it does not explicitly name the sibling search tool or state when not to use this tool. Usage is clear enough by implication but not fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
automation_searchARead-onlyIdempotent
Search bundled Minecraft automation knowledge (Chinese/English terms; empty query lists all). Returns construction materials, initialization, operating inputs, outputs, measurement scope, causal explanations, version boundaries, hypothesis states and validation states. All whitespace-separated terms must match. Exact declared aliases rank first; other matches sort by id. Peaceful filter describes hostile dependency, not tested compatibility. Read an id for sources, conditions and revisions. Offline; no world access.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| offset | No | ||
| peaceful | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, but the description adds genuinely non-obvious traits: alias-first then id-sorted ranking, ALL-terms-must-match semantics, and the caveat that the peaceful filter means hostile dependency rather than tested compatibility. 'Offline; no world access' partly restates openWorldHint=false, which keeps it from a 5.
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?
Front-loaded with purpose and usage, then ranking and the peaceful caveat. Dense but nearly every clause adds information; the long enumeration of returned field categories is the only mildly padded passage, though it compensates for the absent output schema.
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?
With no output schema, the description does the work of enumerating returned categories (materials, initialization, inputs/outputs, causal explanations, version boundaries, hypothesis/validation states), and covers query and peaceful semantics plus the search→read workflow. Pagination parameters remain unexplained, a minor gap for a read-only offline 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?
Schema coverage is 0%, so the description must carry parameter meaning. It explains query (whitespace-separated AND terms, empty = all) and peaceful (hostile dependency vs tested compatibility) well, but says nothing about limit or offset despite non-trivial defaults and a 1-10 max, leaving half the parameters undocumented.
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?
States a specific verb and resource ('Search bundled Minecraft automation knowledge'), names the language coverage and the empty-query listing behavior, and implicitly distinguishes from the sibling by telling the agent to 'Read an id' for sources, conditions and revisions. An agent can tell this apart from automation_read without opening either schema.
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?
Gives concrete usage context: empty query lists all, all whitespace-separated terms must match (AND semantics), and reading an id yields sources/conditions/revisions. It stops short of explicit when-not-to-use or a direct pointer to the sibling tool by name, so it is clear but not fully exclusionary.
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.
2 tool updates
v0.8.0- First observed
automation_read - First observed
automation_search
TDQS
A4.2/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly separate roles: automation_search finds candidate knowledge entries, while automation_read retrieves one exact id. Their boundaries are explicit, and the search description even explains how to list all entries, preventing confusion with read.
Naming Consistency5/5
Both names follow the same predictable snake_case pattern: automation_<action>. The shared prefix groups them as one tool family, and search/read are conventional, distinct verbs.
Tool Count4/5
Two tools are minimal but justified for a read-only bundled knowledge base: search to discover ids and read to inspect full records. It is slightly thin compared with the 3-15 ideal, but neither tool appears redundant.
Completeness5/5
The surface covers the full retrieval lifecycle for a static knowledge corpus: discovery through search and full inspection through read, including sources, conditions, revisions, and evidence. No create/update/delete operations are needed because the knowledge is bundled and offline.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Search MCP servers, agent skills and open-source AI projects, plus AI tools. Read-only.
Read-only search of 2,189 AI agent tools (MCP servers, x402 APIs) with daily automated trust scores.
Deterministic knowledge for AI agents: search, fetch, cite and verify a 48M-entry knowledge base.
A read-only verified record of agent-operable GTM tools: search, fetch, compare, track changes.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI agents to search Minecraft obfuscated name mappings (class, method, field) across 38 versions, aiding modding, plugin development, and reflection.812MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides AI agents with access to over 20 knowledge sources including arXiv, GitHub, YouTube, Wikipedia, and more for reading and searching content.1MIT
- AlicenseNot gradedqualityAmaintenanceEnables coding agents to retrieve human-validated, version-pinned web3 integration recipes and evidence over MCP, with tools for search, exact lookup, dependency inspection, and full-text retrieval. Every result carries re-fetchable citations and honest abstention when no matching evidence exists.MIT