How do I use world-of-claudecraft-mcp?

1. Click on "Install 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., "@world-of-claudecraft-mcp reset the game and play for 20 steps" 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.

world-of-claudecraft-mcp

by u2

Overview Schema Related Servers Score Discussions

TypeScript

Local

world-of-claudecraft-mcp

一个 MCP server 适配器，让 LLM agent（如 OpenClaw）完全接管并自己玩 World of ClaudeCraft。

它把游戏官方的 headless 环境（headless/env_server.ts，NDJSON over stdio）包成一组 MCP 工具。LLM 当 policy：读状态 → 决策 → 执行动作，循环往复，直到一局结束。

游戏内核（Sim）是官方同一个，无需重写任何游戏逻辑。
观测向量（数值）被解码成 LLM 能读懂的文字：血量/蓝量/等级/朝向、当前目标、 5 个最近怪物、可交互物、任务进度、每个技能的就绪/冷却。
动作是命名枚举（来自游戏的 ACTIONS 列表），LLM 直接选名字，不用猜整数。

1. 前置：构建游戏的 headless 环境

这个 MCP server 本身只是个"翻译层"，它要 spawn 游戏编译出的 env_server.cjs。所以先在**你的机器（Mac 推荐）**上把游戏的环境构建出来：

git clone https://github.com/levy-street/world-of-claudecraft
cd world-of-claudecraft
npm install
npm run build:env          # 产出 dist-env/env_server.cjs
node dist-env/env_server.cjs --bench   # 可选：跑个吞吐基准验证能起来

Related MCP server: AgentSpawnMCP

2. 构建这个 MCP server

cd world-of-claudecraft-mcp
npm install
npm run build              # 产出 dist/index.js

3. 接进 OpenClaw 的 MCP 配置

把下面这段加进 OpenClaw 的 MCP servers 配置（路径改成你机器上的绝对路径）：

{
  "mcpServers": {
    "world-of-claudecraft": {
      "command": "node",
      "args": ["/ABS/PATH/TO/world-of-claudecraft-mcp/dist/index.js"],
      "env": {
        "WOC_ENV_SERVER": "/ABS/PATH/TO/world-of-claudecraft/dist-env/env_server.cjs"
      }
    }
  }
}

也可以设环境变量 WOC_ENV_SERVER 指向 env_server.cjs，不写进配置。

4. 让 OpenClaw「自己玩」

LLM 就是玩家。给它这套系统提示词 / 操作规程，它就会自主循环：

你是 World of ClaudeCraft（类魔兽世界经典版的 MMO）的玩家。用 wow_* 工具自主游玩，不要等人类一步步指令，自己读状态、自己决策、自己执行。
循环：
调用 wow_reset 开新的一局（可选 seed 以复现）。
反复执行：调用 wow_state 读当前局面 → 决定接下来 1~10 个动作 → 用 wow_play([...]) 一次性执行这批动作。
当某次返回 terminated=true 或 truncated=true 时，这一局结束，调用 wow_reset 开下一局，或调用 wow_close 收工。
生存本能： HP 低（看 HP%）就 eat_drink；附近有敌对怪物就 target_nearest 然后 attack；技能就绪（ability_N 在 ready 列表里）且合适就放；有可交互物（corpse/object/quest）就 interact 去拾取/接任务/交任务。
目标优先级： 活着 > 完成/交付任务（升级拿 XP）> 击杀练级。 forward/turn_left/turn_right/strafe_* 用来走位接近或拉开距离。

动作速查（来自 `wow_list_actions`）

动作	含义
`noop`	什么都不做
`forward` / `back`	前进 / 后退
`turn_left` / `turn_right`	转向（同时前进）
`strafe_left` / `strafe_right`	横移
`jump`	跳（带前进）
`target_nearest`	选最近的敌人
`attack`	开始自动攻击当前目标
`ability_1` … `ability_N`	按学会顺序施放技能（N 随职业不同）
`interact`	拾取尸体 / 开物体 / 与任务 NPC 对话
`stop`	停止移动和攻击
`eat_drink`	吃喝回血/回蓝

5. 成本与收敛提醒

