What can you do with this server?

This server provides an MCP interface for controlling a Minecraft Java Edition server via RCON, with an optional AI-powered in-game chat listener. * run_command: Execute any Minecraft server command (e.g., list, data get entity, locate structure village) and receive its response, allowing inspection or modification of the live world. * get_ai_chat_status: Check the health, history size, active AI model, log path, and memory configuration of the in-game AI chat listener. * In-game AI chat: Players can type ai in chat; Claude (via Anthropic API) responds using /tellraw, with access to live world state via RCON. The agent has two git-tracked persistent memory stores (server-specific and capability-agnostic) that accumulate knowledge across sessions via a remember tool. * Bundled scripts and recipes: A Python toolbox of low-level primitives (e.g., count_entities, find_block_entities) and higher-level recipes (e.g., cat_spawn_check, reset_trial_spawners) can be listed and run via list_scripts and run_script tools, accessible both programmatically and through the in-game AI agent.

How do I use minecraft-rcon-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@minecraft-rcon-mcp list all online players" 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.

minecraft-rcon-mcp

by scotteratigan

Overview Schema Source Related Servers Discussions Admin

Python

Local

minecraft-rcon-mcp

An MCP server that exposes a Minecraft Java Edition server over RCON as a tool, plus an optional in-game AI chat listener: players type ai <question> in chat and Claude answers in-game, using RCON to read live world state.

It is configured entirely through environment variables, so it is independent of any particular server, world, or Minecraft version.

Features

run_command tool — run any Minecraft server command via RCON and return the response. Use it from any MCP client (Claude Code, VS Code / Copilot, etc.) to inspect or modify the live world.
In-game AI chat — a background thread tails the server log; chat messages prefixed with a configurable trigger (ai by default) are answered by Claude via the Anthropic API, with an agentic RCON tool-use loop and a rolling context window. Responses are posted back with /tellraw.
Persistent memory — the in-game agent reads two git-tracked memory files into its context each request and can append to them with a remember tool, so it accumulates knowledge across sessions instead of relying only on the rolling chat window. See Persistent memory.
get_ai_chat_status tool — report listener health, history size, model, log path, and memory configuration.

Related MCP server: Minecraft MCP Server

Requirements

Python 3.14+
A Minecraft server with RCON enabled (enable-rcon=true in server.properties)
An Anthropic API key (only if you use the in-game AI chat feature)

Install

pip install git+https://github.com/scotteratigan/minecraft-rcon-mcp

Or, for local development / use from a sibling repo:

pip install -e path/to/minecraft-rcon-mcp

Run

minecraft-rcon-mcp          # console entry point
python -m minecraft_rcon_mcp   # equivalent

The server speaks MCP over stdio, so it is normally launched by an MCP client rather than by hand. Example client config (.vscode/mcp.json):

{
  "servers": {
    "minecraft-rcon": {
      "type": "stdio",
      "command": "/path/to/.venv/Scripts/python.exe",
      "args": ["-m", "minecraft_rcon_mcp"],
      "env": {
        "RCON_HOST": "localhost",
        "RCON_PORT": "25575",
        "RCON_PASSWORD": "your-rcon-password",
        "LOG_PATH": "/path/to/server/logs/latest.log"
      }
    }
  }
}

Provide ANTHROPIC_API_KEY in the launching environment (not in committed files) if you want the in-game AI chat.

Configuration

