This page is what I found on 5 October 2026.

• Why these servers exist
• How I counted
• Projects
• Feature matrix
• Boundaries
• What this means for my future plugin work

Why these servers exist

An LLM client already speaks MCP. Minecraft does not. Each project fills one hole.

1. Give the model a player. A Mineflayer bot joins like a person. The model can walk, mine, and chat. The project exists so a desktop assistant can play. Server-side plugin events stay out of reach.
2. Give the model the console. RCON, a Paper plugin, or a Docker wrapper sends text commands and reads logs. The project exists so an assistant can administer a server the way an operator already can.
3. Give the model the world API. A Fabric, NeoForge, Forge, or Paper component runs inside the game and returns blocks, entities, and inventories as structured data. The project exists because command text is a poor tool result.
4. Give the model the source. Decompilers, mappings, wiki pages, crash logs, and Blockbench sit beside the editor. The project exists so a coding agent can write a mod with real method names.
5. Give one product a Minecraft skill. A few servers are a feature of a larger tool: a skin editor, a modpack toolchain, a Bedrock launcher, or an AI client such as Fairies. The MCP server exists so that product can call the game.

A fleet bus is still missing from this set. MQTT is still missing from this set. One tested plugin for every loader is still missing from this set.

How I counted

I read GitHub repositories, their READMEs, and directory pages that point back at those repositories. The directories were mcp.so, Glama, and mcpservers.org. They mostly repeat GitHub.

A loose GitHub search returned 482 repositories. This page keeps the ones that are an MCP server for the game, for server admin, or for mod and plugin work.

Activity is the last GitHub push. Stars are a popularity hint. A push date means someone edited the repository. It is a weak sign that the project still matches the current game.

Bands, counted from 5 October 2026:

• Moving. Last push on or after 5 September 2026.
• Slowing. Last push from 1 April 2026 through 4 September 2026.
• Quiet. Last push before 1 April 2026, or a single early commit and no follow-up.

Projects

Star counts and push dates below are from 5 October 2026.

A player, through Mineflayer

The bot joins as a client. The loader on the server does not matter. Plugin events stay invisible.

The console

A plugin on the server

A mod inside the game

Source, docs, and side tools

Smaller sketches with the same shapes, kept out of the tables: Backas03/VitaminMCP (bots used to test a server), Trooper3001/claude-build-bridge (Fabric plus the Axiom editor), Steve-pixel-cpu/mc-skill-library, giesea59/minecraft-dev-mcp-server, umjammer/mc-mcp-server, Acetyld/packmind (read a Forge modpack). uukelele-scratch/minecraft-mcp is a three-commit Mineflayer stub.

Feature matrix

Each row is a family. “As a client” means the bot can join that server. It still cannot see plugin events.

Boundaries

These are the limits I would plan around. They come from the READMEs and from the shape of the projects. I did not run each server.

A bot stays simple until the protocol moves. Mineflayer does not care which plugin loader the server uses. It also misses plugin events, inventories it has not opened, and claims. Online mode needs a real account. AhmadTariq’s README says the current Mineflayer release stops at 1.21.x, and Minecraft 26.x is still open. A bot with 40 to 60 tools fills the model context. Pathfinding and combat are slow next to a 50 ms tick. The model round trip is seconds.

RCON works on the most servers, and it returns text. Any server that enables RCON can use it, including vanilla. There is one password. An event stream is missing. Two commands can come back in the wrong order. The text does not say whether the server is Paper, Fabric, or a hybrid.

An in-process plugin or mod covers one loader family. Paper and Spigot share a jar when the code stays on the Bukkit API. Folia is absent from these plugins. A Fabric jar does not load on Paper. mcpfabric is the clearest multi-loader mod: Fabric and NeoForge, with a separate jar per Minecraft version, about 14 Fabric jars and 13 NeoForge jars, Java 21 on 1.21 and Java 25 on 26.x. That is as far as one project goes across many versions. It is still two loaders. A proxy is still absent. Paper is still absent.

A long version list is many separate builds. langyo’s README names Forge, Fabric, and NeoForge from old 1.7.2 lines through 26.3. Each cell is a separate build. A green build on one cell leaves the others untested.

Running code inside the process is a different product. lolifamily has one common core, then a thin entry for Fabric, Forge, NeoForge, and Paper. The tool compiles Kotlin and runs it in the game process, including private members. The project’s own README says the token is full control of that process, and that the listener has to stay on localhost. That is a shell, so an allow-list of tools does not apply. A hybrid server is mentioned only as “install the build for the loader that actually boots.” A guest copy loaded through a connector is unsupported.

MCP inside the game is a local tool. The careful projects bind to loopback and require a token. mcpfabric, lolifamily, and Arclight do this. PaperMCP, center2055, and AxenoDev publish a host and port for a remote machine, and with that they put console or world writes on the network. A token in a query string ends up in logs and client configs.

Reflection and file write are operator tools. Inventivetalent exposes reflection and plugin install. Several Paper plugins can write files in the server directory and run any console command. Those tools are useful while developing a plugin on a private box. On a shared server they can destroy the world or the server files.

A fleet is still missing. Each server is one process, one bot, or one RCON host. A second Minecraft server means a second MCP entry, or a second bot. A shared topic tree is missing. Retained status is missing. A capability document that says “this host is Paper and that host is vanilla” is missing.

Side projects use MCP because the editor already does. A skin painter, Blockbench, a wiki, and a Mojang profile lookup do not need a plugin architecture. They exist so the same assistant that writes code can also read a wiki page or look up a player.

