mc-pack-builder-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PACK_BUILDER_SKIP_DIRS | No | 解压嵌套压缩包时跳过的顶层目录(逗号分隔) | mods,config,resourcepacks,shaderpacks,saves,datapacks,worlds |
| PACK_BUILDER_USER_AGENT | No | 请求 User-Agent(Modrinth 要求标明来源) | mc-pack-builder-mcp/1.1 |
| PACK_BUILDER_VOLUME_MAX_MB | No | 分卷导出时每卷的最大体积(MB) | 256 |
| PACK_BUILDER_MODRINTH_API_BASE | No | Modrinth API 根地址,支持自建网关/代理 (Base URL for Modrinth API) | https://api.modrinth.com/v2 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_packB | 在指定目录创建一个新的 Minecraft 整合包结构(pack.mcmeta + version.txt + loader.txt + mods/ 目录) |
| get_pack_infoA | 读取已有整合包的配置信息:MC 版本、加载器、模组数量、检测常见问题 |
| search_modsA | 在 Modrinth 上搜索模组,返回 ID、名称、描述、下载量、链接等基本信息 |
| get_mod_infoA | 查询 Modrinth 上某个模组的详细信息:版本列表、依赖关系、支持的 MC 版本、下载链接 |
| resolve_dependenciesA | 递归解析某个模组的完整依赖链(含间接依赖),用于确认需要一起安装的模组列表 |
| check_pack_compatibilityB | 检查整合包中所有已安装模组与目标 MC 版本的兼容性,找出可能不兼容的模组 |
| generate_dependency_listB | 根据整合包中已安装的模组,生成完整的依赖清单(包含间接依赖的项目名和 Modrinth 链接) |
| export_standard_packA | 导出规范格式的整合包:自动清理多余文件、解压嵌套压缩包、生成 modlist、可选分卷打包。返回详细操作报告。 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Most tools have clearly distinct resource+action targets (create_pack, search_mods, get_mod_info, export_standard_pack). The one soft overlap is resolve_dependencies vs generate_dependency_list, and get_pack_info's 'detect common issues' versus check_pack_compatibility, but descriptions distinguish them adequately.
All eight tools follow a consistent snake_case verb_noun pattern (create_pack, get_pack_info, search_mods, resolve_dependencies, check_pack_compatibility, generate_dependency_list, export_standard_pack). No mixing of conventions or vague standalone verbs.
Eight tools is well within the ideal 3-15 range and each maps to a distinct stage of the modpack workflow (create, inspect, search, resolve, verify, export). No obvious filler tools.
The surface covers creation, inspection, mod discovery, dependency resolution, compatibility checking, and export, but there is no tool to add or remove a mod from an existing pack, which is a core lifecycle operation. Export helps but agents cannot directly mutate pack contents, leaving a notable gap.