Este proyecto expone un pequeño servidor MCP respaldado por un servidor Paper que se ejecuta permanentemente. Paper, Skript y los complementos instalados son el analizador sintáctico: el código Python no intenta entender la sintaxis de Skript en sí.
La imagen predeterminada contiene este perfil de compatibilidad:
Componente | Versión |
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 |
Cada jar descargado se verifica durante la construcción de la imagen. Sobrescribe todas las URL y sumas de verificación relacionadas juntas en .env para usar otro perfil autoritativo. Nunca actualices solo un complemento sin verificar el conjunto completo.
Skript 2.14.3 es intencional para el perfil 1.21.4. SkBee 3.16.1 es la última versión de SkBee para Minecraft 1.21.4, y las versiones más recientes de Skript 2.15/2.16 chocan con su registro de tipo audience de Adventure. Skript más reciente requiere mover todo el perfil a una versión más reciente de Minecraft y SkBee.
Ejecuta el script de configuración. Verifica Docker y uv, crea .env con una contraseña RCON aleatoria, instala dependencias, construye Paper y verifica RCON:
./setup.shPara la configuración manual, crea un archivo de entorno local y reemplaza la contraseña con un valor aleatorio largo que contenga solo letras, números, puntos, guiones bajos o guiones:
cp .env.example .env
docker compose build
docker compose up -d --waitEstablece PUID y PGID en .env con la salida de id -u y id -g. Por defecto son 1000 y permiten que Paper lea los archivos temporales creados por el host con modo 0600.
Los registros de Paper se montan en runtime/logs. Los scripts del host se montan directamente en /server/plugins/Skript/scripts desde scripts. Los datos del mundo y los generados por complementos permanecen como estado desechable del contenedor. Solo se publica RCON, y está vinculado a 127.0.0.1:25575; el puerto de juego no se publica.
Verifica el inicio y las versiones de los complementos con:
docker compose logs paper
docker compose exec paper sh -c 'nc -z 127.0.0.1 25575'Instálalo y ejecútalo con uv:
uv sync
uv run --env-file .env skript-mcpEl proceso MCP lee estas variables de entorno:
Variable | Valor por defecto |
| Requerido |
|
|
|
|
|
|
|
|
| 5 segundos |
| 30 segundos |
|
|
Para OpenCode, agrega una entrada MCP local y pasa la misma contraseña RCON a través del entorno:
{
"$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": {}
}
}
}Reinicia OpenCode después de cambiar su configuración.
skript_check_file(path) valida un archivo .sk existente por ruta. Las rutas relativas se resuelven bajo SKRIPT_SCRIPTS_DIR; las rutas absolutas se aceptan cuando apuntan dentro de ese directorio. Recarga el conjunto completo de scripts para que las funciones y otras definiciones compartidas de scripts hermanos estén disponibles.
skript_reload_file(path) recarga una ruta existente dentro de SKRIPT_SCRIPTS_DIR sin recargar sus scripts hermanos.
minecraft_command(command) ejecuta un comando privilegiado a través de RCON local.
minecraft_logs(lines=200) devuelve una cola limitada del archivo latest.log.
skript_reset() elimina solo los archivos obsoletos __mcp_check_<uuid>.sk.
Las operaciones de recarga se serializan. Los diagnósticos se analizan principalmente desde la respuesta de RCON porque Skript redirige deliberadamente los diagnósticos de comandos fuera del registro normal del servidor; los bytes añadidos a latest.log después del desplazamiento de la operación se capturan y se fusionan como fuente secundaria.
skript_check_file realiza una recarga real de cada script habilitado, no un análisis en entorno aislado. El código fuente que contiene manejadores on load o comportamiento de complementos puede modificar el mundo, archivos o sistemas externos. Solo verifica scripts de confianza y trata minecraft_command y la contraseña RCON como acceso de administrador completo.
Ejecuta las pruebas unitarias con:
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.