What this means for my future plugin work

The next plugin keeps the shared part outside the game. Each server adds only the thin piece its loader can run.

That pattern already shows up more than once, and it stays small. mcpfabric does that for mods. MrApik and PaperMCP do the admin half for Paper.

The outside part is where a fleet belongs. MQTT can carry the events. MCP can sit at the edge and speak to the model. Paper, Fabric, and RCON stay behind that bridge.

Inside the game, one loader belongs in the first jar. A second loader belongs in a second jar, with its own test. A bot and an RCON bridge can cover servers that cannot run the plugin. A bot still cannot see plugin events. RCON still returns text.

This page is a reading of public repositories on 5 October 2026. Stars and push dates will move.

A growing number of people store API keys next to Claude Code settings. Proton Pass tried to fix that with Agent Mode: an isolated vault, a token that is not the password, a mandatory reason on every read, an activity log, and one-click revoke.

That feature is good. It is also paid, and it is not the only model in the market. If you use Dashlane — or you just want something free — here is the short map.

The three models

Almost every product falls into one of these.

1. Token-and-read (Proton’s model)
You create a vault just for the agent. You hand it a token. The agent retrieves the secret when it needs it, states a reason, and the vendor logs the read. Blast radius is one vault. Weakness: a prompt-injected agent can still see the value.

2. Inject-never-reveal
The agent only knows a name (stripe_key). A local broker or the password manager injects the real value into a subprocess, a browser field, or an HTTP proxy. The model never gets the bytes. Stronger against prompt injection. This is where 1Password, Keeper, and Bitwarden’s Agent Access SDK are going.

3. No agent access on purpose
The vault stays human-only. Autofill stays user-driven. That is Dashlane’s public position: credentials must stay under explicit user control, and an AI browser must not scrape the extension.

Tracking (a log of what was read) is common in model 1 and in enterprise PAM.
Alerting on your own rules (“page me if prod-db is read more than three times an hour”) is rare. Consumer apps show a log. Custom alerts live in SIEM, PAM, or a JSONL file you tail yourself.

What the big password managers actually offer

Proton Pass
Agent Mode is the cleanest consumer UI for model 1: scoped vault, expiring token, required reason, activity view, revoke. Included on Pass Plus / Unlimited / Family / Professional / Workspace — not on free Pass.

Dashlane
No Agent Mode. Business plans have a Secrets CLI (inject by secret ID) and a beta MCP server that lets an agent query audit logs, not pull passwords. Their own engineering team runs Claude Code in Dev Containers and keeps tokens off the agent. Stay on Dashlane for personal logins; do not punch an agent hole in that vault.

1Password
Two tracks. For the browser: 1Password for Claude (beta) — biometric approve per task, fill into the page, Agentic Mode locks the rest of the vault. Claude never sees the password or TOTP. For developers: Service Accounts, op run / op:// references, a Claude Code plugin that validates mounted .env files, usage reports. Paid account required. Closest thing to “use the login without exposing it.”

Bitwarden
Secrets Manager: machine accounts and secret IDs instead of plaintext. Free tier exists (unlimited secrets, tight limits on users / projects / machine accounts). Event logs and SIEM-style alerting are on Teams/Enterprise. Separately, the open-source Agent Access SDK does just-in-time, human-approved injection (aac run). Full agent-access auditing is still maturing.

Keeper
Most “enterprise-complete” of the bunch. Agent Kit teaches Claude Code / Cursor / Copilot to call ksm exec so values stay out of chat. Same RBAC and audit as a human. PAM adds agentic policies: allow, deny, require justification or MFA before an agent even runs. Session recording and SIEM on higher tiers. Overkill for a solo .claude folder; right if you already pay for Keeper.

Free and local options

If you do not want another subscription:

• Bitwarden Secrets Manager free — closest hosted Proton-shaped token + isolated project.
• Infisical — free cloud tier or MIT self-host; Agent Vault proxies HTTP so the agent never holds the key.
• secretctl, keymaxxer, passman, agent-vault, Wundervault MCP — local encrypted store + MCP. Agent references a name, the broker injects, output is scrubbed, use is written to a JSONL audit log. This is where you add your alert rules (ntfy, Slack, a cron that greps the log).

These last tools are usually safer than handing Claude a password, even a scoped one.

A simple recommendation

Keep Dashlane (or whatever you already use) for personal logins. Do not give Claude that vault.

Put agent-only secrets somewhere else:

Practical hygiene for Claude Code, regardless of vendor:

• Store values in the vault, not in .claude/ or a committed .env.
• In project files, keep references (op://Agent/openai/credential), not values.
• Deny the agent those paths:

{
  "permissions": {
    "deny": [
      "Read(**/.env*)",
      "Read(~/.ssh/**)",
      "Bash(env)"
    ]
  }
}

• Treat the one bootstrap token (machine account, MCP unlock) like a privileged API key. Keep it in the OS keychain, not in the repo.

The honest takeaway

Proton Agent Mode is still the only mainstream password manager that combines isolated vault + agent token + mandatory reason + one-click revoke in one consumer screen.

Everyone else either refuses to open the vault (Dashlane), injects without showing the secret (1Password, Keeper, Bitwarden SDK), or makes you assemble audit and alerts yourself.

For a coding agent, prefer inject-never-reveal. A reason log is useful after an incident. It does not stop a hijacked agent from reading a vault it was allowed to read.