默认每个 env step = 5 个 sim tick（约每秒 4 次决策）。每次 wow_step 都是一次 LLM 调用。一局最长 8000 步 → 最多 8000 次调用，单局成本不低。 务必用 wow_play([...]) 批量执行（一次 LLM 调用推进多步），而不是一步步 wow_step。
想更省：可在 wow_reset 的 config 里调大 frameSkip（每步推进更多 tick，决策更稀疏），或调小 maxSteps。
环境是确定性的：同 seed + 同动作序列 = 完全可复现，方便调试 agent 行为。

6. 文件结构

world-of-claudecraft-mcp/
├── src/
│   ├── index.ts        # MCP server：暴露 wow_* 工具
│   ├── env_client.ts   # spawn env_server.cjs 的 NDJSON stdio 客户端
│   └── obs_decode.ts   # 把数值观测向量解码成 LLM 可读文字（依据 src/sim/obs.ts）
├── package.json
├── tsconfig.json
├── openclaw-mcp-config.json   # 直接抄进 OpenClaw MCP 配置
└── README.md

7. 本地冒烟测试（无需构建完整游戏）

想先验证适配器本身（客户端往返 + 观测解码）不依赖完整游戏，可用仓库里的 mock：

npm run build
WOC_ENV_SERVER="$(pwd)/mock_env.cjs" node test_run.mjs

它会打印解码后的可读状态，确认动作/目标/怪物/任务都被正确还原。

已知限制 / 可增强

技能在观测里是 ability_1..N（按学会顺序的槽位），没有映射成真实法术名（如 "Heroic Strike"）。想让 LLM 知道每个槽位是什么技能，可额外读 src/sim/content 的职业技能表做一层名字映射。
仅接了 headless 离线环境（和真实 Sim 同源，但是单人对练，不是线上服）。想上 worldofclaudecraft.com 和真人同场，需要另写 WS/REST 客户端（并注意反 bot / ToS）。

Available Tools

7 tools

wow_closeA

Shut down the environment subprocess. Call when you are completely done playing.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

Describes the destructive action of shutting down the subprocess, but with no annotations, it could add more detail about irreversibility or state loss. However, for a simple shutdown, it is adequate.

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?

Two short sentences, front-loaded with the action and followed by usage guidance. No redundant words.

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

Completeness5/5

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

Given the tool's simplicity (no params, no output schema), the description fully specifies its purpose and usage context within the sibling tool set.

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?

With zero parameters, the schema is fully covered; the description correctly adds no parameter info, meeting the baseline for no-param tools.

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 uses the specific verb 'Shut down' with the resource 'environment subprocess', clearly distinguishing it from siblings like wow_reset (reset) and wow_step (step).

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

Usage Guidelines5/5

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

Explicitly states 'Call when you are completely done playing', providing clear context for when to use this tool versus continuing with other actions.

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

wow_infoA

Return environment metadata: observation size, number of actions, the full action vocabulary, and max level. Call once at the start to learn the action names.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns metadata and suggests one-time usage, but does not explicitly state side effects (e.g., read-only, idempotent). 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.

Conciseness5/5

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

Very concise: two sentences. The first states purpose, the second gives usage guidance. No redundant information.

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

Completeness5/5

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

Given no output schema, the description fully explains the return value (observation size, number of actions, full action vocabulary, max level). For a simple initialization tool with no parameters, this is complete.

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?

There are no parameters, and schema coverage is 100%. According to guidelines, 0 parameters baseline is 4. The description adds value by listing the return contents.

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 it returns environment metadata and lists specific items: observation size, number of actions, full action vocabulary, and max level. It distinguishes from sibling tools by explicitly recommending a single call at startup.

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

Usage Guidelines4/5

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

The description specifies 'Call once at the start' which guides usage context. It does not explicitly say when not to use it, but the sibling tools (wow_reset, wow_step, etc.) imply it's for initialization, making exclusions less critical.

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

wow_list_actionsA

List the available action names for the current class setup. Same as wow_info action list.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations given, so the description carries full burden. It describes a read-only listing operation but does not explicitly confirm no side effects or other behavioral traits.

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?

Single concise sentence plus a cross-reference, no wasted words, front-loaded with key information.

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

Completeness4/5

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

For a simple list tool with no parameters and no output schema, the description adequately explains output and context. Minor improvement could mention read-only nature, but not necessary.

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 exist, so schema coverage is 100% trivially. Description adds context about what is listed (action names) and the scope (current class setup), fitting the baseline for 0 parameters.

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

