이 프로젝트는 영구적으로 실행되는 Paper 서버를 기반으로 하는 작은 MCP 서버를 제공합니다. Paper, Skript 및 설치된 애드온이 파서 역할을 합니다. Python 코드는 Skript 구문 자체를 이해하려고 시도하지 않습니다.
기본 이미지에는 다음 호환성 프로필이 포함되어 있습니다:
구성 요소 | 버전 |
Java | 21 |
Paper | 1.21.4 빌드 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가 호스트가 생성한 mode-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.
