Этот проект предоставляет небольшой 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-файл проверяется во время сборки образа. Чтобы использовать другой авторитетный профиль, переопределите все соответствующие URL и контрольные суммы вместе в файле .env. Никогда не обновляйте только один аддон без проверки всего набора.
Skript 2.14.3 выбран намеренно для профиля 1.21.4. SkBee 3.16.1 — последний релиз SkBee для Minecraft 1.21.4, а более новые версии Skript 2.15/2.16 конфликтуют с его регистрацией типа audience из Adventure. Для перехода на более новый Skript потребуется обновить весь профиль до более новой версии Minecraft и SkBee.
Запустите скрипт настройки. Он проверяет Docker и uv, создаёт .env со случайным паролем RCON, устанавливает зависимости, собирает Paper и проверяет RCON:
./setup.shДля ручной настройки создайте локальный файл окружения и замените пароль на длинное случайное значение, содержащее только буквы, цифры, точки, подчёркивания или дефисы:
cp .env.example .env
docker compose build
docker compose up -d --waitУстановите PUID и PGID в .env равными выводу команд id -u и id -g. По умолчанию они равны 1000 и позволяют Paper читать созданные хостом временные файлы с правами 0600.
Логи Paper монтируются в runtime/logs. Скрипты хоста монтируются напрямую в /server/plugins/Skript/scripts из папки 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.