Purpose4/5

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

Clearly states it lists available action names for current class setup and references wow_info action list as equivalent, providing a clear purpose.

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?

Mentions similarity to wow_info action list, implying alternative use, but does not specify when to use this tool versus others or provide explicit guidance on context.

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

wow_playA

Apply a SEQUENCE of named actions, one env step each. Fewer round-trips than calling wow_step repeatedly, so prefer batches of 1-10 actions per call. Stops early if the episode ends. Returns total reward, end flags, and final state.

ParametersJSON Schema

Name	Required	Description	Default
`actions`	Yes	ordered list of action names from wow_list_actions

TDQS

A4.5/5.0

Behavior4/5

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

Describes that actions are applied sequentially, stops early if episode ends, and returns total reward, end flags, and final state. No annotations provided, so description carries full burden; adequate disclosure of core behavior, though could mention state persistence.

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?

Three focused sentences, no fluff, front-loaded with the core action. Each sentence contributes unique information.

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

Completeness5/5

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

Given a simple tool with one parameter and no output schema, description fully covers behavior, return values, and batching rationale. Differentiates from siblings effectively.

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?

Single parameter 'actions' has full schema coverage, and description adds that they are ordered action names from wow_list_actions, providing useful context beyond the schema.

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?

Clearly states it applies a sequence of named actions, one env step each. Distinguishes itself from sibling wow_step by emphasizing fewer round-trips via batching.

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

Usage Guidelines4/5

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

Explicitly advises preferring batches of 1-10 actions to reduce round-trips, and mentions early stopping on episode end. Appropriate guidance, though does not explicitly mention when not to use (e.g., for single actions, use wow_step).

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

wow_resetA

Start a NEW episode (or restart after one ends). Returns the initial decoded game state. player_class examples: warrior, paladin, priest, mage, hunter, rogue, warlock, druid, shaman.

ParametersJSON Schema

Name	Required	Description
`seed`	No	deterministic seed; same seed -> identical episode
`talents`	No	optional talent spec, e.g. {spec:"arms", rows:{}}
`player_class`	No	one of the nine classes
`player_level`	No	starting level (1..max_level)

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions returning the initial decoded game state but does not describe side effects (e.g., clearing progress, ending previous episodes), error conditions, or prerequisites. The behavioral traits are implied but under-documented.

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 two sentences, no fluff, and front-loaded with the core purpose. Every sentence serves a purpose: first states the action and return, second provides an example parameter value. This is ideal conciseness.

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

Completeness2/5

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

Given no output schema, the description should elaborate on the returned 'initial decoded game state' to help the agent understand the output. It only says 'decoded game state' without structure or content hints. Also, it does not explain optional parameters like seed (though schema covers it), error cases, or the exact meaning of 'episode'. The description is insufficiently complete for a tool with no output schema.

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?

Schema description coverage is 100%, so baseline is 3. The description adds value by listing all nine player_class examples, which is more explicit than the schema's 'one of the nine classes'. No other parameters gain additional meaning, but the player_class list is a concrete improvement.

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's function: 'Start a NEW episode (or restart after one ends). Returns the initial decoded game state.' This provides a specific verb ('start' or 'restart') and resource ('episode/game state'), and distinguishes itself from sibling tools like wow_step (which advances the game) and wow_play (which automates).

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 when to use the tool ('Start a NEW episode' and 'restart after one ends'), providing context for initialization. However, it does not explicitly state when not to use it, nor does it mention alternatives like wow_state for inspecting state without resetting. The guidance is present but minimal.

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

wow_stateA

Re-decode and return the CURRENT game state without taking any action. Use this to read the situation before deciding.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description explains it is a read-only operation. It mentions 're-decode' implying state refresh, adding behavioral context beyond the tool name.

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?

Two sentences, front-loaded, with no extraneous information. Every word earns its place.

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

Completeness5/5

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

For a zero-parameter, no-output-schema tool, the description fully covers purpose, usage, and behavioral traits.

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 and schema coverage 100%, so description does not need to add param info. Baseline 4 is appropriate.

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?

Clearly states verb (re-decode and return), resource (CURRENT game state), and distinguishes from siblings like wow_step (takes action) and wow_reset (resets).

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

Usage Guidelines5/5

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

