Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@skript-mcp check the teleport script for syntax errors"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project exposes a small MCP server backed by a permanently running Paper server. Paper, Skript, and the installed addons are the parser: the Python code does not attempt to understand Skript syntax itself.
The default image contains this compatibility profile:
Component | Version |
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 |
Every downloaded jar is checked during the image build. Override all related
URLs and checksums together in .env to use another authoritative profile.
Never update only one addon without verifying the complete set.
Skript 2.14.3 is intentional for the 1.21.4 profile. SkBee 3.16.1 is the last
SkBee release for Minecraft 1.21.4, and newer Skript 2.15/2.16 releases collide
with its Adventure audience type registration. Newer Skript requires moving
the whole profile to a newer Minecraft and SkBee release.
Run the setup script. It checks Docker and uv, creates .env with a random
RCON password, installs dependencies, builds Paper, and verifies RCON:
./setup.shFor manual setup, create a local environment file and replace the password with a long random value containing only letters, numbers, dots, underscores, or hyphens:
cp .env.example .env
docker compose build
docker compose up -d --waitSet PUID and PGID in .env to the output of id -u and id -g. They
default to 1000 and let Paper read the host-created mode-0600 temporary files.
Paper logs are mounted at runtime/logs. Host scripts are mounted directly at
/server/plugins/Skript/scripts from scripts. World and plugin-generated data
remain disposable container state. Only RCON is published, and it is bound to
127.0.0.1:25575; the gameplay port is not published.
Check startup and plugin versions with:
docker compose logs paper
docker compose exec paper sh -c 'nc -z 127.0.0.1 25575'Install and run it with uv:
uv sync
uv run --env-file .env skript-mcpThe MCP process reads these environment variables:
Variable | Default |
| Required |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For OpenCode, add a local MCP entry and pass the same RCON password through the environment:
{
"$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": {}
}
}
}Restart OpenCode after changing its configuration.
skript_check_file(path) validates an existing .sk file by path. Relative
paths are resolved under SKRIPT_SCRIPTS_DIR; absolute paths are accepted
when they point inside that directory. It reloads the complete script set so
functions and other shared definitions from sibling scripts are available.
skript_reload_file(path) reloads one existing path inside
SKRIPT_SCRIPTS_DIR without reloading its siblings.
minecraft_command(command) runs a privileged command over local RCON.
minecraft_logs(lines=200) returns a bounded tail of latest.log.
skript_reset() removes only stale __mcp_check_<uuid>.sk files.
Reload operations are serialized. Diagnostics are parsed primarily from the
RCON response because Skript deliberately redirects command diagnostics away
from normal server logging; bytes appended to latest.log after the operation
offset are captured and merged as a secondary source.
skript_check_file performs a real reload of every enabled script, not a
sandboxed parse. Source containing on load handlers or addon behavior can
modify the world, files, or external systems. Only check trusted scripts, and
treat minecraft_command and the RCON password as full administrator access.
Run unit tests with:
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. Dates show when Glama detected each change.
v0.1.0minecraft_commandminecraft_logsskript_check_fileskript_reload_fileskript_resetEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sbharga/skript-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