Variable	Default	Purpose
`RCON_HOST`	`localhost`	RCON host
`RCON_PORT`	`25575`	RCON port
`RCON_PASSWORD`	`changeme`	RCON password (match `server.properties`)
`LOG_PATH`	`./logs/latest.log`	Path to the server log to tail. Set this explicitly — the default is relative to the working directory.
`AI_CHAT_ENABLED`	`1`	Set `0`/`false` to run a pure RCON tool server (no log tailing, no Anthropic usage).
`AI_PREFIX`	`ai`	Chat trigger prefix (case-insensitive).
`AI_MODEL`	`claude-sonnet-4-5`	Anthropic model for in-game chat.
`AI_MAX_CONTEXT`	`10`	Exchanges retained in the rolling history.
`AI_MAX_TOKENS`	`1024`	Max tokens per chat response.
`AI_SYSTEM_PROMPT`	(generic built-in)	Replace the entire system prompt.
`AI_SYSTEM_PROMPT_EXTRA`	(none)	Append server-specific context (Minecraft version, house rules) to the default prompt.
`AI_MEMORY_ENABLED`	`1`	Set `0`/`false` to disable persistent memory (no files read or written).
`SERVER_MEMORY_PATH`	`./agent_memory.md`	Path to the server-specific memory file (world/player facts). Set this explicitly to a file in your server repo so it is git-tracked there, just like `LOG_PATH`.
`CAPABILITY_MEMORY_PATH`	(packaged `agent_memory/capabilities.md`)	Path to the server-agnostic capability/script memory. Defaults to a file shipped inside this package; override only if you want it elsewhere.
`WORLD_DIR`	—	World save folder (the one with `level.dat`). Required by the file-reading and structure-building scripts run via `run_script` (it can't be derived over RCON).
`STRUCTURES_DIR`	—	Folder of captured `.nbt` templates. Lets `run_script` builders/capture refer to structures by bare name (e.g. `generate_monument` → `ocean_monument`).
`MINECRAFT_JAR`	(auto: `versions//server-.jar`)	Server jar read for the vanilla structure catalog/sizing (`generate_structure`/`generate_piece`). Set explicitly when the working dir isn't near the jar.
`ANTHROPIC_API_KEY`	—	Required for in-game AI chat.

The run_command + remember tools are always available. Two more — list_scripts and run_script — dispatch the Python toolbox (structure builders, world queries) without one MCP tool per script; see Scripts & recipes. They're also exposed to the in-game chat agent, so players can ask it to build things.

Persistent memory

The in-game AI agent keeps two separate memory stores, both intended to be version-controlled, so it accumulates knowledge across sessions. The split is deliberate — each store lives in a different repo:

Scope	What goes in it	Where it lives	Written via
`server`	Facts specific to this server, world, or its players — base/build coordinates, player preferences, house rules, world boundaries, ongoing projects.	The consumer (server) repo, at `SERVER_MEMORY_PATH`. Committed there.	`remember(scope="server")`
`capability`	Server-agnostic knowledge about this MCP — useful command patterns, what a script does, gotchas, techniques that help on any server.	This package, at `CAPABILITY_MEMORY_PATH` (defaults to `agent_memory/capabilities.md`). Committed here.	`remember(scope="capability")`

How it works:

Read — on every chat request, both files are read fresh and appended to the system prompt under a # Persistent memory heading. Editing a file (by hand or by the agent) takes effect on the next message; no restart needed.
Write — the agent has a remember tool that takes content and a scope (server | capability) and appends a one-line bullet to the matching file, creating it with a header if absent.

Because the capability store defaults to a path inside this package, the agent writes into it in place. That is committable when the package is installed editable (pip install -e), which is the intended development setup; under a plain wheel install it would write into site-packages instead, so set CAPABILITY_MEMORY_PATH to a writable, tracked location if you deploy that way.

Disable the whole feature with AI_MEMORY_ENABLED=0.

Scripts & recipes

The package bundles server-agnostic tooling split into two layers. They live here (not in any one server repo) because they are reusable capabilities. The aim is a toolbox of small, orthogonal primitives that compose efficiently, plus a few recipes that show how to combine them for common tasks.

Writing one? See CLAUDE.md for the authoring rules (primitive vs. recipe, server-agnostic requirements, shared helpers, quality gates).

Primitives — `minecraft_rcon_mcp.scripts`

Low-level building blocks, each doing one general thing:

Primitive	Purpose	Needs world files?
`rcon`	Shared RCON client + CLI for running any command.	No (RCON only)
`count_entities`	Run an entity selector and return the parsed count.	No (RCON only)
`find_block_entities`	Scan region files for block entities (spawners, chests…).	Yes
`check_chunk_generated`	Whether given coords are in generated chunks.	Yes
`find_unexplored_edges`	Nearest ungenerated region frontier to a position.	Yes

python -m minecraft_rcon_mcp.scripts.rcon "list"
python -m minecraft_rcon_mcp.scripts.count_entities "type=minecraft:cat,distance=..48" --at Steve
python -m minecraft_rcon_mcp.scripts.find_block_entities --x 0 --z 0 --block-id minecraft:chest
python -m minecraft_rcon_mcp.scripts.check_chunk_generated 1216 237 --dimension the_nether
python -m minecraft_rcon_mcp.scripts.find_unexplored_edges 120 45

Recipes — `minecraft_rcon_mcp.recipes`

Higher-level, task-specific tools composed from the primitives (and sometimes coupled to a particular Minecraft version's mechanics). Each is also a worked example of composition:

Recipe	Composed from	Notes
`cat_spawn_check <player>`	`count_entities`	Village cat-spawn gates; thresholds are version-coupled (26.x).
`reset_trial_spawners [player]`	`find_block_entities` + `rcon`	Finds trial spawners near a player, resets cooldowns.

python -m minecraft_rcon_mcp.recipes.cat_spawn_check Steve
python -m minecraft_rcon_mcp.recipes.reset_trial_spawners

Configuration

RCON — read from RCON_HOST / RCON_PORT / RCON_PASSWORD. As a fallback, rcon.py reads rcon.port / rcon.password from a server.properties in the working directory (or SERVER_PROPERTIES).
WORLD_DIR — tools that read save files need the world folder (the one with level.dat / dimensions/). This cannot be derived over RCON (no vanilla command exposes the save path), so set WORLD_DIR, or pass --world-dir.
--dimension — region-reading tools default to the overworld; pass the_nether / the_end / a namespaced id (mymod:custom) for others. Both vanilla (DIM-1/DIM1) and data-driven (dimensions/<ns>/<name>/) layouts resolve automatically.

The world data itself lives in the server deployment, not in this repo — these tools only carry the logic, and reach the world through WORLD_DIR.

Development

This project uses uv for environment and dependency management, Ruff for linting and formatting, and ty for static type checking. The pinned Python version lives in .python-version; uv installs it for you.

uv sync                 # create .venv and install all deps (incl. dev tools)

uv run pytest           # run the test suite
uv run ruff format      # auto-format
uv run ruff check       # lint (add --fix to auto-fix)
uv run ty check         # type-check

License

MIT — see LICENSE.

Available Tools

2 tools

get_ai_chat_statusA

Return the status of the in-game AI chat listener and conversation history.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations; description only says 'return', suggesting read-only. No disclosure of side effects, auth needs, or edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with verb, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema; description mentions specific items but lacks structural detail. Adequate for a simple tool but could hint at return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; schema coverage 100%. Description adds no param info but none needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it returns status of AI chat listener and conversation history. Distinct from sibling 'run_command' which likely executes commands.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Implied as a status check but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_commandA

Run a Minecraft server command via RCON and return the response.

Examples: 'list', 'data get entity @e[type=minecraft:cat,limit=5,sort=nearest]', 'locate structure village', 'execute at @p run data get block ~ ~ ~'

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'via RCON' and 'return the response,' but does not address whether commands can be destructive, what permissions are required, or any rate limits. This lack of safety and side-effect disclosure is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one sentence stating the action and purpose, followed by four diverse examples. No superfluous information is present. It is well-structured and front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter and an output schema (not shown but present), yet the description lacks behavioral details such as potential side effects or authorization needs. The examples help, but overall completeness is adequate but not exceptional.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It provides multiple examples that illustrate valid commands, adding meaning beyond the parameter name alone. However, it does not explicitly describe the parameter format, constraints, or expected syntax, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a Minecraft server command via RCON and returns the response. The examples further clarify the scope. It is distinct from the only sibling, get_ai_chat_status, which handles chat status queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used to execute server commands, but does not explicitly state when to use it versus alternatives, nor does it provide any conditions or exclusions. The sibling tool is unrelated, so distinction is clear by function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.1.0Jun 23, 2026
- First observedget_ai_chat_status
- First observedrun_command

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-06-23 17:25 across 2 tools

Disambiguation5/5

The two tools, get_ai_chat_status and run_command, have clear and distinct purposes. One retrieves chat status, the other executes arbitrary commands, leaving no ambiguity.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern (get_ai_chat_status, run_command), making them predictable and easy to differentiate.

Tool Count3/5

With only 2 tools, the server is minimally functional. While run_command covers core RCON operations, the additional AI chat tool is specific; the count is low but acceptable for a narrow purpose.

Completeness3/5

The server provides basic RCON command execution and AI chat status, but lacks tools for managing AI chat (e.g., enable/disable) or more granular server interactions, leaving notable gaps.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
synap A
com.linkrra
Synap (pool.linkrra.com/v1), Linkrra's OpenAI-compatible LLM API, as an MCP server.
AI & Machine Learning Developer Tools
21
Writingmate MCPOAuth
ai.writingmate
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI & Machine Learning Image & Video Processing
1
MCP Aggregation Gateway — 22k+ MCP search & call A
cn.pianam.mcp
One AI endpoint to search and call 22k+ MCP servers; 50+ hosted tools work instantly, no key.
Agent Orchestration Search
31

Related MCP Servers

Minecraft Docker MCP
Virtualization Games & Gamification Command Line
rgbkrk
F
license
Not graded
quality
D
maintenance
Enables AI interactions with a running Minecraft server inside a Docker container using RCON, allowing models to programmatically create Minecraft builds and manage the server.
Updated 2 years ago (2025-02-05 20:53 UTC)
10
-
Minecraft MCP Server
Games & Gamification App Automation Command Line
Peterson047
F
license
Not graded
quality
D
maintenance
Enables control of a Minecraft server through RCON commands via natural language, including game commands, chat-based AI interactions, and server management capabilities.
Updated a year ago (2025-07-05 17:06 UTC)
6
-
Minecraft RCON MCP Server
Games & Gamification Developer Tools Testing & QA Tools
MinecraftCodeFoundary
A
license
A
quality
D
maintenance
Connects AI agents to Minecraft servers via RCON to execute commands, monitor logs, and perform read-only SQLite database queries. It is specifically designed to facilitate AI-assisted plugin development, live debugging, and automated testing workflows.
Updated 7 months ago (2026-02-13 10:03 UTC)
6
11
MIT
Minecraft Server MCP
Games & Gamification Command Line
Ver-zhzh
A
license
B
quality
D
maintenance
Enables AI assistants to interact with and manage Minecraft servers through a standardized interface, supporting server monitoring, player management, log analysis, and command execution.
Updated 10 months ago (2025-11-25 05:21 UTC)
11
MIT

minecraft-rcon-mcp

Features

Requirements

Install

Run

Configuration

Persistent memory

Scripts & recipes

Primitives — minecraft_rcon_mcp.scripts

Recipes — minecraft_rcon_mcp.recipes

Configuration

Development

License

Available Tools

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Minecraft Docker MCP

Minecraft MCP Server

Minecraft RCON MCP Server

Minecraft Server MCP

Primitives — `minecraft_rcon_mcp.scripts`

Recipes — `minecraft_rcon_mcp.recipes`