Explicitly says 'Use this to read the situation before deciding,' which guides when to use versus action-oriented siblings.

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

wow_stepA

Take ONE named action and advance the sim by one env step (5 sim ticks ~ 0.25s). Returns reward, end flags, and the new decoded state.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	action name from wow_list_actions, e.g. "forward", "attack", "ability_3", "interact", "eat_drink"

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description discloses the key behaviors: advancing by one env step (~0.25s), returning reward, end flags, and new state. It does not mention any destructive side effects or prerequisites, but the behavior is well described for a simulation step.

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 two sentences with no wasted words. The first sentence states the core action and timing, the second lists return values. It is front-loaded and efficient.

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

Completeness4/5

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

Given the simplicity of the tool (single parameter, no output schema), the description is complete. It explains what the tool does, how it advances, and what it returns. It could elaborate on 'end flags' or mention that the step consumes the action, but it is adequate for correct usage.

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?

Schema coverage is 100% with the action parameter description. The description adds value by reinforcing that the action is a single named action and providing concrete examples (e.g., 'forward', 'attack'). This goes beyond the schema's description which only references wow_list_actions.

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 verb 'Take' and the resource 'ONE named action' to advance the sim. It distinguishes from sibling tools like wow_reset, wow_list_actions, and wow_state by specifying that it performs a single step and returns reward and state.

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

Usage Guidelines4/5

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

The description provides context by mentioning 'action name from wow_list_actions' and giving examples of valid actions. It implies that wow_list_actions should be called first to get available actions. However, it lacks explicit guidance on when not to use this tool (e.g., for multiple steps or resets).

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. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 28, 2026
- First observedwow_close
- First observedwow_info
- First observedwow_list_actions
- First observedwow_play
- First observedwow_reset
- First observedwow_state
- First observedwow_step

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation4/5

Most tools have distinct purposes, but wow_info and wow_list_actions overlap in listing actions, causing minor ambiguity. The distinction between wow_step and wow_play is clear (single vs batch).

Naming Consistency4/5

All tools start with 'wow_' and use underscores, but some verbs are nouns (wow_state) and two tools (info, list_actions) serve similar informational roles with different names.

Tool Count5/5

7 tools is well-scoped for a game environment MCP server, covering reset, step, batch play, shutdown, info, actions, and state without unnecessary extras.

Completeness5/5

The tool surface covers all essential operations for interacting with a game environment: starting, stepping, batching, closing, metadata, and state reading. No obvious gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
214
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2

Related MCP Servers

agent-skill-loader
Agent Orchestration Developer Tools Autonomous Agents
back1ply
A
license
A
quality
B
maintenance
MCP server to dynamically load Claude Code skills into AI agents
Updated 4 months ago (2026-04-29 13:33 UTC)
5
43
15
MIT
AgentSpawnMCP
Agent Orchestration AI & Machine Learning Code Execution
sandsaber
A
license
Not graded
quality
B
maintenance
A universal MCP server for spawning agents with any OpenAI-compatible LLM, supporting cloud and local models, and integrating with Claude Code, OpenCode, and Codex CLI.
Updated 4 months ago (2026-05-14 18:13 UTC)
MIT
haksnbot-tools
Games & Gamification Autonomous Agents
haksndot
A
license
Not graded
quality
F
maintenance
An MCP server that lets Claude control a Minecraft bot with 40+ actions including movement, combat, crafting, and inventory management. Built on Mineflayer, it supports Microsoft authentication, pathfinding, and auto-reconnect.
Updated 6 months ago (2026-03-10 13:39 UTC)
3
MIT
Discord MCP
Social Media
EncryptMan
F
license
C
quality
C
maintenance
An MCP server that exposes Discord bot actions as tools for LLM clients.
Updated a month ago (2026-07-31 12:47 UTC)
29
1
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/u2/world-of-claudecraft-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

world-of-claudecraft-mcp

1. 前置：构建游戏的 headless 环境

2. 构建这个 MCP server

3. 接进 OpenClaw 的 MCP 配置

4. 让 OpenClaw「自己玩」

动作速查（来自 wow_list_actions）

5. 成本与收敛提醒

6. 文件结构

7. 本地冒烟测试（无需构建完整游戏）

已知限制 / 可增强

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

动作速查（来自 `wow_list_actions`）