该项目暴露了一个小型 MCP 服务器，后端由一个永久运行的 Paper 服务器支持。Paper、Skript 以及已安装的插件是解析器：Python 代码本身并不尝试理解 Skript 语法。
默认镜像包含以下兼容性配置：
组件 | 版本 |
Java | 21 |
Paper | 1.21.4 build 232 |
Skript | 2.14.3 |
SkBee | 3.16.1 |
skript-reflect | 2.6.3 |
skript-gui | 1.4.0 |
每个下载的 jar 文件在镜像构建时都会进行校验。如需使用其他权威配置，请在 .env 中同时覆盖所有相关的 URL 和校验和。切勿仅更新一个插件而不验证整个集合。
Skript 2.14.3 是 1.21.4 配置的有意选择。SkBee 3.16.1 是 Minecraft 1.21.4 的最后一个 SkBee 版本，而更新的 Skript 2.15/2.16 版本会与其 Adventure audience 类型注册冲突。更新 Skript 需要将整个配置迁移到更新的 Minecraft 和 SkBee 版本。
运行设置脚本。它会检查 Docker 和 uv，创建包含随机 RCON 密码的 .env，安装依赖，构建 Paper，并验证 RCON：
./setup.sh如需手动设置，请创建一个本地环境文件，并将密码替换为仅包含字母、数字、点、下划线或连字符的长随机值：
cp .env.example .env
docker compose build
docker compose up -d --wait在 .env 中将 PUID 和 PGID 设置为 id -u 和 id -g 的输出。它们默认为 1000，允许 Paper 读取主机创建的权限为 0600 的临时文件。
Paper 日志挂载在 runtime/logs。主机脚本直接从 scripts 挂载到 /server/plugins/Skript/scripts。世界和插件生成的数据保留为可丢弃的容器状态。仅发布 RCON，并绑定到 127.0.0.1:25575；游戏端口不发布。
使用以下命令检查启动状态和插件版本：
docker compose logs paper
docker compose exec paper sh -c 'nc -z 127.0.0.1 25575'使用 uv 安装并运行：
uv sync
uv run --env-file .env skript-mcpMCP 进程读取以下环境变量：
变量 | 默认值 |
| 必需 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对于 OpenCode，添加一个本地 MCP 条目，并通过环境传递相同的 RCON 密码：
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"skript": {
"type": "local",
"command": ["uv", "run", "--directory", "/absolute/path/to/skript-mcp", "--env-file", "/absolute/path/to/skript-mcp/.env", "skript-mcp"],
"enabled": true,
"environment": {}
}
}
}更改配置后重启 OpenCode。
skript_check_file(path) 通过路径验证一个现有的 .sk 文件。相对路径在 SKRIPT_SCRIPTS_DIR 下解析；绝对路径只有在指向该目录内时才被接受。它会重新加载完整的脚本集，以便兄弟脚本中的函数和其他共享定义可用。
skript_reload_file(path) 重新加载 SKRIPT_SCRIPTS_DIR 内的一个现有路径，而不重新加载其兄弟脚本。
minecraft_command(command) 通过本地 RCON 运行一个特权命令。
minecraft_logs(lines=200) 返回 latest.log 的有限尾部内容。
skript_reset() 仅删除过时的 __mcp_check_<uuid>.sk 文件。
重载操作是串行化的。诊断信息主要从 RCON 响应中解析，因为 Skript 有意将命令诊断信息重定向到正常的服务器日志之外；操作偏移后追加到 latest.log 的字节会被捕获并作为次要来源合并。
skript_check_file 会实际重新加载所有已启用的脚本，而不是进行沙盒解析。包含 on load 处理程序或插件行为的源代码可能会修改世界、文件或外部系统。仅检查受信任的脚本，并将 minecraft_command 和 RCON 密码视为完全管理员权限。
使用以下命令运行单元测试：
uv run pytestRun a privileged Minecraft server command over local RCON.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| response | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions 'privileged' (hinting at elevated permissions) and 'local RCON' (suggesting a specific protocol), but does not describe potential side effects (e.g., destructive commands), error states, or response characteristics. This is adequate but not thorough.
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 8-word sentence efficiently conveys the core purpose, access method, and privilege level. Every word contributes meaning; there is no redundancy or filler.
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?
Considering the tool's simplicity (one required parameter, no nested objects) and the presence of an output schema, the description covers the main purpose and connection method. It lacks details about prerequisites (e.g., RCON setup) and error scenarios, but for a straightforward command execution tool, it is mostly complete.
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 single parameter 'command' is self-explanatory from the tool's purpose and description, but the description adds no specific meaning beyond the schema (which has 0% description coverage). An example or format hint would strengthen semantic clarity, but the parameter is simple enough that a 3 is reasonable.
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 ('Run'), the resource ('Minecraft server command'), and the context ('over local RCON' with 'privileged' access). This specific verb+resource combination distinguishes it from sibling tools like skript_check_file or minecraft_logs, which deal with different aspects of server management.
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 provides no explicit guidance on when to use this tool versus alternatives. While the context of 'privileged command over RCON' implies it is for executing commands rather than checking files or logs, no direct comparison or exclusion criteria are given, leaving the agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the newest bounded section of Paper's latest.log.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states the tool returns a bounded section, but does not clarify whether it reads an entire file (potentially blocking), whether it's safe to call repeatedly, or if it updates in real-time. The term 'bounded' is ambiguous. The tool likely has low destructiveness (a read operation), but the description fails to confirm this, leaving important behavioral aspects opaque.
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 that directly states the core purpose. It is concise and front-loaded with the key action. However, it could be more efficient by removing 'bounded' if not clarifying, but overall it wastes no words. The lack of further explanation is acceptable given the tool's simplicity.
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 tool's low complexity (1 parameter with default, output schema exists, 5 sibling tools that are unrelated), the description is somewhat adequate but incomplete. It tells the agent what to expect (log section) but not how to interpret the output (since output schema is present, this is okay), nor any constraints (e.g., maximum lines). The missing piece is specification of what 'bounded' means and whether the tool requires server access. A more detailed example or note about log freshness would improve completeness.
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 input schema only has a 'lines' parameter with a default of 200). The description does not mention the parameter at all, meaning it provides no additive semantics beyond what the schema already states (type integer, default 200). However, the default value in the schema gives some guidance, and the tool is simple with only one parameter, so the lack of param description is noticeable but not catastrophic. Baseline for low coverage is 2-3; since the schema structure is clear and output schema exists, a 3 is appropriate.
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 tool returns the newest bounded section of Paper's latest.log. It specifies the verb 'return' and the resource 'newest bounded section of Paper's latest.log', which distinguishes it from sibling tools like minecraft_command or skript_check_file. However, the phrase 'bounded section' is somewhat vague, lacking clarity on what exactly is bounded (lines or time range), which could confuse an agent.
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 provides no guidance on when to use this tool versus alternatives. It does not mention that it only returns tail-end log entries, nor does it explain when one might prefer skript_check_file or minecraft_command instead. There is no mention of prerequisites or context (e.g., needing to be on the server), leaving the agent without usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a .sk path inside SKRIPT_SCRIPTS_DIR with all sibling scripts loaded.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| success | Yes | |
| raw_output | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that sibling scripts are loaded during validation, a behavioral trait. However, with no annotations provided, it fails to address whether the tool is read-only, what happens on invalid paths, or any side effects beyond loading. Partial transparency but not comprehensive.
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, well-structured sentence that immediately conveys the core purpose. Every word is necessary, no redundancy, and it is front-loaded. Exemplary conciseness.
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?
With one parameter and an output schema, the tool is low complexity. The description covers the path constraint and loading behavior, but omits validation criteria, error handling, and safety implications. Adequate but not thorough given the lack of annotations.
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 0% coverage, so the description carries the burden. It adds meaning by specifying that the path must be a .sk file inside SKRIPT_SCRIPTS_DIR, and implies a validation context. This provides useful constraint beyond the bare schema, though format details are missing.
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 ('Validate') and identifies the resource ('.sk path inside SKRIPT_SCRIPTS_DIR') with context (all sibling scripts loaded). It clearly distinguishes from sibling tools like skript_reload_file, minecraft_command, minecraft_logs, and skript_reset, which have different purposes.
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 does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context, exclusions, or alternative suggestions, leaving the agent to infer without help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload an existing .sk file relative to the configured scripts directory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| success | Yes | |
| raw_output | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the file is reloaded relative to a configured directory, which is useful context. However, it does not mention potential side effects (e.g., discarding current script state, re-compilation delay, permissions needed). A 3 is appropriate as it discloses the basic behavior but lacks depth.
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 that directly states the tool's function without any fluff. Every word is necessary and no waste.
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 tool has a simple interface (1 required parameter) and an output schema exists, which reduces the need for exhaustive return description. The description is nearly complete for a reload operation, though a bit more detail on the path format would help.
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% (no title/description for the 'path' parameter). The description does not explain what 'path' expects (e.g., absolute, relative to scripts dir, with or without extension). The tool description hints at 'relative to ... directory', but the parameter semantics are insufficiently detailed.
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 ('reload'), the resource type ('.sk file'), and the scope ('relative to the configured scripts directory'). This distinguishes it from siblings like skript_check_file (which likely checks syntax) and skript_reset (which resets something else).
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 when to use by specifying it is for reloading a .sk file. However, no explicit guidance is given on when not to use it (e.g., if file doesn't exist, if server is busy, if other reload tools exist) or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unload and remove only temporary scripts left by this MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| removed | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is destructive (unloads and removes) and scoped to temporary scripts. However, with no annotations, it lacks details on reversibility, side effects on other scripts, or whether removal is permanent. The description is adequate but not fully transparent.
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 that conveys the entire purpose without unnecessary words. Every part is essential, making it highly concise and well-structured.
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?
For a simple tool with no parameters and an existing output schema, the description provides enough context to understand the tool's purpose. It could mention the effect on Skript functionality or what happens after removal, but the current description is largely complete.
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 input schema is fully covered. The description does not need to add parameter info, and the baseline of 4 is appropriate for a parameterless tool. The description focuses on the action, which is sufficient.
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 ('unload and remove'), the resource ('temporary scripts'), and the scope ('only those left by this MCP server'). It distinguishes from sibling tools like skript_reload_file which reloads scripts, and minecraft_command which executes commands.
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 cleanup after the MCP server leaves temporary scripts, but it does not explicitly state when to use it versus alternatives like reloading or checking files. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0minecraft_commandminecraft_logsskript_check_fileskript_reload_fileskript_resetScored across 5 tools
Each tool targets a distinct action: file validation, reload, command execution, log retrieval, and reset cleanup. The only potential confusion is between skript_check_file and skript_reload_file, but their descriptions clearly differentiate validation from reloading.
The naming pattern is mostly consistent with skript_ prefix for Skript operations and minecraft_ prefix for Minecraft server operations. Minor inconsistency: 'minecraft_logs' uses a plural noun while others use verb_noun (check_file, reload_file, command).
5 tools is well-scoped for a focused MCP server that bridges Skript development and Minecraft server management. Each tool serves a clear purpose without unnecessary redundancy.
The tool set covers core Skript file operations and server commands, but lacks read-only file operations (e.g., listing scripts, getting contents) and no way to modify configs or manage server state beyond commands. The domain is somewhat narrow by design.
Create, configure, manage Minecraft servers — plugins, files, console, modpacks, backups, metrics.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
MCP server for skill documentation, generated by doc2mcp.
